[U-Boot] [PATCH 06/12 v2] arm: at91: Enable watchdog support

[Heiko Schocher]

Hello Simon,

Am 01.04.2019 um 11:13 schrieb Simon Goldschmidt:
> On Mon, Apr 1, 2019 at 7:41 AM Heiko Schocher <hs at denx.de> wrote:
>>
>> Hello Wolfgang,
>>
>> added Simon Goldschmidt to cc, as he just posted a patchset, which
>> exactly wants to introduce "clear BSS before relocation" ...
>>
>> Am 29.03.2019 um 13:06 schrieb Wolfgang Denk:
>>> Dear Heiko,
>>>
>>> In message <81e69dec-21e7-7b34-a261-e22ae9bef795 at denx.de> you wrote:
>>>>
>>>> The big question is, how many places do we have in code, where we access
>>>> BSS before relocation ?
>>>
>>> Hopefully none.
>>
>> Hmm... Hopefully, but I think, not easy to detect when reviewing
>> patches ... I just stumbeld over this issue in this patch from
>> Stefan, because I could try it on a hardware, and my hardware doesn;t
>> boot with this patch...
>>
>> Theoretically you must check all vars, which are in BSS segment, if
>> they are used before relocation ... and drop an error, no idea yet,
>> how to detect this at compile time ...
>>
>>>> May we better clear BSS very early (at last may possible on arm)?
>>>
>>> You cannot.  There is no storage allocated for BSS - this happens
>>> only during relocation, and then it also gets zeroed.
>>
>> Yes, valid for the boards which have no SPL ... but if U-Boot is
>> loaded with SPL into RAM, BSS is writeable. But as this is not
>> valid for all boards, we cannot do this!
>>
>> Just see the patches from Simon:
>>
>> https://lists.denx.de/pipermail/u-boot/2019-March/361452.html
>>
>> http://patchwork.ozlabs.org/patch/1067363/
>>
>> Same problem ...
> 
> OK, so the word stands "BSS is not used before relocation". Like already
> mentioned, we don't have a check that tells us when this rule is
> violated. Being like
> that, I would be surprised if such a check (if added) would yield zero
> failures...

Hmm... I hope not.

> However, I'm not sure what "relocation" means for SPL boards where the SPL is
> loaded into SRAM (as is the case on many ARM boards at least). The correct
> wording here might be "RAM available" or something like that, instead
> of "relocation".

In case of SPL ... there is no code relocation and "after relocation"
is equivalent to "RAM available".

> With this definition, a new question arises: how can I be forced to
> provide a malloc
> implementation in "pre-reloc" phase (for pre-reloc driver model, e.g.
> drivers for serial
> and SDRAM) when people keep telling me bss might not even be available?
> That sounds a bit confusing to me.

But Simon Glass suggestion to put all variables dlmalloc needs into
a struct and put a pointer into GD should solve this problem, or?

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de