[U-Boot] [PATCH] am33xx, spl, siemens: enable debug uart output again

[Heiko Schocher <hs@denx.de>]

Hello Tom,

Am 02.03.2015 14:59, schrieb Tom Rini:
> On Mon, Mar 02, 2015 at 07:56:41AM +0100, Heiko Schocher wrote:
>> Hello Simon,
>>
>> Am 24.02.2015 14:31, schrieb Simon Glass:
>>> Hi Heiko,
>>>
>>> On 23 February 2015 at 23:18, Heiko Schocher <hs@denx.de> wrote:
>>>> a6b541b090: TI ARMv7: Don't use GD before crt0.S has set it
>>>>
>>>> moves the init of the debug uart at the very end of SPL code.
>>>> Enable it for the siemens board earlier, as they print
>>>> ddr settings ... all debug output before board_init_r()
>>>> is here currently useless. Maybe we must rework this
>>>> globally?
>>>
>>> Assuming we are talking about U-Boot proper, the DDR init should
>>> happen in board_init_f(), specifically dram_init(). so I think this
>>> code should be updated.
>>>
>>> If it is SPL, then DDR init should happen in SPL's board_init_f().
>>
>> It is in SPL...
>>
>> sdram_init() is called from:
>>
>> ./arch/arm/cpu/armv7/am33xx/board.c from s_init() ...
>>
>>> I sent a series a few weeks ago (available at u-boot-dm branch
>>> spl-working) related to this topic:
>>>
>>> http://patchwork.ozlabs.org/patch/438581/
>>
>> Ah ... Hmm... so "./arch/arm/cpu/armv7/am33xx/board.c" needs
>> a rework, right?
>>
>> Is a simple rename s_init() -> board_init_f() correct?
>
> Right so, no, we can't just rename s_init to board_init_f.  This is what
> I was talking about in the thread about the function Hans wants to add
> to enable some bits in CP15 on sunxi, iirc.
>
> In short, armv7 has a different set of abstraction hooks than the
> previous ARM cores (armv8 followed what we have for v7) and I'm not
> convinced in the end that it really won us anything.  See
> http://lists.denx.de/pipermail/u-boot/2015-January/202350.html
>
> For today you need to rework the Siemens code to print out the DDR
> values (when desired) in spl_board_init() as we do not, or will not
> shortly, have gd prior to board_init_f running.

Hmm... first I thought, ok, no problem, move the output from the RAM
parameters to spl_board_init() ... but thats only the half of the
story ... They read the RAM parameters from an i2c eeprom, and if
there are errors, they print this errors ... currently this does
not work, and thats I think the more important case ... and I could
not move this error printfs to somewhere, because if RAM is not
working ... there is no later ...

So I have to enable the console early ... maybe I missed something,
but this worked fine in the past (and I think we should not break
this, as this is an essential feature).

If I look into arch/arm/cpu/armv7/am33xx/board.c s_init()
there gets the console also in the case:

#if defined(CONFIG_NOR_BOOT) || defined(CONFIG_QSPI_BOOT)

very early enabled ... is this buggy?

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany