4 This is u2boot, our proposal for a next generation of the famous U-Boot
5 bootloader. U-Boot offers an excellent choice as a bootloader for
6 today's embedded systems, seen from a user's point of view.
7 Nevertheless, there are quite some design flaws which turned out over
8 the last years and we think that they cannot be solved in a production
9 tree. So this tree tries to do several things right - without caring
10 about losing support for old boards.
12 General features include:
14 - A posix based file API
15 inside U-Boot the usual open/close/read/write/lseek functions are used.
16 This makes it familiar to everyone who has programmed under unix systems.
18 - usual shell commands like ls/cd/mkdir/echo/cat,...
20 - The environment is not a variable store anymore, but a file store. It has
21 currently some limitations, of course. The environment is not a real
22 read/write filesystem, it is more like a tar archive, or even more like
23 an ar archive, because it cannot handle directories. The saveenv command
24 saves the files under a certain directory (by default /env) in persistent
25 storage (by default /dev/env0). There is a counterpart called loadenv, too.
27 - Real filesystem support
28 The loader starts up with mounting a ramdisk on /. Then a devfs is mounted
29 on /dev allowing the user (or shell commands) to access devices. Apart from
30 these two filesystems there is currently one filesystem ported: cramfs. One
31 can mount it with the usual mount command.
34 Devices are no longer described by defines in the config file. Instead
35 there are devices which can be registered in the board .c file or
36 dynamically allocated. Drivers will match upon the devices automatically.
39 Timekeeping has been simplified by the use of the Linux clocksource API.
40 Only one function is needed for a new board, no [gs]et_timer[masked]() or
41 reset_timer[masked]() functions.
43 - Kconfig and Kernel build system
44 Only targets which are really needed get recompiled. Parallel builds are
45 no problem anymore. This also removes the need for many many ifdefs in
49 U-Boot can be compiled to run under Linux. While this is rather useless
50 in real world this is a great debugging and development aid. New features
51 can be easily developped and tested on long train journeys and started
52 under gdb. There is a console driver for linux which emulates a serial
53 device and a tap based ethernet driver. Linux files can be mapped to
54 devices under U-Boot to emulate storage devices.
56 - device parameter support
57 Each device can have a unlimited number of parameters. They can be accessed
58 on the command line with <devid>.<param>="...", for example
59 'eth0.ip=192.168.0.7' or 'echo $eth0.ip'
62 hooks in the startup process can be archieved with *_initcall() directives
66 There is a small getopt implementation. Some commands got really
67 complicated (both in code and in usage) due to the fact that U-Boot only
68 allowed positional parameters.
71 Scripts can be edited with a small editor. This editor has no features
72 except the ones really needed: moving the cursor and typing characters.
78 U-Boot uses the Linux kernel's build system. It consists of two parts:
79 the makefile infrastructure (kbuild), plus a configuration system
80 (kconfig). So building U-Boot is very similar to building the Linux
83 For the examples below, we use the User Mode U-Boot implementation, which
84 is a port of U-Boot to the Linux userspace. This makes it possible to
85 test drive the code without having real hardware. So for this test
86 scenario, ARCH=sandbox is the valid architecture selection. This currently
87 only works on ia32 hosts and partly on x86-64.
89 Selection of the architecture and the cross compiler can be done in two
90 ways. You can either specify it using the environment variables ARCH
91 and CROSS_COMPILE, or you can create the soft links cross_arch and
92 cross_compile pointing to your architecture and compiler. For ARCH=sandbox
93 we do not need a cross compiler so it is sufficient to specify the
96 # ln -s sandbox cross_arch
98 In order to configure the various aspects of U-Boot, start the U-Boot
103 This command starts a menu box and lets you select all the different
104 options available for your architecture. Once the configuration was
105 finished (you can simulate this by using the standard demo config file
106 with 'make sandbox_defconfig'), there is a .config file in the toplevel
107 directory of the sourcode.
109 Once U-Boot is configured, we can start the compilation
113 If everything goes well, the result is a file called uboot:
116 -rwxr-xr-x 1 rsc ptx 114073 Jun 26 22:34 uboot
118 U-Boot usually needs an environment for storing the configuation data.
119 You can generate an environment using the example environment contained
120 in examples/environment:
122 # ./scripts/ubootenv -s -p 0x10000 examples/environment/ env.bin
124 To get some files to play with you can generate a cramfs image:
125 # mkcramfs somedir/ cramfs.bin
127 The U-Boot image is a normal Linux executable, so it can be started
128 just like every other program:
130 # ./uboot -e env.bin -i cramfs.bin
132 U-Boot 2.0.0-trunk (Jun 26 2007 - 22:34:38)
134 loading environment from /dev/env0
137 Specifying -[ie] <file> tells U-Boot to map the file as a device
138 under /dev. Files given with '-e' will appear as /dev/env[n]. Files
139 given with '-i' will appear as /dev/fd[n].
140 If U-Boot finds a valid configuration sector on /dev/env0 it will
141 load it to /env. It then executes /env/init if it exists. If you have
142 loaded the example environment U-Boot will show you a menu asking for
145 If you have started U-Boot as root you will find a new tap device on your
146 host which you can configure using ifconfig. Once you configured U-Boots
147 network settings accordingly you can do a ping or tftpboot.
149 If you have mapped a cramfs image try mounting it with
152 # mount /dev/fd0 cramfs /cram
154 Memory can be examined as usual using md/mw commands. They both understand
155 the -f <file> option to tell the commands that they should work on the
156 specified files instead of /dev/mem which holds the complete address space.
157 Note that if you call 'md /dev/fd0' (without -f) U-Boot will segfault on
158 the host, because it will interpret /dev/fd0 as a number.
163 Most of the directory layout is based upon the Linux Kernel:
165 arch/*/ -> contains architecture specific parts
166 arch/*/mach-*/ -> SoC specific code
168 drivers/serial -> drivers
172 include/asm-* -> architecture specific includes
173 include/asm-*/arch-* -> SoC specific includes
175 fs/ -> filesystem support and filesystem drivers
177 lib/ -> generic library functions (getopt, readline and the
180 common/ -> common stuff
182 commands/ -> many things previously in common/cmd_*, one command
185 net/ -> Networking stuff
187 scripts/ -> Kconfig system
191 There is still the old directory layout in the tree which of course should be
192 merged in one way or the other:
194 lib_*/ -> currently unused
195 cpu/* -> currently unsused
197 nand_spl/ -> untouched
200 documentation/ -> untouched