[U-Boot] [PATCH] SPL: sunxi: don't force .BSS into DRAM

From: Hans de Goede <hdegoede@redhat.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] SPL: sunxi: don't force .BSS into DRAM
Date: Sat, 2 Jul 2016 13:49:52 +0200	[thread overview]
Message-ID: <cf2cbbaa-8e8a-dc97-cd0c-6c11061630c0@redhat.com> (raw)
In-Reply-To: <CAPnjgZ2ajoU90kSNMoHVhbXN4CdeKzs5-SQ-Hq-xePfC0brJ3A@mail.gmail.com>

Hi,

On 30-06-16 17:24, Simon Glass wrote:
> Hi,
>
> On 30 June 2016 at 03:00, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi Andre,
>>
>> On 30-06-16 02:25, Andre Przywara wrote:
>>>
>>> Probably due to some (ill-founded) fear of a large BSS all sunxi boards
>>> forced their SPL BSS section into DRAM.
>>> This only works if there is no usage of a .BSS variable before the DRAM
>>> is initialised.
>>> The recent inclusion of tiny-printf breaks this assumption (it has two
>>> variables in .BSS), so any early printf (printing a number) hangs a board.
>>> This in particular breaks the (WIP) Pine64 SPL, which at the moment links
>>> Allwinner's libdram library, trying to print debug information:
>>> DRAM:DRAM driver version: V1.0
>>> DRAM Type = <hangs>
>>
>>
>> Hmm, although 256 bytes is not a lot I would prefer for BSS to stay in
>> DRAM, esp. since the bss use may grow over time, and the SPL space is quite
>> small.
>>
>> Moreover, given that tiny-printf is specifically meant for use in SPL /
>> restricted environments and having BSS in DRAM is not unheard of for
>> other boards, it seems to me like this is something which should really
>> be fixed in tinyprintf instead.
>>
>> Have you tried looking into fixing this at the tinyprintf level ?
>
> Marek's fix is one option. Another is to make use of global_data,
> which will be available from very early and it set to zero.

I think Marek's fix is fine, we should go and merge that.

As for the worries about not using BSS before DRAM is initialized
coming back to bite us. Yes that may happen, but we are not the
only board / mach / soc code to do this. I agree that documenting
this somewhere would be good (patches welcome).

As for just putting BSS in the sram, nack. Thanks to various efforts
we currently have some free space for the SPL, but in the future
we will likely add NAND support, and try to move the SPL to
dm (with static device instantiation, no space for dt) so that we
can get rid of the duplicate non-dm + dm gpio and uart code we
currently have. These things combined will push things to their
limit and may very well grow the BSS section too.

Regards,

Hans