diff --git a/Documentation/console.txt b/Documentation/console.txt deleted file mode 100644 index 76b6107ac..000000000 --- a/Documentation/console.txt +++ /dev/null @@ -1,13 +0,0 @@ --------------- barebox consoles ------------------ - -barebox supports multiple consoles which may be simultaneously active. -Depending on the configuration none, the first or all consoles are -activated on startup, see CONSOLE_ACTIVATE_FIRST and CONSOLE_ACTIVATE_ALL -options. - -During runtime the behaviour of the consoles can be controlled with the -'active' parameter each console has. The console system recognizes three -characters: 'i' for stdin, 'o' for stdout and 'e' for stderr. These options -may be concatenated together as needed, so setting an 'active' parameter -of a console to 'io' would enable it for stdout and stdin while leaving -stderr disabled. diff --git a/Documentation/devices_drivers.txt b/Documentation/devices_drivers.txt deleted file mode 100644 index e13b13a52..000000000 --- a/Documentation/devices_drivers.txt +++ /dev/null @@ -1,72 +0,0 @@ - ----------- Devices and drivers in barebox -------------- - -We follow a rather simplistic driver model here. There is a struct device which -describes a particular device present in the system. A struct driver represents -a driver present in the system. Both structs find together via the members -'type' (int) and 'name' (char *). If both members match, the driver's probe -function is called with the struct device as argument. People familiar with -the Linux platform bus will recognize this behaviour and in fact many things were -stolen from there. Some selected members of the structs will be described in this -document. -Currently all devices and drivers are handled in simple linked lists. When it comes -to USB or PCI it may be desirable to have a tree structure, but this may also be -unnecessary overhead. - -struct device -------------- - -char name[MAX_DRIVER_NAME]; - -This member (and 'type' described below) is used to match with a driver. This is -a descriptive name and could be MPC5XXX_ether or imx_serial. - -char id[MAX_DRIVER_NAME]; - -The id is used to uniquely identify a device in the system. The id will show up -under /dev/ as the device's name. Usually this is something like eth0 or nor0. - -void *type_data; - -Devices of a particular class normaly need to store more information than struct -device holds. This entry holds a pointer to the type specific struct. - -void *priv; - -Used by the device driver to store private information. - -void *platform_data; - -This is used to carry information of board specific data from the board code to the -device driver. - -struct param_d *param; - -The parameters for this device. See Documentation/parameters.txt for more info. - -struct driver_d ---------------- - -char name[MAX_DRIVER_NAME]; -unsigned long type; - -See above. - -int (*probe) (struct device_d *); -int (*remove)(struct device_d *); - -These are called if an instance of a device is found or gone. - -ssize_t (*read) (struct device_d*, void* buf, size_t count, ulong offset, ulong flags); -ssize_t (*write) (struct device_d*, const void* buf, size_t count, ulong offset, ulong flags); - -The standard read/write functions. These are called as a response to the read/write -system calls. No driver needs to implement these. - -void *type_data; - -This is somewhat redundant with the type data in struct device. Currently the -filesystem implementation uses this field while ethernet drivers use the same -field in struct device. Probably one of them should be removed. - - diff --git a/Documentation/omap4_usb_booting.txt b/Documentation/omap4_usb_booting.txt deleted file mode 100644 index f0d45a2aa..000000000 --- a/Documentation/omap4_usb_booting.txt +++ /dev/null @@ -1,27 +0,0 @@ --------------- omap4_usb_booting -------------- - -omap4 processors have support for booting from the usb port. To be able to fully -use this feature you will need to enable the following: - OMAP4_USBBOOT - This CONFIG_ option adds the required infrastructure. - DRIVER_SERIAL_OMAP4_USBBOOT - This adds console support over the same usb port used for booting. - FS_OMAP4_USBBOOT - This adds filesystem support over the same usb port used for booting. - -To send the bootloader to the processor, execute the utility omap4_usbboot which -can be found in the scripts subdirectory. -omap4_usbboot takes two parameters: - the bootloader image - a directory name which will be the root for the guest system -Once omap4_usbboot is running it will wait for enumeration of the omap4 cpu on -the host usb subsystem. Then power on or reset the cpu with the correct sys_boot -or SAR memory configuration. - -If everything works, barebox's first stage will boot and afterwards it will load -the second stage found at "/barebox.bin". -Barebox's second stage will still have access to the usb filesystem, so an -initrd and a zImage can be loaded. - -Overall this procedure frees the developer of continously be changing the SD -card or other boot media from host to target. diff --git a/Documentation/porting.txt b/Documentation/porting.txt deleted file mode 100644 index bd807a318..000000000 --- a/Documentation/porting.txt +++ /dev/null @@ -1,115 +0,0 @@ - -When porting from old barebox the follwing steps must be taken (please complain -if there's something missing here ;) - - -- Most of the macros in include/configs/yourboard.h can be removed, especially - the CONFIG_COMMANDS section. The goal is to remove this file entirely, but - for now some values are still needed here. If you think some things are better - configured with the Kconfig system feel free to add them there. - -- The linker script needs a new section for the initcalls. The handling of the - barebox command table has changed, too. (The commands are now sorted by the - linker instead at runtime.) To change it you need an entry like the following - in your linker script: - -#include - - __barebox_cmd_start = .; - .barebox_cmd : { BAREBOX_CMDS } - __barebox_cmd_end = .; - - __barebox_initcalls_start = .; - .barebox_initcalls : { INITCALLS } - __barebox_initcalls_end = .; - -- Rename your linker script to barebox.lds.S and add the following entry to the - Makefile to make sure the linker script is generated: - -extra-y += barebox.lds - -- Register the devices present in your system in the board specific .c file. - To see anything you have to at least register a console. In scb9328.c this - looks like this: - - static struct device_d scb9328_serial_device = { - .name = "imx_serial", - .map_base = IMX_UART1_BASE, - .size = 4096, - }; - - static int scb9328_console_init(void) - { - platform_device_register(&scb9328_serial_device); - return 0; - } - - console_initcall(scb9328_console_init); - -- For most boards you will have to register a cfi_flash device. NAND flash - is not ported yet. - -- Call devfs_add_partition() to add an environment partition for your device: - devfs_add_partition("nor0", 0x40000, 0x20000, DEVFS_PARTITION_FIXED, "env0"); - This will add an area starting at 0x40000 of size 0x20000 of the device - nor0 as env0. - -- Port missing drivers. Depending on the driver this can a be rather simple - process: - - Serial drivers - - Declare all functions static. - - in your probe function fill in a struct console_device and register it - with console_register() - - Ethernet drivers - - Basically do the same as with serial drivers. - - Identify the parts of the driver which handle the MAC address. There are - now two functions handling them in struct eth_device. - - get_mac_address() retrieve the MAC address from the EEPROM if one is - connected. If you don't have an EEPROM just return -1. - set_mac_address() set the MAC address in the device. All magic previously - done with getenv/setenv(ethaddr) must be removed. - - During startup barebox calls get_mac_address() to see if an EEPROM is - connected. If so, it calls set_mac_address() with this address. This - is done even if networking is not used during startup. This makes sure - that the MAC address is set in the device and Linux can pick it up later. - - There is now (the beginning of) generic phy support. When porting drivers - it is recommended to use it. The phy support currently only starts generic - autonegotiation, so if you have some fancy things to do (or have gigabit - ethernet) you'll have to extend the phy layer first. Although this is - extra work, it will pay off some day, as phy support is a great source - of duplicated code. see drivers/net/dm9000.c or drivers/net/fec_mpc5200.c - for examples. - -- Add a clocksource for your system. PowerPCs have a generic decrementer - counter, so if you have a PowerPC you have nothing to do here. On ARM - this is SoC dependent. See Documentation/timekeeping.txt for further - information. - -- Adjust start.S. On PowerPC there is at least the Problem that the relocation - offset is defined at compile time. It is easily possible to determine the - address barebox is currently starting from at runtime and thus allowing it - barebox to be started at any address. Look at the relocation code and replace - TEXT_BASE with the following calculation of the runtime address: - - bl calc_source /* Calculate Source Address */ -calc_source: - mfspr r4, LR - subi r4, r4, (calc_source - _start) - subi r4, r4, 0x100 - - (I'm almost sure that PowerPC has a dedicated instruction for this, un- - fortunately I know next to nothing of PowerPC assembler, so if you have - a better way to archieve this, please write to the list.) - - On PowerPC barebox now runs at the address it was linked to, so you have - to adjust TEXT_BASE to be in RAM. This makes the various fixup relocation - functions unnecessary. On PowerPC the removal of -fPIC saves around 10% of - binary space. It also simplifies debugging because you will see the correct - addresses in the objdump without doing offset calculation. - -- On ARM most of the duplicate code under cpu/arm* is already merged into - arch/arm/cpu. The start.S files are missing though. diff --git a/Documentation/timekeeping.txt b/Documentation/timekeeping.txt deleted file mode 100644 index ed5ef62fe..000000000 --- a/Documentation/timekeeping.txt +++ /dev/null @@ -1,13 +0,0 @@ ------------- barebox timekeeping ------------- - -In barebox we use the clocksource mechanism from the Linux Kernel. This makes -it fairly easy to add timer functionality for a new board or architecture. -Apart from initialization there is only one function required: -clocksource_read(). This function returns the current value of a free running -counter. Other functions like udelay() and get_time_ns() are derived from this -function. The only thing you have to implement is a clocksource driver. See -cpu/arm920t/imx/interrupts.c for an example. clocksource drivers from the -Linux Kernel can be used nearly 1:1, except for the register accesses. - -for clocksources the __lshrdi3 symbol is needed. You can find the function for -your architecture in the Linux Kernel or a libc of your choice.