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@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