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

[Simon Goldschmidt]

Am 08.01.2019 um 15:43 schrieb Marek Vasut:
> On 1/8/19 2:51 PM, Simon Goldschmidt wrote:
>> On Tue, Jan 8, 2019 at 2:38 PM Marek Vasut <marex at denx.de> wrote:
>>>
>>> On 1/8/19 2:07 PM, Simon Goldschmidt wrote:
>>>> On Tue, Jan 8, 2019 at 1:58 PM Marek Vasut <marex at denx.de> wrote:
>>>>>
>>>>> On 1/8/19 1:38 PM, Simon Goldschmidt wrote:
>>>>>> 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.
>>>>>
>>>>> 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.
>>>
>>> Can that be somehow optimized ? The ideal approach would be to move it
>>> somehow to DT.
>>
>> I don't know if those binary blobs (pin config, clock config etc.) can
>> be converted
>> without internal information from Intel.
>>
>> The SDRAM initialization might just be bad code, I don't know.
>>
>> So like you wrote in the other thread: obviously, we're doing something wrong
>> as those 60 KiB will not be enough for what I want SPL to do. But, I haven't yet
>> found something that is just obviously code bloat.
> 
> I wonder if the SDRAM init tables aren't a bit sparse for example. Maybe
> something can be done there ?

I'll drop this series. There are some more cleanups in SPL to do before 
I'll be working on platdata again and this one won't apply any more 
after those changes are done.


Regards,
Simon