[U-Boot] [PATCH] arm: socfpga: fix CONFIG_SPL_MAX_SIZE (less than SRAM)
Simon Goldschmidt
sgoldschmidt at de.pepperl-fuchs.com
Tue May 15 10:21:48 UTC 2018
On 15.05.2018 11:14, Marek Vasut wrote:
> On 05/15/2018 09:14 AM, Simon Goldschmidt wrote:
>>
>>
>> On 14.05.2018 23:03, Marek Vasut wrote:
>>> On 05/14/2018 11:02 PM, Simon Goldschmidt wrote:
>>>> The boot ROMs of the socfpga platform limit the size of the
>>>> SPL to copy to less than the available SRAM.
>>>> (See "Intel SoC FPGA Embedded Development Suite User Guide")
>>>>
>>>> According to this document, Cyclone V and Arria V allow 60KB
>>>> maximum while Arria 10 allows 200KB. In both cases, this is
>>>> less than CONFIG_SYS_INIT_RAM_SIZE.
>>>
>>> Do they really copy less ?
>>
>> Well, their own tool errors out if the binary is larger than this. And
>> the documentation says the boot ROM needs some RAM, at least when
>> copying from QSPI. And since the bootcounter stored at the end of SRAM
>> sometimes survives a cold boot on one of my boards, they certainly don't
>> always copy 64KB.
>>
>> In the end, I don't know how 'hard' that restriction is, but if they say
>> so in the documentation, I think it's better to error out than to have a
>> system that does not start any more...
>
> Would it be too much to ask if you could poison the SRAM with some
> pattern, trigger a cold reset and see how much of it got corrupted?
The part of checking how much got corrupted is a bit hard since both SPL
and U-Boot use this part of the SRAM. I'll see what I can do.
But in the end, this will only be valid for my chip (cyclone5). Others
*might* be different. It might even depend on boot source. I know losing
4KB at the end is not nice, but then again, the check I've changed only
checks from start of text to end of bss, which leaves us 4KB stack at
runtime. I think that's OK, isn't it?
Simon
More information about the U-Boot
mailing list