[U-Boot-Users] U-Boot-NG ?

Robert Schwebel
2007-06-30T09:40:23Z

Hi Wolfgang,

On Fri, Jun 29, 2007 at 10:08:50PM -0400, Wolfgang Denk wrote:
> Robert mentioned that you were working on a "U-Boot Next Generation"
> project, and that you were actually pretty far with this. He also
> said that you were addressing a few issues where discussions and/or
> actual work is going on, like using some configuration tool
> (Kconfig?) or creating a more generic device driver interface.

Yes, that's right.

> It would be nice if you could disclose what you are working on and
> discuss it here in public, before the design is cast in stone, so
> others can contribute ideas and/or code, give hints and comments
> and/or raise their concerns.

We'll do soon. The idea behind that activities (at the moment codenamed
"u2boot", but we'll definitely aim at contributing that work into the
u-boot community as a proposal for next-generation) is that, due to
u-boot's very impressive long term stability and maintenance politics,
it is relatively difficult to change fundamental things in a clean way,
because you cannot do this while ensuring that all boards do still work.

The idea would be that u2boot is a technology playground for new u-boot
backend mechanics; existing board supports would have to be ported to
the new code base, to make sure the new code isn't cluttered by things
from the past. Nevertheless, u2boot is based on the u-boot code and
re-uses quite a lot of it. Think of it like "u-boot without the
problems".

So here's a short and incomplete list of what Sascha has implemented so
far:

- Kbuild makefiles, including parallel build support:

rsc at octopus:~/work-octopus/svn/u2boot/u2boot-trunk> time make -j 16
[...]
GEN .version
LD uboot
objcopy -O binary uboot uboot.bin
objdump -d uboot > uboot.S
SYSMAP System.map

real 0m1.819s
user 0m5.020s
sys 0m1.664s

- Kconfig configuration system, stolen from Linux.

- Clean arch/{arm,powerpc,...} hardware abstraction, also stolen
from linux.

- Driver model, also stolen from you-know-where, but much simpler
because of the no-interrupts policy. All "things" live in devices and
drivers, have an abstract concept of "properties". This makes it
possible to throw away all that special cases for multiple devices,
like ethaddr vs. eth1addr.

- File system concept: wanna access scripts? Put them into a filesystem.
As we are living on a very small environment, filesystems can be as
simple as a linear list in memory, but they follow the driver model.

- Wanna edit your favourite script on the device? No problem, there is
an integrated full screen editor.

- user-mode-uboot: you can build for arch/linux, resulting in a normal
Linux binary which can be started on the command line, to test
U-Boot's functionality. It can cope with tun/tap network devices,
so it even can do things like tftp etc...

- Follows a "posix-god-where-is-the-difference" and
"everything-is-a-file" politics. Wanna do scripting? No need to
mis-use an environment for that. Do it the natural way - with scripts
which live in a file system. Nevertheless, the concept of environment
for parameters is still there, but in a more sophisticated way.

- Follows an "ifdefs-are-evil" politics; do things abstract and do them
in centralized places.

Plus more goodies all over the place.

All that does already work; what we'll have to do before a first public
RFC on this list is to clean up the code (it is not obvious which part
of the code is old and which one is new), do some auditing for
non-operational commands, add some README and review the initial code
base for coding style.

So please be patient for some days - I'll promise you that it's
definitely worth it :-)

Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9