diff options
| -rw-r--r-- | Documentation/README | 107 | ||||
| -rw-r--r-- | Documentation/parameters.txt | 2 | ||||
| -rw-r--r-- | Documentation/porting.txt | 18 | ||||
| -rw-r--r-- | README.u2 | 155 |
4 files changed, 119 insertions, 163 deletions
diff --git a/Documentation/README b/Documentation/README deleted file mode 100644 index 23b47ef6d5..0000000000 --- a/Documentation/README +++ /dev/null @@ -1,107 +0,0 @@ - -For long time U-Boot has served as a reliable and versatile bootloader for -embedded systems, but over the time more and more limitations appeared. -With U-Boot one hasd to know the memory layout of a particular device to work -with it. For example to use tftpboot you need to know a memory address where -you can store the file you are just loading. Saving it in flash requires you -to know where in the memory space your flash device is and what erase block -size it has. Configuring U-Boot means that you handle a lot of #defines. This -usually starts with one define to activate a feature, compiling U-Boot and -letting the compiler tell you what other defines you'll probably need. - -This is an attempt to rework U-Boot to fit the needs of modern embedded -systems. Features include: - -- A posix based file API - inside U-Boot the usual open/close/read/write/lseek functions are used. - This makes it familiar to everyone who has programmed under unix systems. - -- usual shell commands like ls/cd/mkdir/echo/cat,... - -- The environment is not a variable store anymore, but a file store. It has - currently some limitations, of course. The environment is not a real - read/write filesystem, it is more like a tar archive, or even more like - an ar archive, because it cannot handle directories. The saveenv command - saves the files under a certain directory (by default /env) in persistent - storage (by default /dev/env0). There is a counterpart called loadenv, too. - -- Real filesystem support - The loader starts up with mounting a ramdisk on /. Then a devfs is mounted - on /dev allowing the user (or shell commands) to access devices. Apart from - these two filesystems there is currently one filesystem ported: cramfs. One - can mount it with the usual mount command. - -- device/driver model - Devices are no longer described by defines in the config file. Instead - there are devices which can be registered in the board .c file or - dynamically allocated. Drivers will match upon the devices automatically. - -- clocksource support - Timekeeping has been simplified by the use of the Linux clocksource API. - Only one function is needed for a new board, no [gs]et_timer[masked]() or - reset_timer[masked]() functions. - -- Kconfig and Kernel build system - Only targets which are really needed get recompiled. Parallel builds are - no problem anymore. This also removes the need for many many ifdefs in - the code. - -- simulation target - U-Boot can be compiled to run under Linux. While this is rather useless - in real world this is a great debugging and development aid. New features - can be easily developped and tested on long train journeys and started - under gdb. There is a console driver for linux which emulates a serial - device and a tap based ethernet driver. Linux files can be mapped to - devices under U-Boot to emulate storage devices. - -- device parameter support - Each device can have a unlimited number of parameters. They can be accessed - on the command line with <devid>.<param>="...", for example - 'eth0.ip=192.168.0.7' or 'echo $eth0.ip' - -- initcalls - hooks in the startup process can be archieved with *_initcall() directives - in each file. - -- getopt - There is a small getopt implementation. Some commands got really - complicated (both in code and in usage) due to the fact that U-Boot only - allowed positional parameters. - -- editor - Scripts can be edited with a small editor. This editor has no features - except the ones really needed: moving the cursor and typing characters. - -To get started try - -ARCH=linux make linux_defconfig -ARCH=linux make menuconfig -ARCH=linux make -./vmlinux - -(you can also do a 'ln -s linux cross_arch' to specify ARCH, the Makefile -will read the link. Same with 'ln -s arm cross_compile', for example) - -This will currently only work on an IA32 architecture, because of some -hardcoded values in the linker script because and little endian is assumed. -Starting U-Boot as root will give you a new tap device which you can -configure with - -ifconfig tap0 172.0.0.1 up - -After setting the network parameters under U-Boot (see 'devinfo eth0') you -can start with sending a ping request to your host. If you have a tftp -server running on your host try 'tftpboot <somefile> /target_file' - -For informations on how to map a file to U-Boot try ./vmlinux -h. -For example if you wish to map a cramfs image to u-boot you can generate one -with mkcramfs <dir> cramfs.bin and then start U-Boot with -i cramfs.bin. The -image can be mounted with 'mkdir /cram; mount /dev/fd0 cramfs /cram' - -Still reading? -Well, of course I only talked about the sunny side of life. This stuff is -highly experimental. The code has so far only been tested under ARM and -partly under PowerPC. On PowerPC This loader is not even able to start a -kernel. Much work has to be done until this becomes a usable bootloader. -Despite this I believe this _can_ become usable with reasonable effort. -... to be continued diff --git a/Documentation/parameters.txt b/Documentation/parameters.txt index 219440b40c..9381cd2d3e 100644 --- a/Documentation/parameters.txt +++ b/Documentation/parameters.txt @@ -33,7 +33,7 @@ with the initial value of the parameter. If the framework handles the set function it will try to free the value of the parameter. If this is a static array bad things will happen. A parameter can have the flag PARAM_FLAG_RO which means that the parameter is readonly. It is perfectly ok -then to point value to a static array. +then to point the value to a static array. const char *dev_get_param(struct device_d *dev, const char *name); diff --git a/Documentation/porting.txt b/Documentation/porting.txt index adbbb6ce5b..7cc3bc298a 100644 --- a/Documentation/porting.txt +++ b/Documentation/porting.txt @@ -46,6 +46,8 @@ static int scb9328_console_init(void) 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. @@ -54,8 +56,6 @@ static int scb9328_console_init(void) This will add an area starting at 0x40000 of size 0x20000 of the device cfi_dev as env0. -console_initcall(scb9328_console_init); - - Port missing drivers. Depending on the driver this can a be rather simple process: @@ -68,11 +68,13 @@ console_initcall(scb9328_console_init); 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 fields in struct eth_device. get_mac_address() shall retrieve the - MAC address from the EEPROM if one is connected. If you don't have an - EEPROM just return -1. set_mac_address() shall set the MAC address in - the device. All magic previously done with getenv/setenv(ethaddr) must be - removed. + 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 U-Boot 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 @@ -118,4 +120,4 @@ calc_source: 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. + arch/arm/cpu. The start.S files are missing though. @@ -7,8 +7,69 @@ today's embedded systems, seen from a user's point of view. Nevertheless, there are quite some design flaws which turned out over the last years and we think that they cannot be solved in a production tree. So this tree tries to do several things right - without caring -about losing support for old boards. So if you aim at stability at this -time, stay with the official U-Boot releases. +about losing support for old boards. + +General features include: + +- A posix based file API + inside U-Boot the usual open/close/read/write/lseek functions are used. + This makes it familiar to everyone who has programmed under unix systems. + +- usual shell commands like ls/cd/mkdir/echo/cat,... + +- The environment is not a variable store anymore, but a file store. It has + currently some limitations, of course. The environment is not a real + read/write filesystem, it is more like a tar archive, or even more like + an ar archive, because it cannot handle directories. The saveenv command + saves the files under a certain directory (by default /env) in persistent + storage (by default /dev/env0). There is a counterpart called loadenv, too. + +- Real filesystem support + The loader starts up with mounting a ramdisk on /. Then a devfs is mounted + on /dev allowing the user (or shell commands) to access devices. Apart from + these two filesystems there is currently one filesystem ported: cramfs. One + can mount it with the usual mount command. + +- device/driver model + Devices are no longer described by defines in the config file. Instead + there are devices which can be registered in the board .c file or + dynamically allocated. Drivers will match upon the devices automatically. + +- clocksource support + Timekeeping has been simplified by the use of the Linux clocksource API. + Only one function is needed for a new board, no [gs]et_timer[masked]() or + reset_timer[masked]() functions. + +- Kconfig and Kernel build system + Only targets which are really needed get recompiled. Parallel builds are + no problem anymore. This also removes the need for many many ifdefs in + the code. + +- simulation target + U-Boot can be compiled to run under Linux. While this is rather useless + in real world this is a great debugging and development aid. New features + can be easily developped and tested on long train journeys and started + under gdb. There is a console driver for linux which emulates a serial + device and a tap based ethernet driver. Linux files can be mapped to + devices under U-Boot to emulate storage devices. + +- device parameter support + Each device can have a unlimited number of parameters. They can be accessed + on the command line with <devid>.<param>="...", for example + 'eth0.ip=192.168.0.7' or 'echo $eth0.ip' + +- initcalls + hooks in the startup process can be archieved with *_initcall() directives + in each file. + +- getopt + There is a small getopt implementation. Some commands got really + complicated (both in code and in usage) due to the fact that U-Boot only + allowed positional parameters. + +- editor + Scripts can be edited with a small editor. This editor has no features + except the ones really needed: moving the cursor and typing characters. Building U-Boot @@ -22,7 +83,8 @@ kernel. For the examples below, we use the User Mode U-Boot implementation, which is a port of U-Boot to the Linux userspace. This makes it possible to test drive the code without having real hardware. So for this test -scenario, ARCH=linux is the valid architecture selection. +scenario, ARCH=linux is the valid architecture selection. This currently +only works on ia32 hosts and partly on x86-64. Selection of the architecture and the cross compiler can be done in two ways. You can either specify it using the environment variables ARCH @@ -57,7 +119,7 @@ U-Boot usually needs an environment for storing the configuation data. You can generate an environment using the example environment contained in examples/environment: - # ./scripts/ubootenv -s examples/environment/ env.bin + # ./scripts/ubootenv -s -p 0x10000 examples/environment/ env.bin To get some files to play with you can generate a cramfs image: # mkcramfs somedir/ cramfs.bin @@ -80,61 +142,60 @@ load it to /env. It then executes /env/init if it exists. If you have loaded the example environment U-Boot will show you a menu asking for your settings. +If you have started U-Boot as root you will find a new tap device on your +host which you can configure using ifconfig. Once you configured U-Boots +network settings accordingly you can do a ping or tftpboot. +If you have mapped a cramfs image try mounting it with -FIXME: cfi currently doesn't work with um-uboot + # mkdir /cram + # mount /dev/fd0 cramfs /cram +Memory can be examined as usual using md/mw commands. They both understand +the -f <file> option to tell the commands that they should work on the +specified files instead of /dev/mem which holds the complete address space. +Note that if you call 'md /dev/fd0' (without -f) U-Boot will segfault on +the host, because it will interpret /dev/fd0 as a number. -Commands --------- +Directory layout +---------------- -devinfo -addpart -pwd -cd -ls -cat -tftpboot <dest> <source> FIXME: order? -tftpboot /dev/nor0.1 <source> -erase -f /dev/nor0.1 -help -edit -> ctrl-c ctrl-d -md -f /dev/nor0.1 -exec /env/init FIXME: doesn't work yet -saveenv (makes /env persistent) -> /dev/env0 -printenv -mount +Most of the directory layout is based upon the Linux Kernel: -Shell ------ +arch/*/ -> contains architecture specific parts +arch/*/mach-*/ -> SoC specific code -- doesn't have switch/case yet -- only one variable space -[ ] add variable space +drivers/serial -> drivers +drivers/net +drivers/... -Drivers -------- +include/asm-* -> architecture specific includes +include/asm-*/arch-* -> SoC specific includes -/dev -serial -partition -environment -> /env; /env/init +fs/ -> filesystem support and filesystem drivers -Design ------- +lib/ -> generic library functions (getopt, readline and the + like) + +common/ -> common stuff + +commands/ -> many things previously in common/cmd_*, one command + per file + +net/ -> Networking stuff -include/driver.h -board/scb9328.c -include/param.h: each device can have parameters; can be changed on -runtime; get/set can be overwritten by implementation. +scripts/ -> Kconfig system -- xfunctions: do panic if error -- proposed design: - arch/ - arch/arm/cpu-arm920t/ - arch/arm/board-.../ - board/ is obsolete +Documentation/ -> -- arch/*/Makefile is central makefile +There is still the old directory layout in the tree which of course should be +merged in one way or the other: +lib_*/ -> currently unused +cpu/* -> currently unsused +post/ -> untouched +nand_spl/ -> untouched +dtt/ -> untouched +disk/ -> untouched +documentation/ -> untouched |