Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Simon & Simon, On Wed, May 22, 2019 at 05:08:40PM -0500, Andreas Dannenberg wrote: > Hi Simon (Glass) > > On Tue, May 21, 2019 at 06:53:31PM -0600, Simon Glass wrote: > > > > > > Not having BSS available to carry over certain state to the > > > > > board_init_r() world would lead to a bunch of hacky changes across > > > > > the board I'm afraid, more below. > > > > > > > > This is really unfortunate. > > > > > > > > It seems to me that we have two choises: > > > > > > > > 1. Hack around with board_init_f() such as to remove the distinction > > > > between this and board_init_r(). > > > > > > > > 2. Enter board_init_r() without DRAM ready, and deal with setting it up > > > > there. > > > > > > > > I feel that the second solution is worth exploring. We could have some > > > > board-specific init in board_init_r(). We already have > > > > spl_board_init() so perhaps we could have spl_early_board_init() > > > > called right near the top? > > > > > > > > We can refactor a few of the functions in spl/spl.c so they can be > > > > called from board-specific code if necessary. We could also add new > > > > flags to global_data to control the behaviour of the SPL code, and the > > > > board code could set these. > > I have an alternative solution working, that essentially makes > board_init_f() more useful. I understand that this is not what you > wanted to see but I wanted to throw it out here anyways so we can have > another look at it. > > Please see attached RFC for the general concept of allowing to move BSS > setup prior to board_init_f for SPL via Kconfig option. This should also > allow a few folks to get rid of the "hacky" memset() calls to manually > clear BSS in board_initf() and with this bring some cleanup across the > board (no pun intended). Of course such solution would need to go along > with comment/documentation updates that are not yet comprehended in this > RFC. Ok I just realized yesterday after I sent that RFC that it was essentially the same approach that was already part of Simon's patch series here... give or take that my approach was using a macro to avoid the duplication of BSS clearing code in crt0.S. So it's not really adding to the discussion here of coming up with something entirely different. Should have looked at the original patch more closely, my bad. -- Andreas Dannenberg Texas Instruments Inc > Background, I played with the adding a hook early into SPL's > board_init_r() but as expected it was not very straightforward. One > challenge for example is that gd/stack are "relocated" to DDR prior to > board_init_r(), but since I don't have DDR until I can use BSS to bring > up DDR, adding a hook into board_init_r() to bringup DDR I couldn't see > a good way to both avoid doing and then to re-do some of that stuff > usually done in crt0.S after my early board_init_r() hook has ran > without making changes to crt0.S itself... > > I'm still thinking about it... > > -- > Andreas Dannenberg > Texas Instruments Inc > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Simon, On Wed, 22 May 2019 at 13:42, Simon Goldschmidt wrote: > > > > Simon Glass schrieb am Mi., 22. Mai 2019, 21:34: >> >> Hi Simon, >> >> On Wed, 22 May 2019 at 02:05, Simon Goldschmidt >> wrote: >> > >> > On Wed, May 22, 2019 at 2:53 AM Simon Glass wrote: >> > > >> > > Hi Andreas, >> > > >> > > On Tue, 21 May 2019 at 15:01, Andreas Dannenberg >> > > wrote: >> > > > >> > > > Hi Simon (Glass), >> > > > >> > > > On Sat, May 18, 2019 at 10:08:19AM -0600, Simon Glass wrote: >> > > > > Hi Andreas, >> > > > > >> > > > > On Mon, 6 May 2019 at 22:49, Andreas Dannenberg >> > > > > wrote: >> > > > > > >> > > > > > Hi Simon, >> > > > > > >> > > > > > On Mon, May 06, 2019 at 09:51:56PM -0600, Simon Glass wrote: >> > > > > > > Hi Andreas, >> > > > > > > >> > > > > > > On Fri, 3 May 2019 at 14:25, Andreas Dannenberg >> > > > > > > wrote: >> > > > > > > > >> > > > > > > > Simon, >> > > > > > > > >> > > > > > > > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt >> > > > > > > > wrote: >> > > > > > > > > Simon Glass schrieb am Sa., 30. März >> > > > > > > > > 2019, 21:06: >> > > > > > > > > >> > > > > > > > > > Hi Simon, >> > > > > > > > > > >> > > > > > > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt >> > > > > > > > > > wrote: >> > > > > > > > > > > >> > > > > > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If >> > > > > > > > > > > enabled, it >> > > > > > > > > > clears >> > > > > > > > > > > the bss before calling board_init_f() instead of >> > > > > > > > > > > clearing it before >> > > > > > > > > > calling >> > > > > > > > > > > board_init_r(). >> > > > > > > > > > > >> > > > > > > > > > > This also ensures that variables placed in BSS can be >> > > > > > > > > > > shared between >> > > > > > > > > > > board_init_f() and board_init_r() in SPL. >> > > > > > > > > > > >> > > > > > > > > > > Such global variables are used, for example, when >> > > > > > > > > > > loading things from FAT >> > > > > > > > > > > before SDRAM is available: the full heap required for >> > > > > > > > > > > FAT uses global >> > > > > > > > > > > variables and clearing BSS after board_init_f() would >> > > > > > > > > > > reset the heap >> > > > > > > > > > state. >> > > > > > > > > > > An example for such a usage is socfpa_arria10 where an >> > > > > > > > > > > FPGA configuration >> > > > > > > > > > > is required before SDRAM can be used. >> > > > > > > > > > > >> > > > > > > > > > > Make the new option depend on ARM for now until more >> > > > > > > > > > > implementations >> > > > > > > > > > follow. >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > I still have objections to this series and I think we >> > > > > > > > > > should discuss >> > > > > > > > > > other ways of solving this problem. >> > > > > > > > > > >> > > > > > > > > > Does socfgpa have SRAM that could be used before SDRAM is >> > > > > > > > > > available? >> > > > > > > > > > If so, can we not use that for the configuration? What >> > > > > > > > > > various are >> > > > > > > > > > actually in BSS that are needed before board_init_r() is >> > > > > > > > > > called? Can >> > > > > > > > > > they not be in a struct created from malloc()? >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > The problem is the board needs to load an FPGA configuration >> > > > > > > > > from FAT >> > > > > > > > > before SDRAM is available. Yes, this is loaded into SRAM of >> > > > > > > > > course, but the >> > > > > > > > > whole code until that is done uses so many malloc/free >> > > > > > > > > iterations that The >> > > > > > > > > simple mall of implementation would require too much memory. >> > > > > > > > > >> > > > > > > > > And it's the full malloc state variables only that use BSS, >> > > > > > > > > not the FAT >> > > > > > > > > code. >> > > > > > > > >> > > > > > > > I've actually faced very similar issues working on our TI >> > > > > > > > AM654x "System >> > > > > > > > Firmware Loader" implementation (will post upstream soon), >> > > > > > > > where I need >> > > > > > > > to load this firmware and other files from media such as >> > > > > > > > MMC/FAT in a very >> > > > > > > > memory-constrained SPL pre-relocation environment *before* I >> > > > > > > > can bring up >> > > > > > > > DDR. >> > > > > > > > >> > > > > > > > Initially, I modified the fat.c driver to re-use memory so it >> > > > > > > > is not as >> > > > > > > > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this >> > > > > > > > solution [1] >> > > > > > > > this allowed us to get going, allowing to load multiple files >> > > > > > > > without >> > > > > > > > issues in pre-relocation SPL. >> > > > > > > >> > > > > > > That seems to point the way to a useful solution I think. We >> > > > > > > could >> > > > > > > have a struct containing allocated pointers which is private to >> > > > > > > FAT, >> > > > > > > and just allocate them the first time. >> > > > > > >> > > > > > The board_init_f
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Simon (Glass) On Tue, May 21, 2019 at 06:53:31PM -0600, Simon Glass wrote: > > > > Not having BSS available to carry over certain state to the > > > > board_init_r() world would lead to a bunch of hacky changes across > > > > the board I'm afraid, more below. > > > > > > This is really unfortunate. > > > > > > It seems to me that we have two choises: > > > > > > 1. Hack around with board_init_f() such as to remove the distinction > > > between this and board_init_r(). > > > > > > 2. Enter board_init_r() without DRAM ready, and deal with setting it up > > > there. > > > > > > I feel that the second solution is worth exploring. We could have some > > > board-specific init in board_init_r(). We already have > > > spl_board_init() so perhaps we could have spl_early_board_init() > > > called right near the top? > > > > > > We can refactor a few of the functions in spl/spl.c so they can be > > > called from board-specific code if necessary. We could also add new > > > flags to global_data to control the behaviour of the SPL code, and the > > > board code could set these. I have an alternative solution working, that essentially makes board_init_f() more useful. I understand that this is not what you wanted to see but I wanted to throw it out here anyways so we can have another look at it. Please see attached RFC for the general concept of allowing to move BSS setup prior to board_init_f for SPL via Kconfig option. This should also allow a few folks to get rid of the "hacky" memset() calls to manually clear BSS in board_initf() and with this bring some cleanup across the board (no pun intended). Of course such solution would need to go along with comment/documentation updates that are not yet comprehended in this RFC. Background, I played with the adding a hook early into SPL's board_init_r() but as expected it was not very straightforward. One challenge for example is that gd/stack are "relocated" to DDR prior to board_init_r(), but since I don't have DDR until I can use BSS to bring up DDR, adding a hook into board_init_r() to bringup DDR I couldn't see a good way to both avoid doing and then to re-do some of that stuff usually done in crt0.S after my early board_init_r() hook has ran without making changes to crt0.S itself... I'm still thinking about it... -- Andreas Dannenberg Texas Instruments Inc >From 170ad7c668050e76dcbf566ea464f5ac90851943 Mon Sep 17 00:00:00 2001 From: Andreas Dannenberg Date: Tue, 4 Dec 2018 22:30:09 -0600 Subject: [RFC] spl: Allow performing BSS init early before board_init_f() On some platform we have sufficient memory available early on to allow setting up and using a basic BSS prior to entering board_init_f(). Doing so can for example be used to carry state over to board_init_r() without having to resort to extending U-Boot's global data structure. To support such scenarios add a Kconfig option called CONFIG_SPL_EARLY_BSS to allow moving the initialization of BSS prior to entering board_init_f(), if enabled. Note that using this option usually should go along with using CONFIG_SPL_SEPARATE_BSS and configuring BSS to be located in memory actually available prior to board_init_f(). Signed-off-by: Andreas Dannenberg --- arch/arm/lib/crt0.S | 53 ++--- common/spl/Kconfig | 10 + 2 files changed, 46 insertions(+), 17 deletions(-) diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index 30fba20e1b..c74641dcd9 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -57,6 +57,33 @@ * For more information see 'Board Initialisation Flow in README. */ +/* + * Macro for clearing BSS during SPL execution. Usually called during the + * relocation process for most boards before entering board_init_r(), but + * can also be done early before entering board_init_f() on plaforms that + * can afford it due to sufficient memory being available early. + */ + +.macro SPL_CLEAR_BSS + ldr r0, =__bss_start /* this is auto-relocated! */ + +#ifdef CONFIG_USE_ARCH_MEMSET + ldr r3, =__bss_end /* this is auto-relocated! */ + mov r1, #0x /* prepare zero to clear BSS */ + + subs r2, r3, r0 /* r2 = memset len */ + bl memset +#else + ldr r1, =__bss_end /* this is auto-relocated! */ + mov r2, #0x /* prepare zero to clear BSS */ + +clbss_l:cmp r0, r1 /* while not at end of BSS */ + strlo r2, [r0] /* clear 32-bit BSS word */ + addlo r0, r0, #4 /* move to next */ + blo clbss_l +#endif +.endm + /* * entry point of crt0 sequence */ @@ -82,6 +109,10 @@ ENTRY(_main) mov r9, r0 bl board_init_f_init_reserve +#if defined(CONFIG_SPL_EARLY_BSS) + SPL_CLEAR_BSS +#endif + mov r0, #0 bl board_init_f @@ -119,6 +150,11 @@ here: bl c_runtime_cpu_setup /* we still call old routine here */ #endif #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_FRAMEWORK) + +#if !defined(CONFIG_SPL_EARLY_BSS) + SPL_CLEAR_BSS +#endif + # ifdef CONFIG_SPL_BUILD /* Use a DRAM stack for the rest of SPL, if requested */ b
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Simon Glass schrieb am Mi., 22. Mai 2019, 21:34: > Hi Simon, > > On Wed, 22 May 2019 at 02:05, Simon Goldschmidt > wrote: > > > > On Wed, May 22, 2019 at 2:53 AM Simon Glass wrote: > > > > > > Hi Andreas, > > > > > > On Tue, 21 May 2019 at 15:01, Andreas Dannenberg > wrote: > > > > > > > > Hi Simon (Glass), > > > > > > > > On Sat, May 18, 2019 at 10:08:19AM -0600, Simon Glass wrote: > > > > > Hi Andreas, > > > > > > > > > > On Mon, 6 May 2019 at 22:49, Andreas Dannenberg > wrote: > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Mon, May 06, 2019 at 09:51:56PM -0600, Simon Glass wrote: > > > > > > > Hi Andreas, > > > > > > > > > > > > > > On Fri, 3 May 2019 at 14:25, Andreas Dannenberg < > dannenb...@ti.com> wrote: > > > > > > > > > > > > > > > > Simon, > > > > > > > > > > > > > > > > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt > wrote: > > > > > > > > > Simon Glass schrieb am Sa., 30. März > 2019, 21:06: > > > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. > If enabled, it > > > > > > > > > > clears > > > > > > > > > > > the bss before calling board_init_f() instead of > clearing it before > > > > > > > > > > calling > > > > > > > > > > > board_init_r(). > > > > > > > > > > > > > > > > > > > > > > This also ensures that variables placed in BSS can be > shared between > > > > > > > > > > > board_init_f() and board_init_r() in SPL. > > > > > > > > > > > > > > > > > > > > > > Such global variables are used, for example, when > loading things from FAT > > > > > > > > > > > before SDRAM is available: the full heap required for > FAT uses global > > > > > > > > > > > variables and clearing BSS after board_init_f() would > reset the heap > > > > > > > > > > state. > > > > > > > > > > > An example for such a usage is socfpa_arria10 where an > FPGA configuration > > > > > > > > > > > is required before SDRAM can be used. > > > > > > > > > > > > > > > > > > > > > > Make the new option depend on ARM for now until more > implementations > > > > > > > > > > follow. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I still have objections to this series and I think we > should discuss > > > > > > > > > > other ways of solving this problem. > > > > > > > > > > > > > > > > > > > > Does socfgpa have SRAM that could be used before SDRAM > is available? > > > > > > > > > > If so, can we not use that for the configuration? What > various are > > > > > > > > > > actually in BSS that are needed before board_init_r() is > called? Can > > > > > > > > > > they not be in a struct created from malloc()? > > > > > > > > > > > > > > > > > > > > > > > > > > > > The problem is the board needs to load an FPGA > configuration from FAT > > > > > > > > > before SDRAM is available. Yes, this is loaded into SRAM > of course, but the > > > > > > > > > whole code until that is done uses so many malloc/free > iterations that The > > > > > > > > > simple mall of implementation would require too much > memory. > > > > > > > > > > > > > > > > > > And it's the full malloc state variables only that use > BSS, not the FAT > > > > > > > > > code. > > > > > > > > > > > > > > > > I've actually faced very similar issues working on our TI > AM654x "System > > > > > > > > Firmware Loader" implementation (will post upstream soon), > where I need > > > > > > > > to load this firmware and other files from media such as > MMC/FAT in a very > > > > > > > > memory-constrained SPL pre-relocation environment *before* I > can bring up > > > > > > > > DDR. > > > > > > > > > > > > > > > > Initially, I modified the fat.c driver to re-use memory so > it is not as > > > > > > > > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of > this solution [1] > > > > > > > > this allowed us to get going, allowing to load multiple > files without > > > > > > > > issues in pre-relocation SPL. > > > > > > > > > > > > > > That seems to point the way to a useful solution I think. We > could > > > > > > > have a struct containing allocated pointers which is private > to FAT, > > > > > > > and just allocate them the first time. > > > > > > > > > > > > The board_init_f()-based loader solution we use extends beyond > MMC/FAT, > > > > > > but also for OSPI, X/Y-Modem, and (later) USB, network, etc. > > > > > > > > > > > > Background: > > > > > > On our "TI K3" devices we need to do a whole bunch of stuff > before > > > > > > DDR is up with limited memory, namely loading and installing a > firmware > > > > > > that controls the entire SoC called "System Firmware". It is > only after > > > > > > this FW is loaded from boot media and successfully started that > I can > > > > > > bring up DDR. So all this is done in SPL board_init_f(), which > as the > > > > > > last step brings up DDR. > > > > > > > > > > > > Not having BSS available t
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Simon, On Wed, 22 May 2019 at 02:05, Simon Goldschmidt wrote: > > On Wed, May 22, 2019 at 2:53 AM Simon Glass wrote: > > > > Hi Andreas, > > > > On Tue, 21 May 2019 at 15:01, Andreas Dannenberg wrote: > > > > > > Hi Simon (Glass), > > > > > > On Sat, May 18, 2019 at 10:08:19AM -0600, Simon Glass wrote: > > > > Hi Andreas, > > > > > > > > On Mon, 6 May 2019 at 22:49, Andreas Dannenberg > > > > wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Mon, May 06, 2019 at 09:51:56PM -0600, Simon Glass wrote: > > > > > > Hi Andreas, > > > > > > > > > > > > On Fri, 3 May 2019 at 14:25, Andreas Dannenberg > > > > > > wrote: > > > > > > > > > > > > > > Simon, > > > > > > > > > > > > > > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt wrote: > > > > > > > > Simon Glass schrieb am Sa., 30. März 2019, > > > > > > > > 21:06: > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If > > > > > > > > > > enabled, it > > > > > > > > > clears > > > > > > > > > > the bss before calling board_init_f() instead of clearing > > > > > > > > > > it before > > > > > > > > > calling > > > > > > > > > > board_init_r(). > > > > > > > > > > > > > > > > > > > > This also ensures that variables placed in BSS can be > > > > > > > > > > shared between > > > > > > > > > > board_init_f() and board_init_r() in SPL. > > > > > > > > > > > > > > > > > > > > Such global variables are used, for example, when loading > > > > > > > > > > things from FAT > > > > > > > > > > before SDRAM is available: the full heap required for FAT > > > > > > > > > > uses global > > > > > > > > > > variables and clearing BSS after board_init_f() would reset > > > > > > > > > > the heap > > > > > > > > > state. > > > > > > > > > > An example for such a usage is socfpa_arria10 where an FPGA > > > > > > > > > > configuration > > > > > > > > > > is required before SDRAM can be used. > > > > > > > > > > > > > > > > > > > > Make the new option depend on ARM for now until more > > > > > > > > > > implementations > > > > > > > > > follow. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I still have objections to this series and I think we should > > > > > > > > > discuss > > > > > > > > > other ways of solving this problem. > > > > > > > > > > > > > > > > > > Does socfgpa have SRAM that could be used before SDRAM is > > > > > > > > > available? > > > > > > > > > If so, can we not use that for the configuration? What > > > > > > > > > various are > > > > > > > > > actually in BSS that are needed before board_init_r() is > > > > > > > > > called? Can > > > > > > > > > they not be in a struct created from malloc()? > > > > > > > > > > > > > > > > > > > > > > > > > The problem is the board needs to load an FPGA configuration > > > > > > > > from FAT > > > > > > > > before SDRAM is available. Yes, this is loaded into SRAM of > > > > > > > > course, but the > > > > > > > > whole code until that is done uses so many malloc/free > > > > > > > > iterations that The > > > > > > > > simple mall of implementation would require too much memory. > > > > > > > > > > > > > > > > And it's the full malloc state variables only that use BSS, not > > > > > > > > the FAT > > > > > > > > code. > > > > > > > > > > > > > > I've actually faced very similar issues working on our TI AM654x > > > > > > > "System > > > > > > > Firmware Loader" implementation (will post upstream soon), where > > > > > > > I need > > > > > > > to load this firmware and other files from media such as MMC/FAT > > > > > > > in a very > > > > > > > memory-constrained SPL pre-relocation environment *before* I can > > > > > > > bring up > > > > > > > DDR. > > > > > > > > > > > > > > Initially, I modified the fat.c driver to re-use memory so it is > > > > > > > not as > > > > > > > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this > > > > > > > solution [1] > > > > > > > this allowed us to get going, allowing to load multiple files > > > > > > > without > > > > > > > issues in pre-relocation SPL. > > > > > > > > > > > > That seems to point the way to a useful solution I think. We could > > > > > > have a struct containing allocated pointers which is private to FAT, > > > > > > and just allocate them the first time. > > > > > > > > > > The board_init_f()-based loader solution we use extends beyond > > > > > MMC/FAT, > > > > > but also for OSPI, X/Y-Modem, and (later) USB, network, etc. > > > > > > > > > > Background: > > > > > On our "TI K3" devices we need to do a whole bunch of stuff before > > > > > DDR is up with limited memory, namely loading and installing a > > > > > firmware > > > > > that controls the entire SoC called "System Firmware". It is only > > > > > after > > > > > this FW is loaded from boot media and successfully started that I can > > > > > brin
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
On Wed, May 22, 2019 at 2:53 AM Simon Glass wrote: > > Hi Andreas, > > On Tue, 21 May 2019 at 15:01, Andreas Dannenberg wrote: > > > > Hi Simon (Glass), > > > > On Sat, May 18, 2019 at 10:08:19AM -0600, Simon Glass wrote: > > > Hi Andreas, > > > > > > On Mon, 6 May 2019 at 22:49, Andreas Dannenberg wrote: > > > > > > > > Hi Simon, > > > > > > > > On Mon, May 06, 2019 at 09:51:56PM -0600, Simon Glass wrote: > > > > > Hi Andreas, > > > > > > > > > > On Fri, 3 May 2019 at 14:25, Andreas Dannenberg > > > > > wrote: > > > > > > > > > > > > Simon, > > > > > > > > > > > > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt wrote: > > > > > > > Simon Glass schrieb am Sa., 30. März 2019, > > > > > > > 21:06: > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If > > > > > > > > > enabled, it > > > > > > > > clears > > > > > > > > > the bss before calling board_init_f() instead of clearing it > > > > > > > > > before > > > > > > > > calling > > > > > > > > > board_init_r(). > > > > > > > > > > > > > > > > > > This also ensures that variables placed in BSS can be shared > > > > > > > > > between > > > > > > > > > board_init_f() and board_init_r() in SPL. > > > > > > > > > > > > > > > > > > Such global variables are used, for example, when loading > > > > > > > > > things from FAT > > > > > > > > > before SDRAM is available: the full heap required for FAT > > > > > > > > > uses global > > > > > > > > > variables and clearing BSS after board_init_f() would reset > > > > > > > > > the heap > > > > > > > > state. > > > > > > > > > An example for such a usage is socfpa_arria10 where an FPGA > > > > > > > > > configuration > > > > > > > > > is required before SDRAM can be used. > > > > > > > > > > > > > > > > > > Make the new option depend on ARM for now until more > > > > > > > > > implementations > > > > > > > > follow. > > > > > > > > > > > > > > > > > > > > > > > > > I still have objections to this series and I think we should > > > > > > > > discuss > > > > > > > > other ways of solving this problem. > > > > > > > > > > > > > > > > Does socfgpa have SRAM that could be used before SDRAM is > > > > > > > > available? > > > > > > > > If so, can we not use that for the configuration? What various > > > > > > > > are > > > > > > > > actually in BSS that are needed before board_init_r() is > > > > > > > > called? Can > > > > > > > > they not be in a struct created from malloc()? > > > > > > > > > > > > > > > > > > > > > > The problem is the board needs to load an FPGA configuration from > > > > > > > FAT > > > > > > > before SDRAM is available. Yes, this is loaded into SRAM of > > > > > > > course, but the > > > > > > > whole code until that is done uses so many malloc/free iterations > > > > > > > that The > > > > > > > simple mall of implementation would require too much memory. > > > > > > > > > > > > > > And it's the full malloc state variables only that use BSS, not > > > > > > > the FAT > > > > > > > code. > > > > > > > > > > > > I've actually faced very similar issues working on our TI AM654x > > > > > > "System > > > > > > Firmware Loader" implementation (will post upstream soon), where I > > > > > > need > > > > > > to load this firmware and other files from media such as MMC/FAT in > > > > > > a very > > > > > > memory-constrained SPL pre-relocation environment *before* I can > > > > > > bring up > > > > > > DDR. > > > > > > > > > > > > Initially, I modified the fat.c driver to re-use memory so it is > > > > > > not as > > > > > > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this > > > > > > solution [1] > > > > > > this allowed us to get going, allowing to load multiple files > > > > > > without > > > > > > issues in pre-relocation SPL. > > > > > > > > > > That seems to point the way to a useful solution I think. We could > > > > > have a struct containing allocated pointers which is private to FAT, > > > > > and just allocate them the first time. > > > > > > > > The board_init_f()-based loader solution we use extends beyond MMC/FAT, > > > > but also for OSPI, X/Y-Modem, and (later) USB, network, etc. > > > > > > > > Background: > > > > On our "TI K3" devices we need to do a whole bunch of stuff before > > > > DDR is up with limited memory, namely loading and installing a firmware > > > > that controls the entire SoC called "System Firmware". It is only after > > > > this FW is loaded from boot media and successfully started that I can > > > > bring up DDR. So all this is done in SPL board_init_f(), which as the > > > > last step brings up DDR. > > > > > > > > Not having BSS available to carry over certain state to the > > > > board_init_r() world would lead to a bunch of hacky changes across > > > > the board I'm afraid, more below. > > > > > > This is really unfortunate. > > > > > >
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Andreas, On Tue, 21 May 2019 at 15:01, Andreas Dannenberg wrote: > > Hi Simon (Glass), > > On Sat, May 18, 2019 at 10:08:19AM -0600, Simon Glass wrote: > > Hi Andreas, > > > > On Mon, 6 May 2019 at 22:49, Andreas Dannenberg wrote: > > > > > > Hi Simon, > > > > > > On Mon, May 06, 2019 at 09:51:56PM -0600, Simon Glass wrote: > > > > Hi Andreas, > > > > > > > > On Fri, 3 May 2019 at 14:25, Andreas Dannenberg > > > > wrote: > > > > > > > > > > Simon, > > > > > > > > > > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt wrote: > > > > > > Simon Glass schrieb am Sa., 30. März 2019, > > > > > > 21:06: > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > > > > > > > wrote: > > > > > > > > > > > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If > > > > > > > > enabled, it > > > > > > > clears > > > > > > > > the bss before calling board_init_f() instead of clearing it > > > > > > > > before > > > > > > > calling > > > > > > > > board_init_r(). > > > > > > > > > > > > > > > > This also ensures that variables placed in BSS can be shared > > > > > > > > between > > > > > > > > board_init_f() and board_init_r() in SPL. > > > > > > > > > > > > > > > > Such global variables are used, for example, when loading > > > > > > > > things from FAT > > > > > > > > before SDRAM is available: the full heap required for FAT uses > > > > > > > > global > > > > > > > > variables and clearing BSS after board_init_f() would reset the > > > > > > > > heap > > > > > > > state. > > > > > > > > An example for such a usage is socfpa_arria10 where an FPGA > > > > > > > > configuration > > > > > > > > is required before SDRAM can be used. > > > > > > > > > > > > > > > > Make the new option depend on ARM for now until more > > > > > > > > implementations > > > > > > > follow. > > > > > > > > > > > > > > > > > > > > > > I still have objections to this series and I think we should > > > > > > > discuss > > > > > > > other ways of solving this problem. > > > > > > > > > > > > > > Does socfgpa have SRAM that could be used before SDRAM is > > > > > > > available? > > > > > > > If so, can we not use that for the configuration? What various are > > > > > > > actually in BSS that are needed before board_init_r() is called? > > > > > > > Can > > > > > > > they not be in a struct created from malloc()? > > > > > > > > > > > > > > > > > > > The problem is the board needs to load an FPGA configuration from > > > > > > FAT > > > > > > before SDRAM is available. Yes, this is loaded into SRAM of course, > > > > > > but the > > > > > > whole code until that is done uses so many malloc/free iterations > > > > > > that The > > > > > > simple mall of implementation would require too much memory. > > > > > > > > > > > > And it's the full malloc state variables only that use BSS, not the > > > > > > FAT > > > > > > code. > > > > > > > > > > I've actually faced very similar issues working on our TI AM654x > > > > > "System > > > > > Firmware Loader" implementation (will post upstream soon), where I > > > > > need > > > > > to load this firmware and other files from media such as MMC/FAT in a > > > > > very > > > > > memory-constrained SPL pre-relocation environment *before* I can > > > > > bring up > > > > > DDR. > > > > > > > > > > Initially, I modified the fat.c driver to re-use memory so it is not > > > > > as > > > > > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this > > > > > solution [1] > > > > > this allowed us to get going, allowing to load multiple files without > > > > > issues in pre-relocation SPL. > > > > > > > > That seems to point the way to a useful solution I think. We could > > > > have a struct containing allocated pointers which is private to FAT, > > > > and just allocate them the first time. > > > > > > The board_init_f()-based loader solution we use extends beyond MMC/FAT, > > > but also for OSPI, X/Y-Modem, and (later) USB, network, etc. > > > > > > Background: > > > On our "TI K3" devices we need to do a whole bunch of stuff before > > > DDR is up with limited memory, namely loading and installing a firmware > > > that controls the entire SoC called "System Firmware". It is only after > > > this FW is loaded from boot media and successfully started that I can > > > bring up DDR. So all this is done in SPL board_init_f(), which as the > > > last step brings up DDR. > > > > > > Not having BSS available to carry over certain state to the > > > board_init_r() world would lead to a bunch of hacky changes across > > > the board I'm afraid, more below. > > > > This is really unfortunate. > > > > It seems to me that we have two choises: > > > > 1. Hack around with board_init_f() such as to remove the distinction > > between this and board_init_r(). > > > > 2. Enter board_init_r() without DRAM ready, and deal with setting it up > > there. > > > > I feel that the second solution is worth exploring. We could have som
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Simon (Glass), On Sat, May 18, 2019 at 10:08:19AM -0600, Simon Glass wrote: > Hi Andreas, > > On Mon, 6 May 2019 at 22:49, Andreas Dannenberg wrote: > > > > Hi Simon, > > > > On Mon, May 06, 2019 at 09:51:56PM -0600, Simon Glass wrote: > > > Hi Andreas, > > > > > > On Fri, 3 May 2019 at 14:25, Andreas Dannenberg wrote: > > > > > > > > Simon, > > > > > > > > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt wrote: > > > > > Simon Glass schrieb am Sa., 30. März 2019, 21:06: > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > > > > > > wrote: > > > > > > > > > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, > > > > > > > it > > > > > > clears > > > > > > > the bss before calling board_init_f() instead of clearing it > > > > > > > before > > > > > > calling > > > > > > > board_init_r(). > > > > > > > > > > > > > > This also ensures that variables placed in BSS can be shared > > > > > > > between > > > > > > > board_init_f() and board_init_r() in SPL. > > > > > > > > > > > > > > Such global variables are used, for example, when loading things > > > > > > > from FAT > > > > > > > before SDRAM is available: the full heap required for FAT uses > > > > > > > global > > > > > > > variables and clearing BSS after board_init_f() would reset the > > > > > > > heap > > > > > > state. > > > > > > > An example for such a usage is socfpa_arria10 where an FPGA > > > > > > > configuration > > > > > > > is required before SDRAM can be used. > > > > > > > > > > > > > > Make the new option depend on ARM for now until more > > > > > > > implementations > > > > > > follow. > > > > > > > > > > > > > > > > > > > I still have objections to this series and I think we should discuss > > > > > > other ways of solving this problem. > > > > > > > > > > > > Does socfgpa have SRAM that could be used before SDRAM is available? > > > > > > If so, can we not use that for the configuration? What various are > > > > > > actually in BSS that are needed before board_init_r() is called? Can > > > > > > they not be in a struct created from malloc()? > > > > > > > > > > > > > > > > The problem is the board needs to load an FPGA configuration from FAT > > > > > before SDRAM is available. Yes, this is loaded into SRAM of course, > > > > > but the > > > > > whole code until that is done uses so many malloc/free iterations > > > > > that The > > > > > simple mall of implementation would require too much memory. > > > > > > > > > > And it's the full malloc state variables only that use BSS, not the > > > > > FAT > > > > > code. > > > > > > > > I've actually faced very similar issues working on our TI AM654x "System > > > > Firmware Loader" implementation (will post upstream soon), where I need > > > > to load this firmware and other files from media such as MMC/FAT in a > > > > very > > > > memory-constrained SPL pre-relocation environment *before* I can bring > > > > up > > > > DDR. > > > > > > > > Initially, I modified the fat.c driver to re-use memory so it is not as > > > > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this solution > > > > [1] > > > > this allowed us to get going, allowing to load multiple files without > > > > issues in pre-relocation SPL. > > > > > > That seems to point the way to a useful solution I think. We could > > > have a struct containing allocated pointers which is private to FAT, > > > and just allocate them the first time. > > > > The board_init_f()-based loader solution we use extends beyond MMC/FAT, > > but also for OSPI, X/Y-Modem, and (later) USB, network, etc. > > > > Background: > > On our "TI K3" devices we need to do a whole bunch of stuff before > > DDR is up with limited memory, namely loading and installing a firmware > > that controls the entire SoC called "System Firmware". It is only after > > this FW is loaded from boot media and successfully started that I can > > bring up DDR. So all this is done in SPL board_init_f(), which as the > > last step brings up DDR. > > > > Not having BSS available to carry over certain state to the > > board_init_r() world would lead to a bunch of hacky changes across > > the board I'm afraid, more below. > > This is really unfortunate. > > It seems to me that we have two choises: > > 1. Hack around with board_init_f() such as to remove the distinction > between this and board_init_r(). > > 2. Enter board_init_r() without DRAM ready, and deal with setting it up there. > > I feel that the second solution is worth exploring. We could have some > board-specific init in board_init_r(). We already have > spl_board_init() so perhaps we could have spl_early_board_init() > called right near the top? > > We can refactor a few of the functions in spl/spl.c so they can be > called from board-specific code if necessary. We could also add new > flags to global_data to control the behaviour of the SPL code, and the > board code could set these. Let me explo
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Andreas, On Mon, 6 May 2019 at 22:49, Andreas Dannenberg wrote: > > Hi Simon, > > On Mon, May 06, 2019 at 09:51:56PM -0600, Simon Glass wrote: > > Hi Andreas, > > > > On Fri, 3 May 2019 at 14:25, Andreas Dannenberg wrote: > > > > > > Simon, > > > > > > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt wrote: > > > > Simon Glass schrieb am Sa., 30. März 2019, 21:06: > > > > > > > > > Hi Simon, > > > > > > > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > > > > > wrote: > > > > > > > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it > > > > > clears > > > > > > the bss before calling board_init_f() instead of clearing it before > > > > > calling > > > > > > board_init_r(). > > > > > > > > > > > > This also ensures that variables placed in BSS can be shared between > > > > > > board_init_f() and board_init_r() in SPL. > > > > > > > > > > > > Such global variables are used, for example, when loading things > > > > > > from FAT > > > > > > before SDRAM is available: the full heap required for FAT uses > > > > > > global > > > > > > variables and clearing BSS after board_init_f() would reset the heap > > > > > state. > > > > > > An example for such a usage is socfpa_arria10 where an FPGA > > > > > > configuration > > > > > > is required before SDRAM can be used. > > > > > > > > > > > > Make the new option depend on ARM for now until more implementations > > > > > follow. > > > > > > > > > > > > > > > > I still have objections to this series and I think we should discuss > > > > > other ways of solving this problem. > > > > > > > > > > Does socfgpa have SRAM that could be used before SDRAM is available? > > > > > If so, can we not use that for the configuration? What various are > > > > > actually in BSS that are needed before board_init_r() is called? Can > > > > > they not be in a struct created from malloc()? > > > > > > > > > > > > > The problem is the board needs to load an FPGA configuration from FAT > > > > before SDRAM is available. Yes, this is loaded into SRAM of course, but > > > > the > > > > whole code until that is done uses so many malloc/free iterations that > > > > The > > > > simple mall of implementation would require too much memory. > > > > > > > > And it's the full malloc state variables only that use BSS, not the FAT > > > > code. > > > > > > I've actually faced very similar issues working on our TI AM654x "System > > > Firmware Loader" implementation (will post upstream soon), where I need > > > to load this firmware and other files from media such as MMC/FAT in a very > > > memory-constrained SPL pre-relocation environment *before* I can bring up > > > DDR. > > > > > > Initially, I modified the fat.c driver to re-use memory so it is not as > > > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this solution > > > [1] > > > this allowed us to get going, allowing to load multiple files without > > > issues in pre-relocation SPL. > > > > That seems to point the way to a useful solution I think. We could > > have a struct containing allocated pointers which is private to FAT, > > and just allocate them the first time. > > The board_init_f()-based loader solution we use extends beyond MMC/FAT, > but also for OSPI, X/Y-Modem, and (later) USB, network, etc. > > Background: > On our "TI K3" devices we need to do a whole bunch of stuff before > DDR is up with limited memory, namely loading and installing a firmware > that controls the entire SoC called "System Firmware". It is only after > this FW is loaded from boot media and successfully started that I can > bring up DDR. So all this is done in SPL board_init_f(), which as the > last step brings up DDR. > > Not having BSS available to carry over certain state to the > board_init_r() world would lead to a bunch of hacky changes across > the board I'm afraid, more below. This is really unfortunate. It seems to me that we have two choises: 1. Hack around with board_init_f() such as to remove the distinction between this and board_init_r(). 2. Enter board_init_r() without DRAM ready, and deal with setting it up there. I feel that the second solution is worth exploring. We could have some board-specific init in board_init_r(). We already have spl_board_init() so perhaps we could have spl_early_board_init() called right near the top? We can refactor a few of the functions in spl/spl.c so they can be called from board-specific code if necessary. We could also add new flags to global_data to control the behaviour of the SPL code, and the board code could set these. > > > I wonder if that would be enough for > > > > > > > > In the quest of creating something more upstream-friendly I had then > > > switched to using full malloc in pre-relocation SPL so that I didn't > > > have to hack the FAT driver, encountering similar issues like you > > > brought up and got this working, but ultimately abandoned this > > > approach after bundling all files needed to get loaded into a single >
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Simon, On Mon, May 06, 2019 at 09:51:56PM -0600, Simon Glass wrote: > Hi Andreas, > > On Fri, 3 May 2019 at 14:25, Andreas Dannenberg wrote: > > > > Simon, > > > > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt wrote: > > > Simon Glass schrieb am Sa., 30. März 2019, 21:06: > > > > > > > Hi Simon, > > > > > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > > > > wrote: > > > > > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it > > > > clears > > > > > the bss before calling board_init_f() instead of clearing it before > > > > calling > > > > > board_init_r(). > > > > > > > > > > This also ensures that variables placed in BSS can be shared between > > > > > board_init_f() and board_init_r() in SPL. > > > > > > > > > > Such global variables are used, for example, when loading things from > > > > > FAT > > > > > before SDRAM is available: the full heap required for FAT uses global > > > > > variables and clearing BSS after board_init_f() would reset the heap > > > > state. > > > > > An example for such a usage is socfpa_arria10 where an FPGA > > > > > configuration > > > > > is required before SDRAM can be used. > > > > > > > > > > Make the new option depend on ARM for now until more implementations > > > > follow. > > > > > > > > > > > > > I still have objections to this series and I think we should discuss > > > > other ways of solving this problem. > > > > > > > > Does socfgpa have SRAM that could be used before SDRAM is available? > > > > If so, can we not use that for the configuration? What various are > > > > actually in BSS that are needed before board_init_r() is called? Can > > > > they not be in a struct created from malloc()? > > > > > > > > > > The problem is the board needs to load an FPGA configuration from FAT > > > before SDRAM is available. Yes, this is loaded into SRAM of course, but > > > the > > > whole code until that is done uses so many malloc/free iterations that The > > > simple mall of implementation would require too much memory. > > > > > > And it's the full malloc state variables only that use BSS, not the FAT > > > code. > > > > I've actually faced very similar issues working on our TI AM654x "System > > Firmware Loader" implementation (will post upstream soon), where I need > > to load this firmware and other files from media such as MMC/FAT in a very > > memory-constrained SPL pre-relocation environment *before* I can bring up > > DDR. > > > > Initially, I modified the fat.c driver to re-use memory so it is not as > > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this solution [1] > > this allowed us to get going, allowing to load multiple files without > > issues in pre-relocation SPL. > > That seems to point the way to a useful solution I think. We could > have a struct containing allocated pointers which is private to FAT, > and just allocate them the first time. The board_init_f()-based loader solution we use extends beyond MMC/FAT, but also for OSPI, X/Y-Modem, and (later) USB, network, etc. Background: On our "TI K3" devices we need to do a whole bunch of stuff before DDR is up with limited memory, namely loading and installing a firmware that controls the entire SoC called "System Firmware". It is only after this FW is loaded from boot media and successfully started that I can bring up DDR. So all this is done in SPL board_init_f(), which as the last step brings up DDR. Not having BSS available to carry over certain state to the board_init_r() world would lead to a bunch of hacky changes across the board I'm afraid, more below. > I wonder if that would be enough for > > > > > In the quest of creating something more upstream-friendly I had then > > switched to using full malloc in pre-relocation SPL so that I didn't > > have to hack the FAT driver, encountering similar issues like you > > brought up and got this working, but ultimately abandoned this > > approach after bundling all files needed to get loaded into a single > > image tree blob which no longer required any of those solutions. > > > > What remained till today however is a need to preserve specific BSS > > state from pre-relocation SPL over to post-relocation SPL environment, > > namely flags set to avoid the (expensive) re-probing of peripheral > > drivers by the SPL loader. For that I introduced a Kconfig option that > > allows skipping the automatic clearing of BSS during relocation [2]. > > > > Seeing this very related discussion here got me thinking about how else > > I can carry over this "state" from pre- to post relocation but that's > > probably a discussion to be had once I post my "System Firmware Loader > > Series", probably next week. > > Since this is SPL I don't you mean 'relocation' here. I think you mean > board_init_f() to board_init_r()? Yes that's what I mean. AFAIK relocation in SPL is still called relocation from what I have seen working on U-boot, it just relocates gd and stack but not the actual code (person
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Andreas, On Fri, 3 May 2019 at 14:25, Andreas Dannenberg wrote: > > Simon, > > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt wrote: > > Simon Glass schrieb am Sa., 30. März 2019, 21:06: > > > > > Hi Simon, > > > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > > > wrote: > > > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it > > > clears > > > > the bss before calling board_init_f() instead of clearing it before > > > calling > > > > board_init_r(). > > > > > > > > This also ensures that variables placed in BSS can be shared between > > > > board_init_f() and board_init_r() in SPL. > > > > > > > > Such global variables are used, for example, when loading things from > > > > FAT > > > > before SDRAM is available: the full heap required for FAT uses global > > > > variables and clearing BSS after board_init_f() would reset the heap > > > state. > > > > An example for such a usage is socfpa_arria10 where an FPGA > > > > configuration > > > > is required before SDRAM can be used. > > > > > > > > Make the new option depend on ARM for now until more implementations > > > follow. > > > > > > > > > > I still have objections to this series and I think we should discuss > > > other ways of solving this problem. > > > > > > Does socfgpa have SRAM that could be used before SDRAM is available? > > > If so, can we not use that for the configuration? What various are > > > actually in BSS that are needed before board_init_r() is called? Can > > > they not be in a struct created from malloc()? > > > > > > > The problem is the board needs to load an FPGA configuration from FAT > > before SDRAM is available. Yes, this is loaded into SRAM of course, but the > > whole code until that is done uses so many malloc/free iterations that The > > simple mall of implementation would require too much memory. > > > > And it's the full malloc state variables only that use BSS, not the FAT > > code. > > I've actually faced very similar issues working on our TI AM654x "System > Firmware Loader" implementation (will post upstream soon), where I need > to load this firmware and other files from media such as MMC/FAT in a very > memory-constrained SPL pre-relocation environment *before* I can bring up > DDR. > > Initially, I modified the fat.c driver to re-use memory so it is not as > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this solution [1] > this allowed us to get going, allowing to load multiple files without > issues in pre-relocation SPL. That seems to point the way to a useful solution I think. We could have a struct containing allocated pointers which is private to FAT, and just allocate them the first time. I wonder if that would be enough for > > In the quest of creating something more upstream-friendly I had then > switched to using full malloc in pre-relocation SPL so that I didn't > have to hack the FAT driver, encountering similar issues like you > brought up and got this working, but ultimately abandoned this > approach after bundling all files needed to get loaded into a single > image tree blob which no longer required any of those solutions. > > What remained till today however is a need to preserve specific BSS > state from pre-relocation SPL over to post-relocation SPL environment, > namely flags set to avoid the (expensive) re-probing of peripheral > drivers by the SPL loader. For that I introduced a Kconfig option that > allows skipping the automatic clearing of BSS during relocation [2]. > > Seeing this very related discussion here got me thinking about how else > I can carry over this "state" from pre- to post relocation but that's > probably a discussion to be had once I post my "System Firmware Loader > Series", probably next week. Since this is SPL I don't you mean 'relocation' here. I think you mean board_init_f() to board_init_r()? You can use global_data to store state, or malloc() to allocate memory and put things there. But using BSS seems wrong to me. If you are doing something in board_init_f() in SPL that needs BSS, can you not just move that code to board_init_r()? > > PS: If you want to save a ton of memory during FAT loading you can > try something like CONFIG_FS_FAT_MAX_CLUSTSIZE=16384, I argue the > default is overkill for all practical scenarios. > > -- > Andreas Dannenberg > Texas Instruments Inc > > [1] > http://git.ti.com/gitweb/?p=ti-u-boot/ti-u-boot.git;a=commitdiff;h=3de26c27d232425e6a3b337dc402d73fe22ea88c > [2] > http://git.ti.com/gitweb/?p=ti-u-boot/ti-u-boot.git;a=commitdiff;h=9ab4a405c98e966a59c7c3005c08cb95ed87eea8 > > > > > One way out could be to move the full mall of state variables into 'gd'... > > > > Another way would be to continue into board_init_f without SDRAM enabled > > and in it it later... > > > > Regards, > > Simon > > > > > > > If this is a limitation of FAT, then I think we should fix that, instead. > > > > > > Regards, > > > Simon > > > > > > > Signed-off-by: Simon Goldschmidt > > > > --
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Simon, On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt wrote: > Simon Glass schrieb am Sa., 30. März 2019, 21:06: > > > Hi Simon, > > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > > wrote: > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it > > clears > > > the bss before calling board_init_f() instead of clearing it before > > calling > > > board_init_r(). > > > > > > This also ensures that variables placed in BSS can be shared between > > > board_init_f() and board_init_r() in SPL. > > > > > > Such global variables are used, for example, when loading things from FAT > > > before SDRAM is available: the full heap required for FAT uses global > > > variables and clearing BSS after board_init_f() would reset the heap > > state. > > > An example for such a usage is socfpa_arria10 where an FPGA configuration > > > is required before SDRAM can be used. > > > > > > Make the new option depend on ARM for now until more implementations > > follow. > > > > > > > I still have objections to this series and I think we should discuss > > other ways of solving this problem. > > > > Does socfgpa have SRAM that could be used before SDRAM is available? > > If so, can we not use that for the configuration? What various are > > actually in BSS that are needed before board_init_r() is called? Can > > they not be in a struct created from malloc()? > > > > The problem is the board needs to load an FPGA configuration from FAT > before SDRAM is available. Yes, this is loaded into SRAM of course, but the > whole code until that is done uses so many malloc/free iterations that The > simple mall of implementation would require too much memory. > > And it's the full malloc state variables only that use BSS, not the FAT > code. I've actually faced very similar issues working on our TI AM654x "System Firmware Loader" implementation (will post upstream soon), where I need to load this firmware and other files from media such as MMC/FAT in a very memory-constrained SPL pre-relocation environment *before* I can bring up DDR. Initially, I modified the fat.c driver to re-use memory so it is not as wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this solution [1] this allowed us to get going, allowing to load multiple files without issues in pre-relocation SPL. In the quest of creating something more upstream-friendly I had then switched to using full malloc in pre-relocation SPL so that I didn't have to hack the FAT driver, encountering similar issues like you brought up and got this working, but ultimately abandoned this approach after bundling all files needed to get loaded into a single image tree blob which no longer required any of those solutions. What remained till today however is a need to preserve specific BSS state from pre-relocation SPL over to post-relocation SPL environment, namely flags set to avoid the (expensive) re-probing of peripheral drivers by the SPL loader. For that I introduced a Kconfig option that allows skipping the automatic clearing of BSS during relocation [2]. Seeing this very related discussion here got me thinking about how else I can carry over this "state" from pre- to post relocation but that's probably a discussion to be had once I post my "System Firmware Loader Series", probably next week. PS: If you want to save a ton of memory during FAT loading you can try something like CONFIG_FS_FAT_MAX_CLUSTSIZE=16384, I argue the default is overkill for all practical scenarios. -- Andreas Dannenberg Texas Instruments Inc [1] http://git.ti.com/gitweb/?p=ti-u-boot/ti-u-boot.git;a=commitdiff;h=3de26c27d232425e6a3b337dc402d73fe22ea88c [2] http://git.ti.com/gitweb/?p=ti-u-boot/ti-u-boot.git;a=commitdiff;h=9ab4a405c98e966a59c7c3005c08cb95ed87eea8 > > One way out could be to move the full mall of state variables into 'gd'... > > Another way would be to continue into board_init_f without SDRAM enabled > and in it it later... > > Regards, > Simon > > > > If this is a limitation of FAT, then I think we should fix that, instead. > > > > Regards, > > Simon > > > > > Signed-off-by: Simon Goldschmidt > > > --- > > > > > > Changes in v3: > > > - improve commit message to show why CONFIG_CLEAR_BSS_F is needed > > > > > > Changes in v2: > > > - make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now > > > > > > common/spl/Kconfig | 12 > > > 1 file changed, 12 insertions(+) > > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > > index 206c24076d..6a4270516a 100644 > > > --- a/common/spl/Kconfig > > > +++ b/common/spl/Kconfig > > > @@ -156,6 +156,18 @@ config SPL_STACK_R_MALLOC_SIMPLE_LEN > > > to give board_init_r() a larger heap then the initial heap in > > > SRAM which is limited to SYS_MALLOC_F_LEN bytes. > > > > > > +config SPL_CLEAR_BSS_F > > > + bool "Clear BSS section before calling board_init_f" > > > + depends on ARM > > > + help > > > + The BSS section is initialized to
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hello Simon, Am 01.04.2019 um 10:43 schrieb Simon Goldschmidt: On Mon, Apr 1, 2019 at 8:07 AM Heiko Schocher wrote: Hello Simon, Am 30.03.2019 um 23:37 schrieb Simon Glass: Hi Simon, On Sat, 30 Mar 2019 at 15:40, Simon Goldschmidt wrote: Simon Glass schrieb am Sa., 30. März 2019, 22:18: Hi Simon, On Sat, 30 Mar 2019 at 14:50, Simon Goldschmidt wrote: Simon Goldschmidt schrieb am Sa., 30. März 2019, 21:18: Simon Glass schrieb am Sa., 30. März 2019, 21:06: Hi Simon, On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt wrote: This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it clears the bss before calling board_init_f() instead of clearing it before calling board_init_r(). This also ensures that variables placed in BSS can be shared between board_init_f() and board_init_r() in SPL. Such global variables are used, for example, when loading things from FAT before SDRAM is available: the full heap required for FAT uses global variables and clearing BSS after board_init_f() would reset the heap state. An example for such a usage is socfpa_arria10 where an FPGA configuration is required before SDRAM can be used. Make the new option depend on ARM for now until more implementations follow. I still have objections to this series and I think we should discuss other ways of solving this problem. Does socfgpa have SRAM that could be used before SDRAM is available? If so, can we not use that for the configuration? What various are actually in BSS that are needed before board_init_r() is called? Can they not be in a struct created from malloc()? The problem is the board needs to load an FPGA configuration from FAT before SDRAM is available. Yes, this is loaded into SRAM of course, but the whole code until that is done uses so many malloc/free iterations that The simple mall of implementation would require too much memory. And it's the full malloc state variables only that use BSS, not the FAT code. One way out could be to move the full mall of state variables into 'gd'... Maybe I should point out again that the whole purpose of this series is to have an SPL that uses full malloc right from the start. This is currently not possible as full malloc needs BSS. Right, and our assumption/design is that full malloc() requires SRAM. Here we have an architecture that requires FAT just to init its SDRAM. FAT requires malloc() and free() and there is not enough SRAM to skip the free() calls. So we have to use full malloc() and that uses BSS. But BSS is not available before board_init_r(). But we need to init SDRAM before board_init_r(). Firstly I'd point out that someone should speak to the chip designers. Did anyone try to boot U-Boot on the SoC model? Well, it's a U-Boot thing to load it from FAT. It could probably be loaded from RAW mmc without problems, so I don't know if it's a chip designers issue. I think it's an issue that we need to fix in U-Boot: we have a good full malloc implementation but it's not usable in all cases were it should be. OK then why use FAT? I assumed it was a boot-ROM requirement. How does the boot ROM load SPL? I think it is possible to change dlmalloc to put its variables in a struct. Then I suppose the struct pointer could be kept in gd. That would be one solution. Then full malloc() could be inited in spl_common_init() perhaps. That might be worth a try. Yes shouldn't be too painful. I suspect it would be neutral on code size, too. Sorry, for digging in so late, here. I just stumbeled over the same problem ... but we cannot use BSS before relocation on all platforms, so I think, this patch is no option. Right, by now I know that folks want to keep it that way. Hmm... I did not take a deep look at the dlmalloc implementation, but may my "fix" for the problem with Stefans patch, see here: http://patchwork.ozlabs.org/patch/1065508/#2130443 is may an option for dlmalloc? Moving variables from 'bss' into 'data' unoverridable by adding the 'section' attribute? No, I think that makes it even worse. Why would 'data' always be available when 'bss' is not? Why marks the section attribute the variable unoverrideable in U-Boot? I could not find any special comment in: https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes Moving this variable into data section has the effect, that the variable is between __image_copy_start and __image_copy_end and as SPL copy U-Boot image into writeable memory, it is guaranteed, that variables in data are in writeable storage medium ... And this should apply for SPL also, as your ROMbootloader must copy SPL into some writeable place ... or does your SPL code is executed from ROM ? If not, I think, the option suggested from Simon here is the way to go ... I'm not too convinced of that either. I'll take the time to re-think this specific problem (using full-malloc in SPL without explicitly defining an address range) and see
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
On Mon, Apr 1, 2019 at 8:07 AM Heiko Schocher wrote: > > Hello Simon, > > Am 30.03.2019 um 23:37 schrieb Simon Glass: > > Hi Simon, > > > > On Sat, 30 Mar 2019 at 15:40, Simon Goldschmidt > > wrote: > >> > >> > >> > >> Simon Glass schrieb am Sa., 30. März 2019, 22:18: > >>> > >>> Hi Simon, > >>> > >>> On Sat, 30 Mar 2019 at 14:50, Simon Goldschmidt > >>> wrote: > > > > Simon Goldschmidt schrieb am Sa., 30. > März 2019, 21:18: > > > > > > > > Simon Glass schrieb am Sa., 30. März 2019, 21:06: > >> > >> Hi Simon, > >> > >> On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > >> wrote: > >>> > >>> This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it > >>> clears > >>> the bss before calling board_init_f() instead of clearing it before > >>> calling > >>> board_init_r(). > >>> > >>> This also ensures that variables placed in BSS can be shared between > >>> board_init_f() and board_init_r() in SPL. > >>> > >>> Such global variables are used, for example, when loading things from > >>> FAT > >>> before SDRAM is available: the full heap required for FAT uses global > >>> variables and clearing BSS after board_init_f() would reset the heap > >>> state. > >>> An example for such a usage is socfpa_arria10 where an FPGA > >>> configuration > >>> is required before SDRAM can be used. > >>> > >>> Make the new option depend on ARM for now until more implementations > >>> follow. > >>> > >> > >> I still have objections to this series and I think we should discuss > >> other ways of solving this problem. > >> > >> Does socfgpa have SRAM that could be used before SDRAM is available? > >> If so, can we not use that for the configuration? What various are > >> actually in BSS that are needed before board_init_r() is called? Can > >> they not be in a struct created from malloc()? > > > > > > The problem is the board needs to load an FPGA configuration from FAT > > before SDRAM is available. Yes, this is loaded into SRAM of course, but > > the whole code until that is done uses so many malloc/free iterations > > that The simple mall of implementation would require too much memory. > > > > And it's the full malloc state variables only that use BSS, not the FAT > > code. > > > > One way out could be to move the full mall of state variables into > > 'gd'... > > > Maybe I should point out again that the whole purpose of this series is > to have an SPL that uses full malloc right from the start. This is > currently not possible as full malloc needs BSS. > >>> > >>> Right, and our assumption/design is that full malloc() requires SRAM. > >>> > >>> Here we have an architecture that requires FAT just to init its SDRAM. > >>> FAT requires malloc() and free() and there is not enough SRAM to skip > >>> the free() calls. So we have to use full malloc() and that uses BSS. > >>> But BSS is not available before board_init_r(). But we need to init > >>> SDRAM before board_init_r(). > >>> > >>> Firstly I'd point out that someone should speak to the chip designers. > >>> Did anyone try to boot U-Boot on the SoC model? > >> > >> > >> Well, it's a U-Boot thing to load it from FAT. It could probably be loaded > >> from RAW mmc without problems, so I don't know if it's a chip designers > >> issue. I think it's an issue that we need to fix in U-Boot: we have a good > >> full malloc implementation but it's not usable in all cases were it should > >> be. > > > > OK then why use FAT? I assumed it was a boot-ROM requirement. How does > > the boot ROM load SPL? > > > >> > >>> > >>> I think it is possible to change dlmalloc to put its variables in a > >>> struct. Then I suppose the struct pointer could be kept in gd. That > >>> would be one solution. Then full malloc() could be inited in > >>> spl_common_init() perhaps. > >> > >> > >> That might be worth a try. > > > > Yes shouldn't be too painful. I suspect it would be neutral on code size, > > too. > > Sorry, for digging in so late, here. I just stumbeled over the same > problem ... but we cannot use BSS before relocation on all platforms, > so I think, this patch is no option. Right, by now I know that folks want to keep it that way. > > Hmm... I did not take a deep look at the dlmalloc implementation, but > may my "fix" for the problem with Stefans patch, see here: > > http://patchwork.ozlabs.org/patch/1065508/#2130443 > > is may an option for dlmalloc? Moving variables from 'bss' into 'data' unoverridable by adding the 'section' attribute? No, I think that makes it even worse. Why would 'data' always be available when 'bss' is not? > > If not, I think, the option suggested from Simon here is the way to > go ... I'm not too convinced of that either. I'll take the time to re-think this specific problem (using fu
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hello Simon, Am 30.03.2019 um 23:37 schrieb Simon Glass: Hi Simon, On Sat, 30 Mar 2019 at 15:40, Simon Goldschmidt wrote: Simon Glass schrieb am Sa., 30. März 2019, 22:18: Hi Simon, On Sat, 30 Mar 2019 at 14:50, Simon Goldschmidt wrote: Simon Goldschmidt schrieb am Sa., 30. März 2019, 21:18: Simon Glass schrieb am Sa., 30. März 2019, 21:06: Hi Simon, On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt wrote: This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it clears the bss before calling board_init_f() instead of clearing it before calling board_init_r(). This also ensures that variables placed in BSS can be shared between board_init_f() and board_init_r() in SPL. Such global variables are used, for example, when loading things from FAT before SDRAM is available: the full heap required for FAT uses global variables and clearing BSS after board_init_f() would reset the heap state. An example for such a usage is socfpa_arria10 where an FPGA configuration is required before SDRAM can be used. Make the new option depend on ARM for now until more implementations follow. I still have objections to this series and I think we should discuss other ways of solving this problem. Does socfgpa have SRAM that could be used before SDRAM is available? If so, can we not use that for the configuration? What various are actually in BSS that are needed before board_init_r() is called? Can they not be in a struct created from malloc()? The problem is the board needs to load an FPGA configuration from FAT before SDRAM is available. Yes, this is loaded into SRAM of course, but the whole code until that is done uses so many malloc/free iterations that The simple mall of implementation would require too much memory. And it's the full malloc state variables only that use BSS, not the FAT code. One way out could be to move the full mall of state variables into 'gd'... Maybe I should point out again that the whole purpose of this series is to have an SPL that uses full malloc right from the start. This is currently not possible as full malloc needs BSS. Right, and our assumption/design is that full malloc() requires SRAM. Here we have an architecture that requires FAT just to init its SDRAM. FAT requires malloc() and free() and there is not enough SRAM to skip the free() calls. So we have to use full malloc() and that uses BSS. But BSS is not available before board_init_r(). But we need to init SDRAM before board_init_r(). Firstly I'd point out that someone should speak to the chip designers. Did anyone try to boot U-Boot on the SoC model? Well, it's a U-Boot thing to load it from FAT. It could probably be loaded from RAW mmc without problems, so I don't know if it's a chip designers issue. I think it's an issue that we need to fix in U-Boot: we have a good full malloc implementation but it's not usable in all cases were it should be. OK then why use FAT? I assumed it was a boot-ROM requirement. How does the boot ROM load SPL? I think it is possible to change dlmalloc to put its variables in a struct. Then I suppose the struct pointer could be kept in gd. That would be one solution. Then full malloc() could be inited in spl_common_init() perhaps. That might be worth a try. Yes shouldn't be too painful. I suspect it would be neutral on code size, too. Sorry, for digging in so late, here. I just stumbeled over the same problem ... but we cannot use BSS before relocation on all platforms, so I think, this patch is no option. Hmm... I did not take a deep look at the dlmalloc implementation, but may my "fix" for the problem with Stefans patch, see here: http://patchwork.ozlabs.org/patch/1065508/#2130443 is may an option for dlmalloc? If not, I think, the option suggested from Simon here is the way to go ... bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
On 30.03.19 23:37, Simon Glass wrote: Hi Simon, On Sat, 30 Mar 2019 at 15:40, Simon Goldschmidt wrote: Simon Glass schrieb am Sa., 30. März 2019, 22:18: Hi Simon, On Sat, 30 Mar 2019 at 14:50, Simon Goldschmidt wrote: Simon Goldschmidt schrieb am Sa., 30. März 2019, 21:18: Simon Glass schrieb am Sa., 30. März 2019, 21:06: Hi Simon, On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt wrote: This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it clears the bss before calling board_init_f() instead of clearing it before calling board_init_r(). This also ensures that variables placed in BSS can be shared between board_init_f() and board_init_r() in SPL. Such global variables are used, for example, when loading things from FAT before SDRAM is available: the full heap required for FAT uses global variables and clearing BSS after board_init_f() would reset the heap state. An example for such a usage is socfpa_arria10 where an FPGA configuration is required before SDRAM can be used. Make the new option depend on ARM for now until more implementations follow. I still have objections to this series and I think we should discuss other ways of solving this problem. Does socfgpa have SRAM that could be used before SDRAM is available? If so, can we not use that for the configuration? What various are actually in BSS that are needed before board_init_r() is called? Can they not be in a struct created from malloc()? The problem is the board needs to load an FPGA configuration from FAT before SDRAM is available. Yes, this is loaded into SRAM of course, but the whole code until that is done uses so many malloc/free iterations that The simple mall of implementation would require too much memory. And it's the full malloc state variables only that use BSS, not the FAT code. One way out could be to move the full mall of state variables into 'gd'... Maybe I should point out again that the whole purpose of this series is to have an SPL that uses full malloc right from the start. This is currently not possible as full malloc needs BSS. Right, and our assumption/design is that full malloc() requires SRAM. Here we have an architecture that requires FAT just to init its SDRAM. FAT requires malloc() and free() and there is not enough SRAM to skip the free() calls. So we have to use full malloc() and that uses BSS. But BSS is not available before board_init_r(). But we need to init SDRAM before board_init_r(). Firstly I'd point out that someone should speak to the chip designers. Did anyone try to boot U-Boot on the SoC model? Well, it's a U-Boot thing to load it from FAT. It could probably be loaded from RAW mmc without problems, so I don't know if it's a chip designers issue. I think it's an issue that we need to fix in U-Boot: we have a good full malloc implementation but it's not usable in all cases were it should be. OK then why use FAT? I assumed it was a boot-ROM requirement. How does the boot ROM load SPL? Honestly, I don't know. It's Altera/Intel that decided for this boot flow. However, since FPGA development is often done from Windows, I guess it's convenient for FPGA development to write the resulting binary to a FAT partition on a sdcard. I think it is possible to change dlmalloc to put its variables in a struct. Then I suppose the struct pointer could be kept in gd. That would be one solution. Then full malloc() could be inited in spl_common_init() perhaps. That might be worth a try. Yes shouldn't be too painful. I suspect it would be neutral on code size, too. Another option might be to update the FAT code to use ALLOC_CACHE_ALIGN_BUFFER() instead of malloc(), as it already does in places, and perhaps to disable all caching for this case. Then it might work with simple malloc(). Hmm, then the next platform will have problems because allocating via malloc would be preferable. If really rather fix using dlmalloc instead. Hmm but there is no obvious analysis behind your preference. If we have code like this: do_something_with_fat() { void *buf = malloc(...); ... free(buf); } it seems to me we should convert it to use the stack instead, unless there is some recursion problem, etc. Otherwise we are just causing pointless churn on malloc(). I don't think it's that easy. There are platforms where a big stack size hurts. I don't think such big buffers like MAX_CLUSTERSIZE should be allocated on stack. Another option would be to put the FPGA image in a known position on the media, outside the FAT partition. The position could perhaps be written into a FAT file, and reading just that file in SPL might not involve many free() operations. Sounds like a workaround, too. I think the U-Boot infrastructure should work for the boards, not placing restrictions on them. I'll await your answer to my first question in this email before passing judgement. I hesitate to suggest enhancing simple malloc() to
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Simon, On Sat, 30 Mar 2019 at 15:40, Simon Goldschmidt wrote: > > > > Simon Glass schrieb am Sa., 30. März 2019, 22:18: >> >> Hi Simon, >> >> On Sat, 30 Mar 2019 at 14:50, Simon Goldschmidt >> wrote: >> > >> > >> > >> > Simon Goldschmidt schrieb am Sa., 30. >> > März 2019, 21:18: >> >> >> >> >> >> >> >> Simon Glass schrieb am Sa., 30. März 2019, 21:06: >> >>> >> >>> Hi Simon, >> >>> >> >>> On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt >> >>> wrote: >> >>> > >> >>> > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it >> >>> > clears >> >>> > the bss before calling board_init_f() instead of clearing it before >> >>> > calling >> >>> > board_init_r(). >> >>> > >> >>> > This also ensures that variables placed in BSS can be shared between >> >>> > board_init_f() and board_init_r() in SPL. >> >>> > >> >>> > Such global variables are used, for example, when loading things from >> >>> > FAT >> >>> > before SDRAM is available: the full heap required for FAT uses global >> >>> > variables and clearing BSS after board_init_f() would reset the heap >> >>> > state. >> >>> > An example for such a usage is socfpa_arria10 where an FPGA >> >>> > configuration >> >>> > is required before SDRAM can be used. >> >>> > >> >>> > Make the new option depend on ARM for now until more implementations >> >>> > follow. >> >>> > >> >>> >> >>> I still have objections to this series and I think we should discuss >> >>> other ways of solving this problem. >> >>> >> >>> Does socfgpa have SRAM that could be used before SDRAM is available? >> >>> If so, can we not use that for the configuration? What various are >> >>> actually in BSS that are needed before board_init_r() is called? Can >> >>> they not be in a struct created from malloc()? >> >> >> >> >> >> The problem is the board needs to load an FPGA configuration from FAT >> >> before SDRAM is available. Yes, this is loaded into SRAM of course, but >> >> the whole code until that is done uses so many malloc/free iterations >> >> that The simple mall of implementation would require too much memory. >> >> >> >> And it's the full malloc state variables only that use BSS, not the FAT >> >> code. >> >> >> >> One way out could be to move the full mall of state variables into 'gd'... >> > >> > >> > Maybe I should point out again that the whole purpose of this series is to >> > have an SPL that uses full malloc right from the start. This is currently >> > not possible as full malloc needs BSS. >> >> Right, and our assumption/design is that full malloc() requires SRAM. >> >> Here we have an architecture that requires FAT just to init its SDRAM. >> FAT requires malloc() and free() and there is not enough SRAM to skip >> the free() calls. So we have to use full malloc() and that uses BSS. >> But BSS is not available before board_init_r(). But we need to init >> SDRAM before board_init_r(). >> >> Firstly I'd point out that someone should speak to the chip designers. >> Did anyone try to boot U-Boot on the SoC model? > > > Well, it's a U-Boot thing to load it from FAT. It could probably be loaded > from RAW mmc without problems, so I don't know if it's a chip designers > issue. I think it's an issue that we need to fix in U-Boot: we have a good > full malloc implementation but it's not usable in all cases were it should be. OK then why use FAT? I assumed it was a boot-ROM requirement. How does the boot ROM load SPL? > >> >> I think it is possible to change dlmalloc to put its variables in a >> struct. Then I suppose the struct pointer could be kept in gd. That >> would be one solution. Then full malloc() could be inited in >> spl_common_init() perhaps. > > > That might be worth a try. Yes shouldn't be too painful. I suspect it would be neutral on code size, too. > >> >> Another option might be to update the FAT code to use >> ALLOC_CACHE_ALIGN_BUFFER() instead of malloc(), as it already does in >> places, and perhaps to disable all caching for this case. Then it >> might work with simple malloc(). > > > Hmm, then the next platform will have problems because allocating via malloc > would be preferable. If really rather fix using dlmalloc instead. Hmm but there is no obvious analysis behind your preference. If we have code like this: do_something_with_fat() { void *buf = malloc(...); ... free(buf); } it seems to me we should convert it to use the stack instead, unless there is some recursion problem, etc. Otherwise we are just causing pointless churn on malloc(). > >> >> Another option would be to put the FPGA image in a known position on >> the media, outside the FAT partition. The position could perhaps be >> written into a FAT file, and reading just that file in SPL might not >> involve many free() operations. > > > Sounds like a workaround, too. I think the U-Boot infrastructure should work > for the boards, not placing restrictions on them. I'll await your answer to my first question in this email before passing judgement. > >> >>
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Simon Glass schrieb am Sa., 30. März 2019, 22:18: > Hi Simon, > > On Sat, 30 Mar 2019 at 14:50, Simon Goldschmidt > wrote: > > > > > > > > Simon Goldschmidt schrieb am Sa., 30. > März 2019, 21:18: > >> > >> > >> > >> Simon Glass schrieb am Sa., 30. März 2019, 21:06: > >>> > >>> Hi Simon, > >>> > >>> On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > >>> wrote: > >>> > > >>> > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it > clears > >>> > the bss before calling board_init_f() instead of clearing it before > calling > >>> > board_init_r(). > >>> > > >>> > This also ensures that variables placed in BSS can be shared between > >>> > board_init_f() and board_init_r() in SPL. > >>> > > >>> > Such global variables are used, for example, when loading things > from FAT > >>> > before SDRAM is available: the full heap required for FAT uses global > >>> > variables and clearing BSS after board_init_f() would reset the heap > state. > >>> > An example for such a usage is socfpa_arria10 where an FPGA > configuration > >>> > is required before SDRAM can be used. > >>> > > >>> > Make the new option depend on ARM for now until more implementations > follow. > >>> > > >>> > >>> I still have objections to this series and I think we should discuss > >>> other ways of solving this problem. > >>> > >>> Does socfgpa have SRAM that could be used before SDRAM is available? > >>> If so, can we not use that for the configuration? What various are > >>> actually in BSS that are needed before board_init_r() is called? Can > >>> they not be in a struct created from malloc()? > >> > >> > >> The problem is the board needs to load an FPGA configuration from FAT > before SDRAM is available. Yes, this is loaded into SRAM of course, but the > whole code until that is done uses so many malloc/free iterations that The > simple mall of implementation would require too much memory. > >> > >> And it's the full malloc state variables only that use BSS, not the FAT > code. > >> > >> One way out could be to move the full mall of state variables into > 'gd'... > > > > > > Maybe I should point out again that the whole purpose of this series is > to have an SPL that uses full malloc right from the start. This is > currently not possible as full malloc needs BSS. > > Right, and our assumption/design is that full malloc() requires SRAM. > > Here we have an architecture that requires FAT just to init its SDRAM. > FAT requires malloc() and free() and there is not enough SRAM to skip > the free() calls. So we have to use full malloc() and that uses BSS. > But BSS is not available before board_init_r(). But we need to init > SDRAM before board_init_r(). > > Firstly I'd point out that someone should speak to the chip designers. > Did anyone try to boot U-Boot on the SoC model? > Well, it's a U-Boot thing to load it from FAT. It could probably be loaded from RAW mmc without problems, so I don't know if it's a chip designers issue. I think it's an issue that we need to fix in U-Boot: we have a good full malloc implementation but it's not usable in all cases were it should be. > I think it is possible to change dlmalloc to put its variables in a > struct. Then I suppose the struct pointer could be kept in gd. That > would be one solution. Then full malloc() could be inited in > spl_common_init() perhaps. > That might be worth a try. > Another option might be to update the FAT code to use > ALLOC_CACHE_ALIGN_BUFFER() instead of malloc(), as it already does in > places, and perhaps to disable all caching for this case. Then it > might work with simple malloc(). > Hmm, then the next platform will have problems because allocating via malloc would be preferable. If really rather fix using dlmalloc instead. > Another option would be to put the FPGA image in a known position on > the media, outside the FAT partition. The position could perhaps be > written into a FAT file, and reading just that file in SPL might not > involve many free() operations. > Sounds like a workaround, too. I think the U-Boot infrastructure should work for the boards, not placing restrictions on them. > I hesitate to suggest enhancing simple malloc() to support a free > list. That would increase the code size and I'm not sure it would be > better than using full malloc(). > Yes, I think that might result in making a second dlmalloc :-) Thanks for your thoughts and input! Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Simon, On Sat, 30 Mar 2019 at 14:50, Simon Goldschmidt wrote: > > > > Simon Goldschmidt schrieb am Sa., 30. März > 2019, 21:18: >> >> >> >> Simon Glass schrieb am Sa., 30. März 2019, 21:06: >>> >>> Hi Simon, >>> >>> On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt >>> wrote: >>> > >>> > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it >>> > clears >>> > the bss before calling board_init_f() instead of clearing it before >>> > calling >>> > board_init_r(). >>> > >>> > This also ensures that variables placed in BSS can be shared between >>> > board_init_f() and board_init_r() in SPL. >>> > >>> > Such global variables are used, for example, when loading things from FAT >>> > before SDRAM is available: the full heap required for FAT uses global >>> > variables and clearing BSS after board_init_f() would reset the heap >>> > state. >>> > An example for such a usage is socfpa_arria10 where an FPGA configuration >>> > is required before SDRAM can be used. >>> > >>> > Make the new option depend on ARM for now until more implementations >>> > follow. >>> > >>> >>> I still have objections to this series and I think we should discuss >>> other ways of solving this problem. >>> >>> Does socfgpa have SRAM that could be used before SDRAM is available? >>> If so, can we not use that for the configuration? What various are >>> actually in BSS that are needed before board_init_r() is called? Can >>> they not be in a struct created from malloc()? >> >> >> The problem is the board needs to load an FPGA configuration from FAT before >> SDRAM is available. Yes, this is loaded into SRAM of course, but the whole >> code until that is done uses so many malloc/free iterations that The simple >> mall of implementation would require too much memory. >> >> And it's the full malloc state variables only that use BSS, not the FAT code. >> >> One way out could be to move the full mall of state variables into 'gd'... > > > Maybe I should point out again that the whole purpose of this series is to > have an SPL that uses full malloc right from the start. This is currently not > possible as full malloc needs BSS. Right, and our assumption/design is that full malloc() requires SRAM. Here we have an architecture that requires FAT just to init its SDRAM. FAT requires malloc() and free() and there is not enough SRAM to skip the free() calls. So we have to use full malloc() and that uses BSS. But BSS is not available before board_init_r(). But we need to init SDRAM before board_init_r(). Firstly I'd point out that someone should speak to the chip designers. Did anyone try to boot U-Boot on the SoC model? I think it is possible to change dlmalloc to put its variables in a struct. Then I suppose the struct pointer could be kept in gd. That would be one solution. Then full malloc() could be inited in spl_common_init() perhaps. Another option might be to update the FAT code to use ALLOC_CACHE_ALIGN_BUFFER() instead of malloc(), as it already does in places, and perhaps to disable all caching for this case. Then it might work with simple malloc(). Another option would be to put the FPGA image in a known position on the media, outside the FAT partition. The position could perhaps be written into a FAT file, and reading just that file in SPL might not involve many free() operations. I hesitate to suggest enhancing simple malloc() to support a free list. That would increase the code size and I'm not sure it would be better than using full malloc(). [..] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Simon Goldschmidt schrieb am Sa., 30. März 2019, 21:18: > > > Simon Glass schrieb am Sa., 30. März 2019, 21:06: > >> Hi Simon, >> >> On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt >> wrote: >> > >> > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it >> clears >> > the bss before calling board_init_f() instead of clearing it before >> calling >> > board_init_r(). >> > >> > This also ensures that variables placed in BSS can be shared between >> > board_init_f() and board_init_r() in SPL. >> > >> > Such global variables are used, for example, when loading things from >> FAT >> > before SDRAM is available: the full heap required for FAT uses global >> > variables and clearing BSS after board_init_f() would reset the heap >> state. >> > An example for such a usage is socfpa_arria10 where an FPGA >> configuration >> > is required before SDRAM can be used. >> > >> > Make the new option depend on ARM for now until more implementations >> follow. >> > >> >> I still have objections to this series and I think we should discuss >> other ways of solving this problem. >> >> Does socfgpa have SRAM that could be used before SDRAM is available? >> If so, can we not use that for the configuration? What various are >> actually in BSS that are needed before board_init_r() is called? Can >> they not be in a struct created from malloc()? >> > > The problem is the board needs to load an FPGA configuration from FAT > before SDRAM is available. Yes, this is loaded into SRAM of course, but the > whole code until that is done uses so many malloc/free iterations that The > simple mall of implementation would require too much memory. > > And it's the full malloc state variables only that use BSS, not the FAT > code. > > One way out could be to move the full mall of state variables into 'gd'... > Maybe I should point out again that the whole purpose of this series is to have an SPL that uses full malloc right from the start. This is currently not possible as full malloc needs BSS. Regards, Simon > Another way would be to continue into board_init_f without SDRAM enabled > and in it it later... > > Regards, > Simon > > >> If this is a limitation of FAT, then I think we should fix that, instead. >> >> Regards, >> Simon >> >> > Signed-off-by: Simon Goldschmidt >> > --- >> > >> > Changes in v3: >> > - improve commit message to show why CONFIG_CLEAR_BSS_F is needed >> > >> > Changes in v2: >> > - make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now >> > >> > common/spl/Kconfig | 12 >> > 1 file changed, 12 insertions(+) >> > >> > diff --git a/common/spl/Kconfig b/common/spl/Kconfig >> > index 206c24076d..6a4270516a 100644 >> > --- a/common/spl/Kconfig >> > +++ b/common/spl/Kconfig >> > @@ -156,6 +156,18 @@ config SPL_STACK_R_MALLOC_SIMPLE_LEN >> > to give board_init_r() a larger heap then the initial heap in >> > SRAM which is limited to SYS_MALLOC_F_LEN bytes. >> > >> > +config SPL_CLEAR_BSS_F >> > + bool "Clear BSS section before calling board_init_f" >> > + depends on ARM >> > + help >> > + The BSS section is initialized to zero. In SPL, this is >> normally done >> > + before calling board_init_r(). >> > + For platforms using BSS in board_init_f() already, enable >> this to >> > + clear the BSS section before calling board_init_f() instead of >> > + clearing it before calling board_init_r(). This also ensures >> that >> > + variables placed in BSS can be shared between board_init_f() >> and >> > + board_init_r(). >> > + >> > config SPL_SEPARATE_BSS >> > bool "BSS section is in a different memory region from text" >> > help >> > -- >> > 2.17.1 >> > >> > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Simon Glass schrieb am Sa., 30. März 2019, 21:06: > Hi Simon, > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > wrote: > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it > clears > > the bss before calling board_init_f() instead of clearing it before > calling > > board_init_r(). > > > > This also ensures that variables placed in BSS can be shared between > > board_init_f() and board_init_r() in SPL. > > > > Such global variables are used, for example, when loading things from FAT > > before SDRAM is available: the full heap required for FAT uses global > > variables and clearing BSS after board_init_f() would reset the heap > state. > > An example for such a usage is socfpa_arria10 where an FPGA configuration > > is required before SDRAM can be used. > > > > Make the new option depend on ARM for now until more implementations > follow. > > > > I still have objections to this series and I think we should discuss > other ways of solving this problem. > > Does socfgpa have SRAM that could be used before SDRAM is available? > If so, can we not use that for the configuration? What various are > actually in BSS that are needed before board_init_r() is called? Can > they not be in a struct created from malloc()? > The problem is the board needs to load an FPGA configuration from FAT before SDRAM is available. Yes, this is loaded into SRAM of course, but the whole code until that is done uses so many malloc/free iterations that The simple mall of implementation would require too much memory. And it's the full malloc state variables only that use BSS, not the FAT code. One way out could be to move the full mall of state variables into 'gd'... Another way would be to continue into board_init_f without SDRAM enabled and in it it later... Regards, Simon > If this is a limitation of FAT, then I think we should fix that, instead. > > Regards, > Simon > > > Signed-off-by: Simon Goldschmidt > > --- > > > > Changes in v3: > > - improve commit message to show why CONFIG_CLEAR_BSS_F is needed > > > > Changes in v2: > > - make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now > > > > common/spl/Kconfig | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > index 206c24076d..6a4270516a 100644 > > --- a/common/spl/Kconfig > > +++ b/common/spl/Kconfig > > @@ -156,6 +156,18 @@ config SPL_STACK_R_MALLOC_SIMPLE_LEN > > to give board_init_r() a larger heap then the initial heap in > > SRAM which is limited to SYS_MALLOC_F_LEN bytes. > > > > +config SPL_CLEAR_BSS_F > > + bool "Clear BSS section before calling board_init_f" > > + depends on ARM > > + help > > + The BSS section is initialized to zero. In SPL, this is > normally done > > + before calling board_init_r(). > > + For platforms using BSS in board_init_f() already, enable this > to > > + clear the BSS section before calling board_init_f() instead of > > + clearing it before calling board_init_r(). This also ensures > that > > + variables placed in BSS can be shared between board_init_f() > and > > + board_init_r(). > > + > > config SPL_SEPARATE_BSS > > bool "BSS section is in a different memory region from text" > > help > > -- > > 2.17.1 > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Simon, On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt wrote: > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it clears > the bss before calling board_init_f() instead of clearing it before calling > board_init_r(). > > This also ensures that variables placed in BSS can be shared between > board_init_f() and board_init_r() in SPL. > > Such global variables are used, for example, when loading things from FAT > before SDRAM is available: the full heap required for FAT uses global > variables and clearing BSS after board_init_f() would reset the heap state. > An example for such a usage is socfpa_arria10 where an FPGA configuration > is required before SDRAM can be used. > > Make the new option depend on ARM for now until more implementations follow. > I still have objections to this series and I think we should discuss other ways of solving this problem. Does socfgpa have SRAM that could be used before SDRAM is available? If so, can we not use that for the configuration? What various are actually in BSS that are needed before board_init_r() is called? Can they not be in a struct created from malloc()? If this is a limitation of FAT, then I think we should fix that, instead. Regards, Simon > Signed-off-by: Simon Goldschmidt > --- > > Changes in v3: > - improve commit message to show why CONFIG_CLEAR_BSS_F is needed > > Changes in v2: > - make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now > > common/spl/Kconfig | 12 > 1 file changed, 12 insertions(+) > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > index 206c24076d..6a4270516a 100644 > --- a/common/spl/Kconfig > +++ b/common/spl/Kconfig > @@ -156,6 +156,18 @@ config SPL_STACK_R_MALLOC_SIMPLE_LEN > to give board_init_r() a larger heap then the initial heap in > SRAM which is limited to SYS_MALLOC_F_LEN bytes. > > +config SPL_CLEAR_BSS_F > + bool "Clear BSS section before calling board_init_f" > + depends on ARM > + help > + The BSS section is initialized to zero. In SPL, this is normally > done > + before calling board_init_r(). > + For platforms using BSS in board_init_f() already, enable this to > + clear the BSS section before calling board_init_f() instead of > + clearing it before calling board_init_r(). This also ensures that > + variables placed in BSS can be shared between board_init_f() and > + board_init_r(). > + > config SPL_SEPARATE_BSS > bool "BSS section is in a different memory region from text" > help > -- > 2.17.1 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it clears the bss before calling board_init_f() instead of clearing it before calling board_init_r(). This also ensures that variables placed in BSS can be shared between board_init_f() and board_init_r() in SPL. Such global variables are used, for example, when loading things from FAT before SDRAM is available: the full heap required for FAT uses global variables and clearing BSS after board_init_f() would reset the heap state. An example for such a usage is socfpa_arria10 where an FPGA configuration is required before SDRAM can be used. Make the new option depend on ARM for now until more implementations follow. Signed-off-by: Simon Goldschmidt --- Changes in v3: - improve commit message to show why CONFIG_CLEAR_BSS_F is needed Changes in v2: - make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now common/spl/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 206c24076d..6a4270516a 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -156,6 +156,18 @@ config SPL_STACK_R_MALLOC_SIMPLE_LEN to give board_init_r() a larger heap then the initial heap in SRAM which is limited to SYS_MALLOC_F_LEN bytes. +config SPL_CLEAR_BSS_F + bool "Clear BSS section before calling board_init_f" + depends on ARM + help + The BSS section is initialized to zero. In SPL, this is normally done + before calling board_init_r(). + For platforms using BSS in board_init_f() already, enable this to + clear the BSS section before calling board_init_f() instead of + clearing it before calling board_init_r(). This also ensures that + variables placed in BSS can be shared between board_init_f() and + board_init_r(). + config SPL_SEPARATE_BSS bool "BSS section is in a different memory region from text" help -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot