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

[Wolfgang Denk]

Dear Carsten,

in message <1183243336.3233.90.camel at loki> you wrote:
> 
> Fine to hear that you guys work on it ;-) I asked about two week ago on
> this list, if there is any on-going project. And as I didn't get any
> answer, I simply did my own experiments. 

THanks!

> My own U-Boot target is using kconfig already, and porting further
> platforms from the old to the new system should be straight forward -
> just start 'make menuconfig' and answer all question from top down (No
> it's nmot complete yet... but easy to extend now.) And you can always
> switch back in case it doesn't work.

Sounds good - what about showing what you have? If you want, we can
create a branch for this stuff...

> While doing these modification I found many 'problems' with the existing
> build system, which either need to be worked around (CFG_ style defines)

Can you please explain what these problems were? It would be nice if
the new config system could keep the concept of different levels of
configuration options (CONFIG_ being selections that can be made more
or less as you like, i. e. things to select or deselect features or
to change behaviour or defaults, while CFG_ are supposed to be
settings needed to adapt (port) U-Boot to that specific hardware
platform, i. e. these should never be touched by a "normal" user, but
only by the board maintainer that understands the underlying
hardware.

> or to be fixed the real way. There are also many things which could be
> simplified with kconfig. Although this will take some time, it is
> possible to migrate the current U-Boot configuration this way.

I would like to know how you delt for example with situations where a
config file setting refers to other config options or even inline
code, for example like these:

#define CONFIG_SYS_CLK_FREQ    ((in8(CFG_BCSR_BASE + 3) & 0x80) ? \
                                33333333 : 33000000)
...
#define CFG_PCI_MEMBASE         0x80000000      /* mapped pci memory    */
#define CFG_PCI_MEMBASE1        CFG_PCI_MEMBASE  + 0x10000000
#define CFG_PCI_MEMBASE2        CFG_PCI_MEMBASE1 + 0x10000000
#define CFG_PCI_MEMBASE3        CFG_PCI_MEMBASE2 + 0x10000000
...
#define CFG_ENV_SECT_SIZE       0x20000 /* size of one complete sector          */
#define CFG_ENV_ADDR            ((-CFG_MONITOR_LEN)-CFG_ENV_SECT_SIZE)
#define CFG_ENV_SIZE            0x2000  /* Total Size of Environment Sector     */
...
#define CFG_ENV_ADDR_REDUND     (CFG_ENV_ADDR-CFG_ENV_SECT_SIZE)
#define CFG_ENV_SIZE_REDUND     (CFG_ENV_SIZE)

[Examples taken from include/configs/sequoia.h]

> So when can we access a first draft of u-boot-ng? I would like to have a
> look on it. Maybe there is some way to allow users of u-boot to migrate
> smoothly to the new system.

That would be indeed appreciated.

> It would be a pitty to have two bootloader projects covering the same
> targets. People would start to work on the one or other project, instead
> of focusing their efforts on a single solution.

Even if these efforts get merged somehow later, there is a pretty big
danger of wasting resources by duplicating efforts.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I think animal testing is a terrible idea; they get all  nervous  and
give the wrong answers.