On Tue, Jan 8, 2019 at 1:58 PM Marek Vasut <ma...@denx.de> wrote: > > On 1/8/19 1:38 PM, Simon Goldschmidt wrote: > > On Tue, Jan 8, 2019 at 1:06 PM Marek Vasut <ma...@denx.de> wrote: > >> > >> On 1/8/19 7:56 AM, Simon Goldschmidt wrote: > >>> On Mon, Jan 7, 2019 at 11:59 PM Marek Vasut <ma...@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. > > I wonder if there are some huge chunks of code which could be optimized? > > > 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. > > Can you check readelf and see how the function size looks ? Maybe > there's something which is just too big ?
I'm looking at the map file all the time ;-) The only thing that looks too big is SDRAM initialization, which is about 16 KiB overall, I think. The rest just seems to be smaller parts. But the binary blob u32 arrays created by Quartus don't help, either: rodata is about 9 KiB. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot