[U-Boot] [PATCH v1 0/4] arm: socfgpa: support of-platdata

[Simon Goldschmidt]

On Tue, Jan 8, 2019 at 1:06 PM Marek Vasut <marex at denx.de> wrote:
>
> On 1/8/19 7:56 AM, Simon Goldschmidt wrote:
> > On Mon, Jan 7, 2019 at 11:59 PM Marek Vasut <marex at denx.de> wrote:
> >>
> >> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> >>> This is an initial attempt to support OF_PLATDATA for socfpga gen5.
> >>>
> >>> There are two motivations for this:
> >>> a) reduce code size to eventually support secure boot (where SPL has to
> >>>    authenticate the next stage by loading/checking U-Boot from a FIT
> >>>    image)
> >>> b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM
> >>>    (on warm-restart), all bytes to check need to be in one piece. With
> >>>    OF_SEPARATE, this is not the case (.bss is between .rodata and the
> >>>    DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to
> >>>    be a good solution.
> >>
> >> I'd much prefer parsing the DT (and thus, decoupling the SW from HW)
> >> than having some ad-hoc plat data again if we can avoid that.
> >
> > So you're against the whole OF_PLATDATA thing or how should I understand
> > that?
>
> If we can avoid it, I'd prefer to do so.
>
> > It's not really ad-hoc, it's the DT converted to C structs. It's just in another
> > format, but it's still (sort of) decoupled SW from HW.
> >
> > As written above, I have two goals I want to achieve with this. Right now, I
> > cannot enable verified boot in SPL because the available OCRAM cannot
> > hold all the code. And it seemed to me OF_PLATDATA could help me there.
>
> Well this might be a long shot, but I discussed this lack of OCRAM
> during 35C3 and there was a suggestion to lock L2 cache lines above ROM
> (so there's some backing store) and use that as extra SRAM. Would that
> help you ?

I would have joined that discussion if my Family would have let me go during the
holidays :-))

This is an interesing idea, but actually it's a lack of code/rodata
size. The Intel
docs clearly state that the binary SPL loaded from SPI/MMC must be 60 KiB at
max. I have not checked the code size increase I would get when enabling trusted
boot (SPL loading U-Boot from FIT and verifying it with a public key),
but I'm currently
at ~45 KiB for .text, .rodata and DTB and only 40 bytes for BSS. I'm
booting from SPI.
When booting from MMC, the code is about ~4 KiB smaller but BSS grows to ~600
Bytes.

Of course the stack and initial malloc area do need some bytes too, but I think
summed up, bss, stack and malloc should probably fit into 4 KiB, so I
currently have
about 15 KiB to add FIT loading and public key verification/hashing. I
don't think that's
enough just from the code size.

And on socfpga, I think all added code would use the heap, which is
changed to SDRAM
very early, so it's not the RAM that is tight.


Regards,
Simon