[U-Boot] SUNXI: A64: Increase SPL size

[Jagan Teki]

On Thu, Nov 9, 2017 at 5:23 PM, Andre Przywara <andre.przywara at arm.com> wrote:
> Hi,
>
> On 09/11/17 11:38, Jagan Teki wrote:
>> Hi Andre,
>>
>> On Thu, Nov 9, 2017 at 3:36 AM, André Przywara <andre.przywara at arm.com> wrote:
>>> On 08/11/17 19:59, Jagan Teki wrote:
>>>> Hi,
>>>>
>>>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
>>>> able to fit new features like falcon. I knew the limit about 32K but
>>>> page[1] stating that we can use approximately 192 KiB of contiguous
>>>> SRAM.
>>>
>>> We are not really sure about this. The memory following SRAM A1 is
>>> called SRAM C (not A2, that is secure memory at 0x44000). And this is
>>> actually meant for use by the DisplayEngine, AFAIK. We found it unstable
>>> to use from the ARM cores. With the default config is it not even
>>> covering the whole region as described in the manual.
>>
>>>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>>>
>>> Well, how? As far as I know the *BROM* does not load more than 32KB, at
>>> least not with the ("un-encrypted") eGON.BT0 format. Or could you
>>> actually load more code?
>>
>> Yes, I've 40K SPL start from sector 16 of SD Since BROM load 32KB to
>> A1 and I had an impression of using SRAM C for > 32KB. So BROM only
>> have an access to A1 (not any other SRAM's like SRAM C) we can't
>> increase the SPL size > 32KB..this is strict. correct?
>
> It's not so much about BROM not having access to SRAM C, it's just not
> doing it. That's a design decision made by Allwinner, and since it's
> ROM, we can't do anything about it.
>
>>>
>>> I *think* we can load more with the "secure" payload, which requires the
>>> "secure boot" fuse to be burned (with no return), which in turn will let
>>> the BROM refuse to load a standard eGON.BT0 Boot0/SPL, but only the
>>> secure packaged version (TOC0): http://linux-sunxi.org/TOC0
>>
>> Did you try this? if yes please point the same.
>
> I tried TOC0 on a Pine64 where I burnt the fuse. But I didn't try to
> load more than 32KB. Anyway I don't believe it's an option for you,
> since it's an revocable change to the SoC (it's a one-time fuse).
> I guess you don't want to force that on your customer's boards.

I've few dev boards, may be I can try > 32KB can you point me the link
or source about this?

>>>> because I've tried with 64K SPL size with existing SPL code and was
>>>> able to boot, but with increasing SPL by enabling falcon seems like
>>>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>>>
>>> So why do you need falcon, desperately? You can put the kernel into the
>>> SPL FIT image (u-boot.itb), then have the U-Boot proper just execute
>>> booti (no further loading). That works from SPI flash, also. If you are
>>> really want to, you can disable USB, Ethernet and the timeout and save
>>> some time here. But those are .config options and shouldn't require code
>>> changes.
>>
>> Falcon make direct Linux boot, from SPL. we can skip U-Boot, (even
>> ATF). I'm not using USB, ethernet on SPL so current code look fit with
>> what SPL wants.
>
> I understand that, my question was: What does Falcon give you to justify
> all the hacking and the pain you go through? Why can't you just go the
> normal way and trim U-Boot proper to not waste time?

Yes, we can trim the U-Boot proper but my idea is to skip it so-that
we can achieve better boot-time. I've seen better boot-time numbers
with other SOC.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.