In message 8D7C5F56B409554D9D46AC22195807F3061B3B@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