From mboxrd@z Thu Jan  1 00:00:00 1970
From: Simon Glass <sjg@chromium.org>
Date: Sun, 3 Jul 2016 15:15:55 -0600
Subject: [U-Boot] [PATCH] SPL: sunxi: don't force .BSS into DRAM
In-Reply-To: <cf2cbbaa-8e8a-dc97-cd0c-6c11061630c0@redhat.com>
References: <20160630002500.2817-1-andre.przywara@arm.com>
 <af86054b-8fcc-3b58-6889-7af02cd7a9fc@redhat.com>
 <CAPnjgZ2ajoU90kSNMoHVhbXN4CdeKzs5-SQ-Hq-xePfC0brJ3A@mail.gmail.com>
 <cf2cbbaa-8e8a-dc97-cd0c-6c11061630c0@redhat.com>
Message-ID: <CAPnjgZ0DSXxsCtJ2aahbTFV23QW0K1asciYwvFXTi+XLnuSgQw@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Hans,

On 2 July 2016 at 04:49, Hans de Goede <hdegoede@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@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