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

[Carsten Schlote]

Hi Wolfgang,

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

It's already prepared. I created a page on my personal wiki for this
issue.
http://www.vahanus.net/~csc/wiki/index.php/U-Boot
I will collect all related ideas on this page as some kind of issue
digest.

I also reworked my patches and pushed everything to my public
repository:
http://www.vahanus.net/~csc/scm/u-boot.git kconfig-001

Forget the old patches I posted before - they are screwed up.

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

Right, the basic idea is fully ok. Unfortunately the standard kconfig
system just creates CONFIG_* defines - there is no way foreseen to
create different prefixes (yet :-) ). Also I got the impression, that
this naming scheme is not used consistently. I currently rework the
problem with some auxiliary header file (autoconf_glues.h), which
translates from CONFIG_* to CFG_* defines. It also does the magic for
the special defines like CONFIG_POST and similiar. This is just a
temporary solution until a common agreement for whatever problem is
found.

> 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) ...

Again, kconfig doesn't allow for plain defines (yet :-) ). But I would
strongly discourage the use of such 'plain' macros, as they can cause
difficult to detect problems and broken code. Maybe it's even the reason
why kconfig doesn't support that... 

The better way would be to have kconfig configuration options for this.
You can select a plain const value like 
#define CONFIG_SYSCLK_FREQ 33000   
 or to choose some additional option, which allows you to change the
define into something like
#define CONFIG_SYSCLK_FREQ <boardname>_GetSysClock()

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

You would specify these values as plain hexvalues in kconfig. Normally
these values never change - the use of a baseaddress macros and offset
for the other membases is just good C programming practice. 

For absolute addresses you can try this with my git branch with the DRAM
or Flash settings - just define more banks to see the effect. This will
define sets of base address and size defines. Of course if this is more
useful, we can also use a base address + offset approach.

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

Yes, there are many examples for creative use of macros in the board
headers :-) But I'm also very creative in finding solution for such
interesting problems :-) There are already some solutions for
problematic macros in my git branch - e.g. CONFIG_COMMANDS is fixed in
cmd_confdef.h. Ok, that's still some easy example.

So without changes to the makefiles and headers it surely won't work.
But everything can be fixed in small steps - and with a good
search&replace tool all references and uses to a specific define can be
changed easily. 

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

I fully agree on this and everything you said here and in the previous
mail.

Regards
  Carsten



____________
Virus checked by G DATA AntiVirusKit
Version: AVKA 17.257 from 28.06.2007
____________
Virus checked by G DATA AntiVirus
Version: AVKB 17.283 from 02.07.2007
Virus news: www.antiviruslab.com