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:
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