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

[Simon Glass]

Hi Hans,

On 2 July 2016 at 04:49, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
>
> On 30-06-16 17:24, Simon Glass wrote:
>>
>> Hi,
>>
>> On 30 June 2016 at 03:00, Hans de Goede <hdegoede at 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.

FWIW dm is designed to avoid using BSS. Also if it helps, see my
series which converts the DT to C data structures.

Regards,
Simon