* [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5
@ 2019-06-13 19:50 Simon Goldschmidt
2019-06-13 20:14 ` Marek Vasut
0 siblings, 1 reply; 10+ messages in thread
From: Simon Goldschmidt @ 2019-06-13 19:50 UTC (permalink / raw)
To: u-boot
This provides an SPL_SIZE_LIMIT that makes the build check that the SPL
binary loaded from flash fits into the SRAM (64 KiB) and leaves enough
room for global data, heap and stack (512 bytes assumed stack usage).
Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
---
arch/arm/mach-socfpga/Kconfig | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 48f02f08d4..1d914648e3 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -3,6 +3,12 @@ if ARCH_SOCFPGA
config NR_DRAM_BANKS
default 1
+config SPL_SIZE_LIMIT
+ default 65536 if TARGET_SOCFPGA_GEN5
+
+config SPL_SIZE_LIMIT_PROVIDE_STACK
+ default 0x200 if TARGET_SOCFPGA_GEN5
+
config SPL_STACK_R_ADDR
default 0x00800000 if TARGET_SOCFPGA_GEN5
@@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
bool
select SPL_ALTERA_SDRAM
imply FPGA_SOCFPGA
+ imply SPL_SIZE_LIMIT_SUBTRACT_GD
+ imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
imply SPL_STACK_R
imply SPL_SYS_MALLOC_SIMPLE
imply USE_TINY_PRINTF
--
2.20.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5
2019-06-13 19:50 [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5 Simon Goldschmidt
@ 2019-06-13 20:14 ` Marek Vasut
2019-06-13 20:26 ` Simon Goldschmidt
0 siblings, 1 reply; 10+ messages in thread
From: Marek Vasut @ 2019-06-13 20:14 UTC (permalink / raw)
To: u-boot
On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
> This provides an SPL_SIZE_LIMIT that makes the build check that the SPL
> binary loaded from flash fits into the SRAM (64 KiB) and leaves enough
> room for global data, heap and stack (512 bytes assumed stack usage).
>
> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
> ---
>
> arch/arm/mach-socfpga/Kconfig | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
> index 48f02f08d4..1d914648e3 100644
> --- a/arch/arm/mach-socfpga/Kconfig
> +++ b/arch/arm/mach-socfpga/Kconfig
> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
> config NR_DRAM_BANKS
> default 1
>
> +config SPL_SIZE_LIMIT
> + default 65536 if TARGET_SOCFPGA_GEN5
> +
> +config SPL_SIZE_LIMIT_PROVIDE_STACK
> + default 0x200 if TARGET_SOCFPGA_GEN5
> +
> config SPL_STACK_R_ADDR
> default 0x00800000 if TARGET_SOCFPGA_GEN5
>
> @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
> bool
> select SPL_ALTERA_SDRAM
> imply FPGA_SOCFPGA
> + imply SPL_SIZE_LIMIT_SUBTRACT_GD
> + imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
> imply SPL_STACK_R
> imply SPL_SYS_MALLOC_SIMPLE
> imply USE_TINY_PRINTF
>
512 bytes for stack looks like it's too little. I think the SPL started
misbehaving when it overgrew 50 kiB, no ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5
2019-06-13 20:14 ` Marek Vasut
@ 2019-06-13 20:26 ` Simon Goldschmidt
2019-06-13 20:39 ` Marek Vasut
0 siblings, 1 reply; 10+ messages in thread
From: Simon Goldschmidt @ 2019-06-13 20:26 UTC (permalink / raw)
To: u-boot
On 13.06.19 22:14, Marek Vasut wrote:
> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
>> This provides an SPL_SIZE_LIMIT that makes the build check that the SPL
>> binary loaded from flash fits into the SRAM (64 KiB) and leaves enough
>> room for global data, heap and stack (512 bytes assumed stack usage).
>>
>> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
>> ---
>>
>> arch/arm/mach-socfpga/Kconfig | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
>> index 48f02f08d4..1d914648e3 100644
>> --- a/arch/arm/mach-socfpga/Kconfig
>> +++ b/arch/arm/mach-socfpga/Kconfig
>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
>> config NR_DRAM_BANKS
>> default 1
>>
>> +config SPL_SIZE_LIMIT
>> + default 65536 if TARGET_SOCFPGA_GEN5
>> +
>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
>> + default 0x200 if TARGET_SOCFPGA_GEN5
>> +
>> config SPL_STACK_R_ADDR
>> default 0x00800000 if TARGET_SOCFPGA_GEN5
>>
>> @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
>> bool
>> select SPL_ALTERA_SDRAM
>> imply FPGA_SOCFPGA
>> + imply SPL_SIZE_LIMIT_SUBTRACT_GD
>> + imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
>> imply SPL_STACK_R
>> imply SPL_SYS_MALLOC_SIMPLE
>> imply USE_TINY_PRINTF
>>
> 512 bytes for stack looks like it's too little. I think the SPL started
> misbehaving when it overgrew 50 kiB, no ?
To 1: Well, I tested the stack usage once, booting from eMMC, and was
somewhere below that range. But yes, it's a problem for the future: once
we get a more stack-consuming function, we might be lost. Which size
would you suggest?
To 2: No. The documentation says 60 KiB would be the limit (upper 4 KiB
reserved for BootRom usage while loading SPL). I'm running SPL with the
DM_CLK driver (still under development) with a binary (code + dtb) of
about 58 KiB and it runs fine. Heap size before relocation increases to
around 4KiB though, so that ensures the 60 KiB limit isn't breached.
Regards,
Simon
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5
2019-06-13 20:26 ` Simon Goldschmidt
@ 2019-06-13 20:39 ` Marek Vasut
2019-06-13 20:55 ` Simon Goldschmidt
0 siblings, 1 reply; 10+ messages in thread
From: Marek Vasut @ 2019-06-13 20:39 UTC (permalink / raw)
To: u-boot
On 6/13/19 10:26 PM, Simon Goldschmidt wrote:
>
>
> On 13.06.19 22:14, Marek Vasut wrote:
>> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
>>> This provides an SPL_SIZE_LIMIT that makes the build check that the SPL
>>> binary loaded from flash fits into the SRAM (64 KiB) and leaves enough
>>> room for global data, heap and stack (512 bytes assumed stack usage).
>>>
>>> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
>>> ---
>>>
>>> arch/arm/mach-socfpga/Kconfig | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-socfpga/Kconfig
>>> b/arch/arm/mach-socfpga/Kconfig
>>> index 48f02f08d4..1d914648e3 100644
>>> --- a/arch/arm/mach-socfpga/Kconfig
>>> +++ b/arch/arm/mach-socfpga/Kconfig
>>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
>>> config NR_DRAM_BANKS
>>> default 1
>>> +config SPL_SIZE_LIMIT
>>> + default 65536 if TARGET_SOCFPGA_GEN5
>>> +
>>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
>>> + default 0x200 if TARGET_SOCFPGA_GEN5
>>> +
>>> config SPL_STACK_R_ADDR
>>> default 0x00800000 if TARGET_SOCFPGA_GEN5
>>> @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
>>> bool
>>> select SPL_ALTERA_SDRAM
>>> imply FPGA_SOCFPGA
>>> + imply SPL_SIZE_LIMIT_SUBTRACT_GD
>>> + imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
>>> imply SPL_STACK_R
>>> imply SPL_SYS_MALLOC_SIMPLE
>>> imply USE_TINY_PRINTF
>>>
>> 512 bytes for stack looks like it's too little. I think the SPL started
>> misbehaving when it overgrew 50 kiB, no ?
>
> To 1: Well, I tested the stack usage once, booting from eMMC, and was
> somewhere below that range. But yes, it's a problem for the future: once
> we get a more stack-consuming function, we might be lost. Which size
> would you suggest?
Hmmm, now that I think about it, the stack gets relocated to DRAM quite
early too, right ? So maybe we really don't need that much space for stack.
> To 2: No. The documentation says 60 KiB would be the limit (upper 4 KiB
> reserved for BootRom usage while loading SPL). I'm running SPL with the
> DM_CLK driver (still under development) with a binary (code + dtb) of
> about 58 KiB and it runs fine. Heap size before relocation increases to
> around 4KiB though, so that ensures the 60 KiB limit isn't breached.
OK, thanks for checking.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5
2019-06-13 20:39 ` Marek Vasut
@ 2019-06-13 20:55 ` Simon Goldschmidt
2019-06-13 20:56 ` Marek Vasut
0 siblings, 1 reply; 10+ messages in thread
From: Simon Goldschmidt @ 2019-06-13 20:55 UTC (permalink / raw)
To: u-boot
Marek Vasut <marex@denx.de> schrieb am Do., 13. Juni 2019, 22:40:
> On 6/13/19 10:26 PM, Simon Goldschmidt wrote:
> >
> >
> > On 13.06.19 22:14, Marek Vasut wrote:
> >> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
> >>> This provides an SPL_SIZE_LIMIT that makes the build check that the SPL
> >>> binary loaded from flash fits into the SRAM (64 KiB) and leaves enough
> >>> room for global data, heap and stack (512 bytes assumed stack usage).
> >>>
> >>> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
> >>> ---
> >>>
> >>> arch/arm/mach-socfpga/Kconfig | 8 ++++++++
> >>> 1 file changed, 8 insertions(+)
> >>>
> >>> diff --git a/arch/arm/mach-socfpga/Kconfig
> >>> b/arch/arm/mach-socfpga/Kconfig
> >>> index 48f02f08d4..1d914648e3 100644
> >>> --- a/arch/arm/mach-socfpga/Kconfig
> >>> +++ b/arch/arm/mach-socfpga/Kconfig
> >>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
> >>> config NR_DRAM_BANKS
> >>> default 1
> >>> +config SPL_SIZE_LIMIT
> >>> + default 65536 if TARGET_SOCFPGA_GEN5
> >>> +
> >>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
> >>> + default 0x200 if TARGET_SOCFPGA_GEN5
> >>> +
> >>> config SPL_STACK_R_ADDR
> >>> default 0x00800000 if TARGET_SOCFPGA_GEN5
> >>> @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
> >>> bool
> >>> select SPL_ALTERA_SDRAM
> >>> imply FPGA_SOCFPGA
> >>> + imply SPL_SIZE_LIMIT_SUBTRACT_GD
> >>> + imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
> >>> imply SPL_STACK_R
> >>> imply SPL_SYS_MALLOC_SIMPLE
> >>> imply USE_TINY_PRINTF
> >>>
> >> 512 bytes for stack looks like it's too little. I think the SPL started
> >> misbehaving when it overgrew 50 kiB, no ?
> >
> > To 1: Well, I tested the stack usage once, booting from eMMC, and was
> > somewhere below that range. But yes, it's a problem for the future: once
> > we get a more stack-consuming function, we might be lost. Which size
> > would you suggest?
>
> Hmmm, now that I think about it, the stack gets relocated to DRAM quite
> early too, right ? So maybe we really don't need that much space for stack.
>
Exactly. The only stack-consuming things before relocation are dts parsing
and maybe the ddr driver. I implemented a stack usage check by filling the
memory with 0xaa and checking it afterwards and if I remember correctly it
resulted in about 400 bytes. It's even more or less independent of the boot
type since the ski/mmc drivers are probed only after DDR is up. Same goes
for file systems.
Nevertheless, stack usage can increase in the future. That's why I'm not
too happy about this constant. Otoh, DM_CLK makes me need every byte and
right now I don't see how I can enable secure boot (fit signature check)
due to this size limit...
Regards,
Simon
> > To 2: No. The documentation says 60 KiB would be the limit (upper 4 KiB
> > reserved for BootRom usage while loading SPL). I'm running SPL with the
> > DM_CLK driver (still under development) with a binary (code + dtb) of
> > about 58 KiB and it runs fine. Heap size before relocation increases to
> > around 4KiB though, so that ensures the 60 KiB limit isn't breached.
>
> OK, thanks for checking.
>
> --
> Best regards,
> Marek Vasut
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5
2019-06-13 20:55 ` Simon Goldschmidt
@ 2019-06-13 20:56 ` Marek Vasut
2019-06-13 21:00 ` Simon Goldschmidt
0 siblings, 1 reply; 10+ messages in thread
From: Marek Vasut @ 2019-06-13 20:56 UTC (permalink / raw)
To: u-boot
On 6/13/19 10:55 PM, Simon Goldschmidt wrote:
>
>
> Marek Vasut <marex at denx.de <mailto:marex@denx.de>> schrieb am Do., 13.
> Juni 2019, 22:40:
>
> On 6/13/19 10:26 PM, Simon Goldschmidt wrote:
> >
> >
> > On 13.06.19 22:14, Marek Vasut wrote:
> >> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
> >>> This provides an SPL_SIZE_LIMIT that makes the build check that
> the SPL
> >>> binary loaded from flash fits into the SRAM (64 KiB) and leaves
> enough
> >>> room for global data, heap and stack (512 bytes assumed stack
> usage).
> >>>
> >>> Signed-off-by: Simon Goldschmidt
> <simon.k.r.goldschmidt@gmail.com
> <mailto:simon.k.r.goldschmidt@gmail.com>>
> >>> ---
> >>>
> >>> arch/arm/mach-socfpga/Kconfig | 8 ++++++++
> >>> 1 file changed, 8 insertions(+)
> >>>
> >>> diff --git a/arch/arm/mach-socfpga/Kconfig
> >>> b/arch/arm/mach-socfpga/Kconfig
> >>> index 48f02f08d4..1d914648e3 100644
> >>> --- a/arch/arm/mach-socfpga/Kconfig
> >>> +++ b/arch/arm/mach-socfpga/Kconfig
> >>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
> >>> config NR_DRAM_BANKS
> >>> default 1
> >>> +config SPL_SIZE_LIMIT
> >>> + default 65536 if TARGET_SOCFPGA_GEN5
> >>> +
> >>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
> >>> + default 0x200 if TARGET_SOCFPGA_GEN5
> >>> +
> >>> config SPL_STACK_R_ADDR
> >>> default 0x00800000 if TARGET_SOCFPGA_GEN5
> >>> @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
> >>> bool
> >>> select SPL_ALTERA_SDRAM
> >>> imply FPGA_SOCFPGA
> >>> + imply SPL_SIZE_LIMIT_SUBTRACT_GD
> >>> + imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
> >>> imply SPL_STACK_R
> >>> imply SPL_SYS_MALLOC_SIMPLE
> >>> imply USE_TINY_PRINTF
> >>>
> >> 512 bytes for stack looks like it's too little. I think the SPL
> started
> >> misbehaving when it overgrew 50 kiB, no ?
> >
> > To 1: Well, I tested the stack usage once, booting from eMMC, and was
> > somewhere below that range. But yes, it's a problem for the
> future: once
> > we get a more stack-consuming function, we might be lost. Which size
> > would you suggest?
>
> Hmmm, now that I think about it, the stack gets relocated to DRAM quite
> early too, right ? So maybe we really don't need that much space for
> stack.
>
>
> Exactly. The only stack-consuming things before relocation are dts
> parsing and maybe the ddr driver. I implemented a stack usage check by
> filling the memory with 0xaa and checking it afterwards and if I
> remember correctly it resulted in about 400 bytes. It's even more or
> less independent of the boot type since the ski/mmc drivers are probed
> only after DDR is up. Same goes for file systems.
>
> Nevertheless, stack usage can increase in the future. That's why I'm not
> too happy about this constant. Otoh, DM_CLK makes me need every byte and
> right now I don't see how I can enable secure boot (fit signature check)
> due to this size limit...
Maybe before we add more bloat, we should consider how to trim the bloat
down first ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5
2019-06-13 20:56 ` Marek Vasut
@ 2019-06-13 21:00 ` Simon Goldschmidt
2019-06-13 21:08 ` Marek Vasut
0 siblings, 1 reply; 10+ messages in thread
From: Simon Goldschmidt @ 2019-06-13 21:00 UTC (permalink / raw)
To: u-boot
Marek Vasut <marex@denx.de> schrieb am Do., 13. Juni 2019, 22:56:
> On 6/13/19 10:55 PM, Simon Goldschmidt wrote:
> >
> >
> > Marek Vasut <marex at denx.de <mailto:marex@denx.de>> schrieb am Do., 13.
> > Juni 2019, 22:40:
> >
> > On 6/13/19 10:26 PM, Simon Goldschmidt wrote:
> > >
> > >
> > > On 13.06.19 22:14, Marek Vasut wrote:
> > >> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
> > >>> This provides an SPL_SIZE_LIMIT that makes the build check that
> > the SPL
> > >>> binary loaded from flash fits into the SRAM (64 KiB) and leaves
> > enough
> > >>> room for global data, heap and stack (512 bytes assumed stack
> > usage).
> > >>>
> > >>> Signed-off-by: Simon Goldschmidt
> > <simon.k.r.goldschmidt@gmail.com
> > <mailto:simon.k.r.goldschmidt@gmail.com>>
> > >>> ---
> > >>>
> > >>> arch/arm/mach-socfpga/Kconfig | 8 ++++++++
> > >>> 1 file changed, 8 insertions(+)
> > >>>
> > >>> diff --git a/arch/arm/mach-socfpga/Kconfig
> > >>> b/arch/arm/mach-socfpga/Kconfig
> > >>> index 48f02f08d4..1d914648e3 100644
> > >>> --- a/arch/arm/mach-socfpga/Kconfig
> > >>> +++ b/arch/arm/mach-socfpga/Kconfig
> > >>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
> > >>> config NR_DRAM_BANKS
> > >>> default 1
> > >>> +config SPL_SIZE_LIMIT
> > >>> + default 65536 if TARGET_SOCFPGA_GEN5
> > >>> +
> > >>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
> > >>> + default 0x200 if TARGET_SOCFPGA_GEN5
> > >>> +
> > >>> config SPL_STACK_R_ADDR
> > >>> default 0x00800000 if TARGET_SOCFPGA_GEN5
> > >>> @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
> > >>> bool
> > >>> select SPL_ALTERA_SDRAM
> > >>> imply FPGA_SOCFPGA
> > >>> + imply SPL_SIZE_LIMIT_SUBTRACT_GD
> > >>> + imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
> > >>> imply SPL_STACK_R
> > >>> imply SPL_SYS_MALLOC_SIMPLE
> > >>> imply USE_TINY_PRINTF
> > >>>
> > >> 512 bytes for stack looks like it's too little. I think the SPL
> > started
> > >> misbehaving when it overgrew 50 kiB, no ?
> > >
> > > To 1: Well, I tested the stack usage once, booting from eMMC, and
> was
> > > somewhere below that range. But yes, it's a problem for the
> > future: once
> > > we get a more stack-consuming function, we might be lost. Which
> size
> > > would you suggest?
> >
> > Hmmm, now that I think about it, the stack gets relocated to DRAM
> quite
> > early too, right ? So maybe we really don't need that much space for
> > stack.
> >
> >
> > Exactly. The only stack-consuming things before relocation are dts
> > parsing and maybe the ddr driver. I implemented a stack usage check by
> > filling the memory with 0xaa and checking it afterwards and if I
> > remember correctly it resulted in about 400 bytes. It's even more or
> > less independent of the boot type since the ski/mmc drivers are probed
> > only after DDR is up. Same goes for file systems.
> >
> > Nevertheless, stack usage can increase in the future. That's why I'm not
> > too happy about this constant. Otoh, DM_CLK makes me need every byte and
> > right now I don't see how I can enable secure boot (fit signature check)
> > due to this size limit...
>
> Maybe before we add more bloat, we should consider how to trim the bloat
> down first ?
>
One of the reasons why I haven't sent the clk driver patches yet.
Anyway, I'll be off for at least a week now, I just wanted to get this one
in before the release.
I hope I'll be working on SPL size after that... 64 KiB not being enough is
just ridicculous...
Regards,
Simon
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5
2019-06-13 21:00 ` Simon Goldschmidt
@ 2019-06-13 21:08 ` Marek Vasut
2019-06-14 6:57 ` Simon Goldschmidt
0 siblings, 1 reply; 10+ messages in thread
From: Marek Vasut @ 2019-06-13 21:08 UTC (permalink / raw)
To: u-boot
On 6/13/19 11:00 PM, Simon Goldschmidt wrote:
>
>
> Marek Vasut <marex at denx.de <mailto:marex@denx.de>> schrieb am Do., 13.
> Juni 2019, 22:56:
>
> On 6/13/19 10:55 PM, Simon Goldschmidt wrote:
> >
> >
> > Marek Vasut <marex at denx.de <mailto:marex@denx.de>
> <mailto:marex at denx.de <mailto:marex@denx.de>>> schrieb am Do., 13.
> > Juni 2019, 22:40:
> >
> > On 6/13/19 10:26 PM, Simon Goldschmidt wrote:
> > >
> > >
> > > On 13.06.19 22:14, Marek Vasut wrote:
> > >> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
> > >>> This provides an SPL_SIZE_LIMIT that makes the build check
> that
> > the SPL
> > >>> binary loaded from flash fits into the SRAM (64 KiB) and
> leaves
> > enough
> > >>> room for global data, heap and stack (512 bytes assumed stack
> > usage).
> > >>>
> > >>> Signed-off-by: Simon Goldschmidt
> > <simon.k.r.goldschmidt@gmail.com
> <mailto:simon.k.r.goldschmidt@gmail.com>
> > <mailto:simon.k.r.goldschmidt@gmail.com
> <mailto:simon.k.r.goldschmidt@gmail.com>>>
> > >>> ---
> > >>>
> > >>> arch/arm/mach-socfpga/Kconfig | 8 ++++++++
> > >>> 1 file changed, 8 insertions(+)
> > >>>
> > >>> diff --git a/arch/arm/mach-socfpga/Kconfig
> > >>> b/arch/arm/mach-socfpga/Kconfig
> > >>> index 48f02f08d4..1d914648e3 100644
> > >>> --- a/arch/arm/mach-socfpga/Kconfig
> > >>> +++ b/arch/arm/mach-socfpga/Kconfig
> > >>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
> > >>> config NR_DRAM_BANKS
> > >>> default 1
> > >>> +config SPL_SIZE_LIMIT
> > >>> + default 65536 if TARGET_SOCFPGA_GEN5
> > >>> +
> > >>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
> > >>> + default 0x200 if TARGET_SOCFPGA_GEN5
> > >>> +
> > >>> config SPL_STACK_R_ADDR
> > >>> default 0x00800000 if TARGET_SOCFPGA_GEN5
> > >>> @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
> > >>> bool
> > >>> select SPL_ALTERA_SDRAM
> > >>> imply FPGA_SOCFPGA
> > >>> + imply SPL_SIZE_LIMIT_SUBTRACT_GD
> > >>> + imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
> > >>> imply SPL_STACK_R
> > >>> imply SPL_SYS_MALLOC_SIMPLE
> > >>> imply USE_TINY_PRINTF
> > >>>
> > >> 512 bytes for stack looks like it's too little. I think the SPL
> > started
> > >> misbehaving when it overgrew 50 kiB, no ?
> > >
> > > To 1: Well, I tested the stack usage once, booting from
> eMMC, and was
> > > somewhere below that range. But yes, it's a problem for the
> > future: once
> > > we get a more stack-consuming function, we might be lost.
> Which size
> > > would you suggest?
> >
> > Hmmm, now that I think about it, the stack gets relocated to
> DRAM quite
> > early too, right ? So maybe we really don't need that much
> space for
> > stack.
> >
> >
> > Exactly. The only stack-consuming things before relocation are dts
> > parsing and maybe the ddr driver. I implemented a stack usage check by
> > filling the memory with 0xaa and checking it afterwards and if I
> > remember correctly it resulted in about 400 bytes. It's even more or
> > less independent of the boot type since the ski/mmc drivers are probed
> > only after DDR is up. Same goes for file systems.
> >
> > Nevertheless, stack usage can increase in the future. That's why
> I'm not
> > too happy about this constant. Otoh, DM_CLK makes me need every
> byte and
> > right now I don't see how I can enable secure boot (fit signature
> check)
> > due to this size limit...
>
> Maybe before we add more bloat, we should consider how to trim the bloat
> down first ?
>
>
> One of the reasons why I haven't sent the clk driver patches yet.
>
> Anyway, I'll be off for at least a week now, I just wanted to get this
> one in before the release.
So is 0x200 bytes for stack before SPL relocs the stack enough ?
> I hope I'll be working on SPL size after that... 64 KiB not being enough
> is just ridicculous...
Agreed
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5
2019-06-13 21:08 ` Marek Vasut
@ 2019-06-14 6:57 ` Simon Goldschmidt
2019-06-14 10:42 ` Marek Vasut
0 siblings, 1 reply; 10+ messages in thread
From: Simon Goldschmidt @ 2019-06-14 6:57 UTC (permalink / raw)
To: u-boot
Marek Vasut <marex@denx.de> schrieb am Do., 13. Juni 2019, 23:08:
> On 6/13/19 11:00 PM, Simon Goldschmidt wrote:
> >
> >
> > Marek Vasut <marex at denx.de <mailto:marex@denx.de>> schrieb am Do., 13.
> > Juni 2019, 22:56:
> >
> > On 6/13/19 10:55 PM, Simon Goldschmidt wrote:
> > >
> > >
> > > Marek Vasut <marex at denx.de <mailto:marex@denx.de>
> > <mailto:marex at denx.de <mailto:marex@denx.de>>> schrieb am Do., 13.
> > > Juni 2019, 22:40:
> > >
> > > On 6/13/19 10:26 PM, Simon Goldschmidt wrote:
> > > >
> > > >
> > > > On 13.06.19 22:14, Marek Vasut wrote:
> > > >> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
> > > >>> This provides an SPL_SIZE_LIMIT that makes the build check
> > that
> > > the SPL
> > > >>> binary loaded from flash fits into the SRAM (64 KiB) and
> > leaves
> > > enough
> > > >>> room for global data, heap and stack (512 bytes assumed
> stack
> > > usage).
> > > >>>
> > > >>> Signed-off-by: Simon Goldschmidt
> > > <simon.k.r.goldschmidt@gmail.com
> > <mailto:simon.k.r.goldschmidt@gmail.com>
> > > <mailto:simon.k.r.goldschmidt@gmail.com
> > <mailto:simon.k.r.goldschmidt@gmail.com>>>
> > > >>> ---
> > > >>>
> > > >>> arch/arm/mach-socfpga/Kconfig | 8 ++++++++
> > > >>> 1 file changed, 8 insertions(+)
> > > >>>
> > > >>> diff --git a/arch/arm/mach-socfpga/Kconfig
> > > >>> b/arch/arm/mach-socfpga/Kconfig
> > > >>> index 48f02f08d4..1d914648e3 100644
> > > >>> --- a/arch/arm/mach-socfpga/Kconfig
> > > >>> +++ b/arch/arm/mach-socfpga/Kconfig
> > > >>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
> > > >>> config NR_DRAM_BANKS
> > > >>> default 1
> > > >>> +config SPL_SIZE_LIMIT
> > > >>> + default 65536 if TARGET_SOCFPGA_GEN5
> > > >>> +
> > > >>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
> > > >>> + default 0x200 if TARGET_SOCFPGA_GEN5
> > > >>> +
> > > >>> config SPL_STACK_R_ADDR
> > > >>> default 0x00800000 if TARGET_SOCFPGA_GEN5
> > > >>> @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
> > > >>> bool
> > > >>> select SPL_ALTERA_SDRAM
> > > >>> imply FPGA_SOCFPGA
> > > >>> + imply SPL_SIZE_LIMIT_SUBTRACT_GD
> > > >>> + imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
> > > >>> imply SPL_STACK_R
> > > >>> imply SPL_SYS_MALLOC_SIMPLE
> > > >>> imply USE_TINY_PRINTF
> > > >>>
> > > >> 512 bytes for stack looks like it's too little. I think the
> SPL
> > > started
> > > >> misbehaving when it overgrew 50 kiB, no ?
> > > >
> > > > To 1: Well, I tested the stack usage once, booting from
> > eMMC, and was
> > > > somewhere below that range. But yes, it's a problem for the
> > > future: once
> > > > we get a more stack-consuming function, we might be lost.
> > Which size
> > > > would you suggest?
> > >
> > > Hmmm, now that I think about it, the stack gets relocated to
> > DRAM quite
> > > early too, right ? So maybe we really don't need that much
> > space for
> > > stack.
> > >
> > >
> > > Exactly. The only stack-consuming things before relocation are dts
> > > parsing and maybe the ddr driver. I implemented a stack usage
> check by
> > > filling the memory with 0xaa and checking it afterwards and if I
> > > remember correctly it resulted in about 400 bytes. It's even more
> or
> > > less independent of the boot type since the ski/mmc drivers are
> probed
> > > only after DDR is up. Same goes for file systems.
> > >
> > > Nevertheless, stack usage can increase in the future. That's why
> > I'm not
> > > too happy about this constant. Otoh, DM_CLK makes me need every
> > byte and
> > > right now I don't see how I can enable secure boot (fit signature
> > check)
> > > due to this size limit...
> >
> > Maybe before we add more bloat, we should consider how to trim the
> bloat
> > down first ?
> >
> >
> > One of the reasons why I haven't sent the clk driver patches yet.
> >
> > Anyway, I'll be off for at least a week now, I just wanted to get this
> > one in before the release.
>
> So is 0x200 bytes for stack before SPL relocs the stack enough ?
>
For now it's enough, yes.
Regards,
Simon
> > I hope I'll be working on SPL size after that... 64 KiB not being enough
> > is just ridicculous...
>
> Agreed
>
> --
> Best regards,
> Marek Vasut
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5
2019-06-14 6:57 ` Simon Goldschmidt
@ 2019-06-14 10:42 ` Marek Vasut
0 siblings, 0 replies; 10+ messages in thread
From: Marek Vasut @ 2019-06-14 10:42 UTC (permalink / raw)
To: u-boot
On 6/14/19 8:57 AM, Simon Goldschmidt wrote:
>
>
> Marek Vasut <marex at denx.de <mailto:marex@denx.de>> schrieb am Do., 13.
> Juni 2019, 23:08:
>
> On 6/13/19 11:00 PM, Simon Goldschmidt wrote:
> >
> >
> > Marek Vasut <marex at denx.de <mailto:marex@denx.de>
> <mailto:marex at denx.de <mailto:marex@denx.de>>> schrieb am Do., 13.
> > Juni 2019, 22:56:
> >
> > On 6/13/19 10:55 PM, Simon Goldschmidt wrote:
> > >
> > >
> > > Marek Vasut <marex at denx.de <mailto:marex@denx.de>
> <mailto:marex at denx.de <mailto:marex@denx.de>>
> > <mailto:marex at denx.de <mailto:marex@denx.de>
> <mailto:marex at denx.de <mailto:marex@denx.de>>>> schrieb am Do., 13.
> > > Juni 2019, 22:40:
> > >
> > > On 6/13/19 10:26 PM, Simon Goldschmidt wrote:
> > > >
> > > >
> > > > On 13.06.19 22:14, Marek Vasut wrote:
> > > >> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
> > > >>> This provides an SPL_SIZE_LIMIT that makes the build
> check
> > that
> > > the SPL
> > > >>> binary loaded from flash fits into the SRAM (64 KiB) and
> > leaves
> > > enough
> > > >>> room for global data, heap and stack (512 bytes
> assumed stack
> > > usage).
> > > >>>
> > > >>> Signed-off-by: Simon Goldschmidt
> > > <simon.k.r.goldschmidt@gmail.com
> <mailto:simon.k.r.goldschmidt@gmail.com>
> > <mailto:simon.k.r.goldschmidt@gmail.com
> <mailto:simon.k.r.goldschmidt@gmail.com>>
> > > <mailto:simon.k.r.goldschmidt@gmail.com
> <mailto:simon.k.r.goldschmidt@gmail.com>
> > <mailto:simon.k.r.goldschmidt@gmail.com
> <mailto:simon.k.r.goldschmidt@gmail.com>>>>
> > > >>> ---
> > > >>>
> > > >>> arch/arm/mach-socfpga/Kconfig | 8 ++++++++
> > > >>> 1 file changed, 8 insertions(+)
> > > >>>
> > > >>> diff --git a/arch/arm/mach-socfpga/Kconfig
> > > >>> b/arch/arm/mach-socfpga/Kconfig
> > > >>> index 48f02f08d4..1d914648e3 100644
> > > >>> --- a/arch/arm/mach-socfpga/Kconfig
> > > >>> +++ b/arch/arm/mach-socfpga/Kconfig
> > > >>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
> > > >>> config NR_DRAM_BANKS
> > > >>> default 1
> > > >>> +config SPL_SIZE_LIMIT
> > > >>> + default 65536 if TARGET_SOCFPGA_GEN5
> > > >>> +
> > > >>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
> > > >>> + default 0x200 if TARGET_SOCFPGA_GEN5
> > > >>> +
> > > >>> config SPL_STACK_R_ADDR
> > > >>> default 0x00800000 if TARGET_SOCFPGA_GEN5
> > > >>> @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
> > > >>> bool
> > > >>> select SPL_ALTERA_SDRAM
> > > >>> imply FPGA_SOCFPGA
> > > >>> + imply SPL_SIZE_LIMIT_SUBTRACT_GD
> > > >>> + imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
> > > >>> imply SPL_STACK_R
> > > >>> imply SPL_SYS_MALLOC_SIMPLE
> > > >>> imply USE_TINY_PRINTF
> > > >>>
> > > >> 512 bytes for stack looks like it's too little. I
> think the SPL
> > > started
> > > >> misbehaving when it overgrew 50 kiB, no ?
> > > >
> > > > To 1: Well, I tested the stack usage once, booting from
> > eMMC, and was
> > > > somewhere below that range. But yes, it's a problem
> for the
> > > future: once
> > > > we get a more stack-consuming function, we might be lost.
> > Which size
> > > > would you suggest?
> > >
> > > Hmmm, now that I think about it, the stack gets relocated to
> > DRAM quite
> > > early too, right ? So maybe we really don't need that much
> > space for
> > > stack.
> > >
> > >
> > > Exactly. The only stack-consuming things before relocation
> are dts
> > > parsing and maybe the ddr driver. I implemented a stack
> usage check by
> > > filling the memory with 0xaa and checking it afterwards and if I
> > > remember correctly it resulted in about 400 bytes. It's even
> more or
> > > less independent of the boot type since the ski/mmc drivers
> are probed
> > > only after DDR is up. Same goes for file systems.
> > >
> > > Nevertheless, stack usage can increase in the future. That's why
> > I'm not
> > > too happy about this constant. Otoh, DM_CLK makes me need every
> > byte and
> > > right now I don't see how I can enable secure boot (fit
> signature
> > check)
> > > due to this size limit...
> >
> > Maybe before we add more bloat, we should consider how to trim
> the bloat
> > down first ?
> >
> >
> > One of the reasons why I haven't sent the clk driver patches yet.
> >
> > Anyway, I'll be off for at least a week now, I just wanted to get this
> > one in before the release.
>
> So is 0x200 bytes for stack before SPL relocs the stack enough ?
>
>
> For now it's enough, yes.
OK, applied.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-06-14 10:42 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-13 19:50 [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5 Simon Goldschmidt
2019-06-13 20:14 ` Marek Vasut
2019-06-13 20:26 ` Simon Goldschmidt
2019-06-13 20:39 ` Marek Vasut
2019-06-13 20:55 ` Simon Goldschmidt
2019-06-13 20:56 ` Marek Vasut
2019-06-13 21:00 ` Simon Goldschmidt
2019-06-13 21:08 ` Marek Vasut
2019-06-14 6:57 ` Simon Goldschmidt
2019-06-14 10:42 ` Marek Vasut
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.