On 23.12.2010 12:58, Andreas Bießmann wrote: > Dear Jens Scharsig, > > Am 18.12.2010 um 13:08 schrieb Jens Scharsig: > >> * remove LED initialization in front of relocation and bss init >> >> Signed-off-by: Jens Scharsig<js_at...@scharsoft.de> >> --- >> >> * prevents run C function on an uninitialized environment > > You are right, we do not have stack/bss setup when we call these two > c-functions. > > But in that case it is ok to do so cause we do just pc relative accesses > here, do not use bss variables and last we do not use the stack. > > Beside the fact that we could use it here as it is done since atmel posted > their at91rm9200 code we could ask if we need it or not. > > I think it is a nice helper for initialisation debugging and I used it from > time to time for my relocation investigations. But I think we do _not_ need > it in every arm920t/at91 board for every bootup. > It should be > a) enclosed in some ifdef to enable them conditionally on compile time > b) documented in a README and completely removed (some lines later too) > > Beside that one could state > c) completely removed (the whole coloured_LED stuff) as this is atmel > specific and other SoC use another interface to switch LED > if we decide to not use these LED features for bootup debugging. > > AFAIK this is also used in arm926ejs (at91sam only), Reinhard can you please > comment on that?
Quite funny, incidentally right this morning I tried to figure out how to use LEDs to assist a "blackbox" sort of system that has only 3 RG LEDs to signal u-boot phases and errors before kernel and application are ultimately started. This part of u-boot is quite messy, look at "status_led.h" for example... I agree the AT91 colored LED specialty should be removed, once we can agree on a useful common LED approach. And I think that should be working the other way. It is pointless to try to factorize it into a few LEDs with specific meanings. We should have one function like "show_status(int status)" with various statuses defined like: LED_STATUS_RESET, _BEFORE_RELOC, _AFTER_RELOC, _SENT_DHCP, _STARTING_KERNEL, _CRASHED, ... Then it is up to the board specific code to drive multicolored LEDs, an LCDisplay, some seven-segment displays or even relais. But I guess that's too futuristic, and as always there is a lot of existing code that does it in various different ways :( Best Regards, Reinhard _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
