[U-Boot] [PATCH] arm: socfpga: fix CONFIG_SPL_MAX_SIZE (less than SRAM)
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(-)
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
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 ?
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
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?
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
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 ?
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
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.
participants (2)
-
Marek Vasut -
Simon Goldschmidt