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

[Robert Schwebel]

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