Documentation: remove remaining documentation
This removes the documentation texts in Documentation/. It will be replaced with sphinx based documentation later. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This commit is contained in:
Sascha Hauer
parent
98360be0fe
commit
fb619a75fd
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
@ -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.
|
||||
|
|
@ -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 <asm-generic/barebox.lds.h>
|
||||
|
||||
__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.
|
||||
|
|
@ -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.
|
||||
Loading…
Reference in New Issue