Hello Simon,
Am 01.04.2019 um 11:13 schrieb Simon Goldschmidt:
On Mon, Apr 1, 2019 at 7:41 AM Heiko Schocher <h...@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-e22ae9bef...@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: h...@denx.de
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
