diff mbox series

[U-Boot] arm: socfpga: fix CONFIG_SPL_MAX_SIZE (less than SRAM)

Message ID 4149c595-169b-3479-e9d2-2d0a89724ecf@de.pepperl-fuchs.com
State Rejected, archived
Delegated to: Marek Vasut
Headers show
Series [U-Boot] arm: socfpga: fix CONFIG_SPL_MAX_SIZE (less than SRAM) | expand

Commit Message

Simon Goldschmidt May 14, 2018, 9:02 p.m. UTC
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.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
---
  include/configs/socfpga_common.h | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

Comments

Marek Vasut May 14, 2018, 9:03 p.m. UTC | #1
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 ?
Simon Goldschmidt May 15, 2018, 7:14 a.m. UTC | #2
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...

Simon
Marek Vasut May 15, 2018, 9:14 a.m. UTC | #3
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?
Simon Goldschmidt May 15, 2018, 10:21 a.m. UTC | #4
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
Marek Vasut May 15, 2018, 10:30 a.m. UTC | #5
On 05/15/2018 12:21 PM, Simon Goldschmidt wrote:
> 
> 
> 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?

4k is fine, but on A10 it's not 56k is it ?
Simon Goldschmidt May 15, 2018, 10:37 a.m. UTC | #6
On 15.05.2018 12:30, Marek Vasut wrote:
> On 05/15/2018 12:21 PM, Simon Goldschmidt wrote:
>>
>>
>> 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?
> 
> 4k is fine, but on A10 it's not 56k is it ?

I really don't know. I don't have access to an A10, so I cannot even 
test this. Maybe someone at Intel can shed some light on this? Also, I 
wouldn't think the boot ROM needs 56k on that platform...

So how do we proceed? If the Cyclone5/Arria5 limit of 60KB is 
acceptable, I can send a V2 with A10 left like it was...

Simon
Marek Vasut May 15, 2018, 10:48 a.m. UTC | #7
On 05/15/2018 12:37 PM, Simon Goldschmidt wrote:
> 
> 
> On 15.05.2018 12:30, Marek Vasut wrote:
>> On 05/15/2018 12:21 PM, Simon Goldschmidt wrote:
>>>
>>>
>>> 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?
>>
>> 4k is fine, but on A10 it's not 56k is it ?
> 
> I really don't know. I don't have access to an A10, so I cannot even
> test this. Maybe someone at Intel can shed some light on this? Also, I
> wouldn't think the boot ROM needs 56k on that platform...

I have it on my desk, ES2, but anyway ... 56k looks nonsensical.

> So how do we proceed? If the Cyclone5/Arria5 limit of 60KB is
> acceptable, I can send a V2 with A10 left like it was...

I am CCing Dinh/Chin/Chee. See what they have to say about this.
I think for CV, 60k is fine, although I think it might trigger size
limit problems on CV SoCDK.
diff mbox series

Patch

diff --git a/include/configs/socfpga_common.h 
b/include/configs/socfpga_common.h
index 4de2aa7929..bf7014064a 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -31,9 +31,12 @@ 
  #if defined(CONFIG_TARGET_SOCFPGA_GEN5)
  #define CONFIG_SYS_INIT_RAM_ADDR	0xFFFF0000
  #define CONFIG_SYS_INIT_RAM_SIZE	0x10000
+#define CONFIG_SPL_MAX_SIZE		0xF000 /* 60KB */
+
  #elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
  #define CONFIG_SYS_INIT_RAM_ADDR	0xFFE00000
  #define CONFIG_SYS_INIT_RAM_SIZE	0x40000 /* 256KB */
+#define CONFIG_SPL_MAX_SIZE		0x32000 /* 200KB */
  #endif
  #define CONFIG_SYS_INIT_SP_OFFSET		\
  	(CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE)
@@ -254,7 +257,6 @@  unsigned int cm_get_qspi_controller_clk_hz(void);
   * 0xFFFF_FF00 ...... End of SRAM
   */
  #define CONFIG_SPL_TEXT_BASE		CONFIG_SYS_INIT_RAM_ADDR
-#define CONFIG_SPL_MAX_SIZE		CONFIG_SYS_INIT_RAM_SIZE

  /* SPL SDMMC boot support */
  #ifdef CONFIG_SPL_MMC_SUPPORT