[U-Boot-Users] lkc support for U-Boot My $0.02 worth

[Wolfgang Denk]

In message <8D7C5F56B409554D9D46AC22195807F3061B3B at exchwenz01.dmcwave.co.nz> you wrote:
> 
> I know progress is a thing that cannot be stopped and change is sometimes
> positive.  But my preference is that we stick with the make file
> configuration approach.  It is small easy to add new configurations of
> either boards or CPUs.  What is more when starting out it is easy to follow
> what is going on with a make file I maybe an old dog who doesn't like change
> but...
> 
> 				if it isn't broken why fix it?

Because U-Boot claims to be easily portable. And I can understand the
argument that a configuration menu that guides you  through  all  the
questions might be useful.

One of my definitive requiterementes is that  the  Makefile  approach
must  not  change  significantly;  only  the  way  how we get a board
specific config header file will change.


Well, I don;t need such a change  for  myself  -  I'm  probably  much
faster  to  clone an existent port - we've done enough of them that I
will always find one close enough :-) But this does not mean I should
reject new ideas.

I still see technical issues; for example, I have not  the  slightest
idea how longish definitions like:

#define CONFIG_EXTRA_ENV_SETTINGS                                               \
        "kernel_addr=40040000\0"                                                \
        "ramdisk_addr=40100000\0"                                               \
        "magic_keys=#3\0"                                                       \
        "key_magic#=28\0"                                                       \
        "key_cmd#=setenv addfb setenv bootargs \\$(bootargs) console=tty0\0"    \
        "key_magic3=24\0"                                                       \
        "key_cmd3=echo *** Entering Test Mode ***;" \
                "setenv add_misc setenv bootargs \\$(bootargs) testmode\0"      \
        "nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=$(serverip):$(rootpath)\0" 
\
        "ramargs=setenv bootargs root=/dev/ram rw\0"                            \
        "addfb=setenv bootargs $(bootargs) console=ttyS1,$(baudrate)\0"         \
        "addip=setenv bootargs $(bootargs) "                                    \
                "ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname)::off " 
\
                "panic=1\0"                                                     \
        "add_wdt=setenv bootargs $(bootargs) $(wdt_args)\0"                     \
        "flash_nfs=run nfsargs addip add_wdt addfb;"            \
                "bootm $(kernel_addr)\0"                                        \
        "flash_self=run ramargs addip add_wdt addfb;"           \
                "bootm $(kernel_addr) $(ramdisk_addr)\0"                        \
        "net_nfs=tftp 100000 /tftpboot/pImage.lwmon;"           \
                "run nfsargs addip add_wdt addfb;bootm\0"       \
        "rootpath=/opt/eldk/ppc_8xx\0"                                          \
        "load=tftp 100000 /tftpboot/u-boot.bin\0"                               \
        "update=protect off 1:0;era 1:0;cp.b 100000 40000000 $(filesize)\0"     \
        "wdt_args=wdt_8xx=off\0"                                                \
        "verify=no"


can be handled in a readable way, if at all. Things like that.  Also,
I  fear  that  adding new features will become much harder, as you'll
have to continually extend  the  config  setup.  And  finally  -  has
anybody  benchmarked the speed of such a new config scheme? Running a
MAKEALL over all PPC and ARM boards takes a considerable time already
now. I don't really want to add to build time...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
See us @ electronica 2002 in Munich, Nov 12-15, Hall A3, Booth A3.325