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

[Heiko Schocher <hs@denx.de>]

Hello Tom,

Am 04.03.2015 17:40, schrieb Tom Rini:
> On Wed, Mar 04, 2015 at 08:42:58AM +0100, Heiko Schocher wrote:
>> 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).
>
> OK, I missed something too.  I think this gets better now once I merge
> Simon's SPL series as we do all of this from board_init_f() and the
> siemens code should just work again.

Yes, just saw your patch ;-)

If they are in mainline (or do you have them somewhere in a git repo?),
I test it again on the dxr2 board, thanks!

>> 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?
>
> Digging out one of the QSPI bootable boards (which I only _think_ I
> have) or setting up and confirming the beaglebone white + NOR cape I
> have still functions at the HW level and then re-testing on mainline are
> on my list as yes, I'm a bit worried these paths might be broken again.
>

Thanks for the info!

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