Hi,
On 09/11/17 11:38, Jagan Teki wrote:
> Hi Andre,
>
> On Thu, Nov 9, 2017 at 3:36 AM, André Przywara <andre.przyw...@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.
>>> 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?
Cheers,
Andre.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
