| Message ID | 1421253662-27222-16-git-send-email-dinguyen@opensource.altera.com |
|---|---|
| State | Superseded |
| Delegated to: | Marek Vasut |
| Headers | show |
On Wednesday, January 14, 2015 at 05:40:55 PM, dinguyen@opensource.altera.com wrote: > From: Dinh Nguyen <dinguyen@opensource.altera.com> > > Add a function to relocate the stack from OCRAM to SDRAM. Hi, is this functionality really needed ? There's like 128 KiB of OCRAM on SoCFPGA, which should be plenty, right? If moving the stack to SDRAM is really needed, then you might want to use the common stack relocation code (see relocate_code() function). Also, you should thoroughly describe the reason in the commit message, in this case it's really important. Best regards, Marek Vasut
Hi Marek, On 01/14/2015 05:58 PM, Marek Vasut wrote: > On Wednesday, January 14, 2015 at 05:40:55 PM, dinguyen@opensource.altera.com > wrote: >> From: Dinh Nguyen <dinguyen@opensource.altera.com> >> >> Add a function to relocate the stack from OCRAM to SDRAM. > > Hi, > > is this functionality really needed ? There's like 128 KiB of OCRAM on SoCFPGA, On cyclone5 and arria5, there is only 64KiB. > which should be plenty, right? If moving the stack to SDRAM is really needed, > then you might want to use the common stack relocation code (see relocate_code() > function). Also, you should thoroughly describe the reason in the commit > message, in this case it's really important. I'll update in v2. Thanks, Dinh
On Thursday, January 15, 2015 at 08:19:15 PM, Dinh Nguyen wrote: > Hi Marek, Hi Dinh, > On 01/14/2015 05:58 PM, Marek Vasut wrote: > > On Wednesday, January 14, 2015 at 05:40:55 PM, > > dinguyen@opensource.altera.com > > > > wrote: > >> From: Dinh Nguyen <dinguyen@opensource.altera.com> > >> > >> Add a function to relocate the stack from OCRAM to SDRAM. > > > > Hi, > > > > is this functionality really needed ? There's like 128 KiB of OCRAM on > > SoCFPGA, > > On cyclone5 and arria5, there is only 64KiB. Ooops, sorry, my bad. You're right. But that is still boatload of memory, given that the SPL will use some hundreds of bytes for the stack under normal conditions. > > which should be plenty, right? If moving the stack to SDRAM is really > > needed, then you might want to use the common stack relocation code (see > > relocate_code() function). Also, you should thoroughly describe the > > reason in the commit message, in this case it's really important. > > I'll update in v2. So uh, what's the reason for moving the stack into the SDRAM anyway please ? Best regards, Marek Vasut
On 01/15/2015 04:00 PM, Marek Vasut wrote: > On Thursday, January 15, 2015 at 08:19:15 PM, Dinh Nguyen wrote: >> Hi Marek, > > Hi Dinh, > >> On 01/14/2015 05:58 PM, Marek Vasut wrote: >>> On Wednesday, January 14, 2015 at 05:40:55 PM, >>> dinguyen@opensource.altera.com >>> >>> wrote: >>>> From: Dinh Nguyen <dinguyen@opensource.altera.com> >>>> >>>> Add a function to relocate the stack from OCRAM to SDRAM. >>> >>> Hi, >>> >>> is this functionality really needed ? There's like 128 KiB of OCRAM on >>> SoCFPGA, >> >> On cyclone5 and arria5, there is only 64KiB. > > Ooops, sorry, my bad. You're right. But that is still boatload of memory, > given that the SPL will use some hundreds of bytes for the stack under > normal conditions. > >>> which should be plenty, right? If moving the stack to SDRAM is really >>> needed, then you might want to use the common stack relocation code (see >>> relocate_code() function). Also, you should thoroughly describe the >>> reason in the commit message, in this case it's really important. >> >> I'll update in v2. > > So uh, what's the reason for moving the stack into the SDRAM anyway please ? > I think this is needed to be able to support SPL_FAT_LOAD. Dinh
On Friday, January 16, 2015 at 01:07:55 AM, Dinh Nguyen wrote: Hi! > >>> which should be plenty, right? If moving the stack to SDRAM is really > >>> needed, then you might want to use the common stack relocation code > >>> (see relocate_code() function). Also, you should thoroughly describe > >>> the reason in the commit message, in this case it's really important. > >> > >> I'll update in v2. > > > > So uh, what's the reason for moving the stack into the SDRAM anyway > > please ? > > I think this is needed to be able to support SPL_FAT_LOAD. Loading from FAT shouldn't consume that much stack. I think you should be able to use JTAG debugger and trace the stack utilisation in the functions defined in files under fs/fat/ , which should give you some idea how much the FAT loading consumes. In case there really is some spike in the stack utilization, such spike should be identified and fixed instead. I also believe that in case we manage to avoid moving the stack to SDRAM, we avoid a lot of code which is possibly fragile and that's always nice. Would you please be able to look into this stack utilization issue in more depth ? Thank you! Best regards, Marek Vasut
diff --git a/arch/arm/cpu/armv7/socfpga/lowlevel_init.S b/arch/arm/cpu/armv7/socfpga/lowlevel_init.S index ee3c9fa..9ae8e3c 100644 --- a/arch/arm/cpu/armv7/socfpga/lowlevel_init.S +++ b/arch/arm/cpu/armv7/socfpga/lowlevel_init.S @@ -52,3 +52,27 @@ clrsp: cmp r0, r1 /* while not at end of BSS */ blo clrsp #endif /* #ifdef CONFIG_SPL_BUILD */ bx lr + +#ifdef CONFIG_SPL_BUILD +ENTRY(relocate_stack_to_sdram) + PUSH {r4-r11, lr} /* save registers per AAPCS */ + + mov r0, sp /* [r0] source address */ + ldr r2, =__stack_start /* [r2] source end address */ + sub r3, r2, r0 + ldr r4, =__sdram_stack_start + sub r1, r4, r3 /* [r1] target address */ + mov r5, r1 /* [r5] new sp within SDRAM */ + +relocate_loop1: + ldmia r0!, {r3} + stmia r1!, {r3} + cmp r0, r2 + blo relocate_loop1 + + /* assign SP to new address within SDRAM now */ + mov sp, r5 + + POP {r4-r11, pc} +ENDPROC(relocate_stack_to_sdram) +#endif /* CONFIG_SPL_BUILD */