1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
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
|
