Documentation update
This commit is contained in:
parent
631b71e69c
commit
96f4672d44
|
@ -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
|
|
|
@ -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
|
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
|
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
|
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);
|
const char *dev_get_param(struct device_d *dev, const char *name);
|
||||||
|
|
||||||
|
|
|
@ -46,6 +46,8 @@ static int scb9328_console_init(void)
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
console_initcall(scb9328_console_init);
|
||||||
|
|
||||||
- For most boards you will have to register a cfi_flash device. NAND flash
|
- For most boards you will have to register a cfi_flash device. NAND flash
|
||||||
is not ported yet.
|
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
|
This will add an area starting at 0x40000 of size 0x20000 of the device
|
||||||
cfi_dev as env0.
|
cfi_dev as env0.
|
||||||
|
|
||||||
console_initcall(scb9328_console_init);
|
|
||||||
|
|
||||||
- Port missing drivers. Depending on the driver this can a be rather simple
|
- Port missing drivers. Depending on the driver this can a be rather simple
|
||||||
process:
|
process:
|
||||||
|
|
||||||
|
@ -68,11 +68,13 @@ console_initcall(scb9328_console_init);
|
||||||
Ethernet drivers
|
Ethernet drivers
|
||||||
- Basically do the same as with serial drivers.
|
- Basically do the same as with serial drivers.
|
||||||
- Identify the parts of the driver which handle the MAC address. There are
|
- 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
|
now two functions handling them in struct eth_device.
|
||||||
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
|
get_mac_address() retrieve the MAC address from the EEPROM if one is
|
||||||
the device. All magic previously done with getenv/setenv(ethaddr) must be
|
connected. If you don't have an EEPROM just return -1.
|
||||||
removed.
|
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
|
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
|
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
|
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.
|
addresses in the objdump without doing offset calculation.
|
||||||
|
|
||||||
- On arm most of the duplicate code under cpu/arm* is already merged into
|
- 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.
|
||||||
|
|
155
README.u2
155
README.u2
|
@ -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
|
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
|
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
|
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
|
about losing support for old boards.
|
||||||
time, stay with the official U-Boot releases.
|
|
||||||
|
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
|
Building U-Boot
|
||||||
|
@ -22,7 +83,8 @@ kernel.
|
||||||
For the examples below, we use the User Mode U-Boot implementation, which
|
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
|
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
|
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
|
Selection of the architecture and the cross compiler can be done in two
|
||||||
ways. You can either specify it using the environment variables ARCH
|
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
|
You can generate an environment using the example environment contained
|
||||||
in examples/environment:
|
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:
|
To get some files to play with you can generate a cramfs image:
|
||||||
# mkcramfs somedir/ cramfs.bin
|
# 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
|
loaded the example environment U-Boot will show you a menu asking for
|
||||||
your settings.
|
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
|
Most of the directory layout is based upon the Linux Kernel:
|
||||||
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
|
|
||||||
|
|
||||||
Shell
|
arch/*/ -> contains architecture specific parts
|
||||||
-----
|
arch/*/mach-*/ -> SoC specific code
|
||||||
|
|
||||||
- doesn't have switch/case yet
|
drivers/serial -> drivers
|
||||||
- only one variable space
|
drivers/net
|
||||||
[ ] add variable space
|
drivers/...
|
||||||
|
|
||||||
Drivers
|
include/asm-* -> architecture specific includes
|
||||||
-------
|
include/asm-*/arch-* -> SoC specific includes
|
||||||
|
|
||||||
/dev
|
fs/ -> filesystem support and filesystem drivers
|
||||||
serial
|
|
||||||
partition
|
|
||||||
environment -> /env; /env/init
|
|
||||||
|
|
||||||
Design
|
lib/ -> generic library functions (getopt, readline and the
|
||||||
------
|
like)
|
||||||
|
|
||||||
include/driver.h
|
common/ -> common stuff
|
||||||
board/scb9328.c
|
|
||||||
include/param.h: each device can have parameters; can be changed on
|
|
||||||
runtime; get/set can be overwritten by implementation.
|
|
||||||
|
|
||||||
- xfunctions: do panic if error
|
commands/ -> many things previously in common/cmd_*, one command
|
||||||
- proposed design:
|
per file
|
||||||
arch/
|
|
||||||
arch/arm/cpu-arm920t/
|
|
||||||
arch/arm/board-.../
|
|
||||||
board/ is obsolete
|
|
||||||
|
|
||||||
- arch/*/Makefile is central makefile
|
net/ -> Networking stuff
|
||||||
|
|
||||||
|
scripts/ -> Kconfig system
|
||||||
|
|
||||||
|
Documentation/ ->
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue