Dear Aneesh V,
In message 4DF617C2.6070100@ti.com you wrote:
Console should _always_ be enabled as early as possible,
Unfortunately this is not the case with U-Boot today. Console initialization happens in board_init_f(). Before board_init_f() typically a lot of(in fact most of) low level initialization happens through the lowlevel_init() function called from start.S and the initial part of init_sequence()
As the name LOWLEVEL_init() suggests, this is suppoed to contain always only the bare minimum of initialization that is necessary to get the CPU running. All more complex initializations should be delayed and only be run when we have a proper environment, including debug output on the console.
Can we not rather change the code so both configurations behave the same?
In SPL I had more flexibility, so I do a simplified init of console right at the beginning of lowlevel_init(), so I can use debug prints in lowlevel_init(). Some part of our lowlevel_init() that is executed in SPL path may also be executed by U-Boot if it runs from NOR flash, but in this case console wouldn't be ready. That's why I made the macro.
I do not understand this. How can you have more flexibility in the more restricted environment?
We definitely should unify this.
No. That wouldn't serve the purpose. I need two macros to distinguish between the two cases.
- 'debug()' - can be used in all places at which console is guaranteed
to be initialized whether executed as part of U-Boot or SPL. 2. 'spl_debug()' to be used at places where console is initialized for SPL but not for U-Boot (eg. lowlevel_init()) - so emit no code for U-Boot.
You see - this distinction is becoming a mess. Let's get rid of this and use common code for both cases.
Best regards,
Wolfgang Denk