On Fri, Mar 15, 2019 at 05:41:36AM +0100, Heiko Schocher wrote: > Hello Tom, > > Am 13.03.2019 um 19:19 schrieb Tom Rini: > >On Wed, Mar 13, 2019 at 10:18:06AM +0100, Heiko Schocher wrote: > >>Hello Stefano, > >> > >>Am 13.03.2019 um 09:51 schrieb Stefano Babic: > >>>Hi Heiko, > >>> > >>>On 13/03/19 08:44, Heiko Schocher wrote: > >>>>Hello Wolfgang, > >>>> > >>>>Am 12.03.2019 um 18:46 schrieb Wolfgang Denk: > >>>>>Dear Tom, > >>>>> > >>>>>In message <20190312173125.GP4690@bill-the-cat> you wrote: > >>>>>> > >>>>>>>I think you were misled by Heiko's description. What he really ment > >>>>>>>was just that the addresses where the boot ROM stored the > >>>>>>>information about the boot device etc. gets overwriteen when the SPL > >>>>>> > >>>>>>For clarity, that's not _quite_ it. The ROM passes the value in a > >>>>>>register and we move that to scratch space, see > >>>>>>arch/arm/mach-omap2/lowlevel_init.S and save_boot_params. This is done > >>>>>>on every 32bit Cortex-A TI platform. > >>>>>... > >>>>>>OK, but here's the problem. We define off, iirc, 1KiB of that SRAM > >>>>>>space as not-stack but scratch space to store stuff in. The first > >>>>>>problem you will hit, if something else touches that scratch space is > >>>>>>what Heiko found, the boot value got blown away. > >>>>> > >>>>>I see. Well, I think it's best if Heiko explains in detail; what he > >>>>>has observed, and what when which part of the information got lost. > >>>>>I was just interpreting his mail, so I may easily have misunderstood > >>>>>this. > >>>>> > >>>>>@ Heiko: Can you please elucidate? > >>>> > >>>>arch/arm/include/asm/arch-am33xx/omap.h > >>>> > >>>> 19 #ifdef CONFIG_AM33XX > >>>> 20 #define NON_SECURE_SRAM_START 0x402F0400 > >>>> 21 #define NON_SECURE_SRAM_END 0x40310000 > >>>> 22 #define NON_SECURE_SRAM_IMG_END 0x4030B800 > >>>> 23 #elif defined(CONFIG_TI816X) || defined(CONFIG_TI814X) > >>>> 24 #define NON_SECURE_SRAM_START 0x40300000 > >>>> 25 #define NON_SECURE_SRAM_END 0x40320000 > >>>> 26 #define NON_SECURE_SRAM_IMG_END 0x4031B800 > >>>> 27 #elif defined(CONFIG_AM43XX) > >>>> 28 #define NON_SECURE_SRAM_START 0x402F0400 > >>>> 29 #define NON_SECURE_SRAM_END 0x40340000 > >>>> 30 #define NON_SECURE_SRAM_IMG_END 0x40337DE0 > >>>> 31 #define QSPI_BASE 0x47900000 > >>>> 32 #endif > >>>> 33 #define SRAM_SCRATCH_SPACE_ADDR (NON_SECURE_SRAM_IMG_END - SZ_1K) > >>>> 34 > >>>> > >>>> > >>>>and with ./include/configs/ti_armv7_common.h > >>>> > >>>> 69 #ifndef CONFIG_SYS_INIT_SP_ADDR > >>>> 70 #define CONFIG_SYS_INIT_SP_ADDR (NON_SECURE_SRAM_END - \ > >>>> 71 > >>>>GENERATED_GBL_DATA_SIZE) > >>>> 72 #endif > >>>> 73 > >>>> > >>>>include/generated/generic-asm-offsets.h > >>>> > >>>> 9 #define GENERATED_GBL_DATA_SIZE 224 /* (sizeof(struct global_data) + > >>>>15) & ~15 @ */ > >>>> 10 #define GENERATED_BD_INFO_SIZE 112 /* (sizeof(struct bd_info) + 15) > >>>>& ~15 @ */ > >>>> 11 #define GD_SIZE 224 /* sizeof(struct global_data) @ */ > >>>> > >>>> > >>>>-> CONFIG_SYS_INIT_SP_ADDR = 0x40340000 - 0xe0 = 0x4033ff20 > >>>>-> SRAM_SCRATCH_SPACE_ADDR = 0x40337DE0 - 0x400 = 0x403379e0 > >>>> > >>>>./arch/arm/include/asm/omap_common.h: > >>>>816 #define OMAP_SRAM_SCRATCH_BOOT_PARAMS (SRAM_SCRATCH_SPACE_ADDR + > >>>>0x24) > >>>> > >>>>OMAP_SRAM_SCRATCH_BOOT_PARAMS = 0x40337a04 > >>>> > >>>>So stack is on a higher address than the scratch space. Stack > >>>>addresses decrement on usage, so may they overwrite scratch > >>>>space, as SPL functionality grows more and more ... > >>> > >>>What about to move this area after the initial SP ? This is the same way > >>>we do with GENERATED_GBL_DATA_SIZE to avoid to be overwritten. > >> > >>If I am not wrong, the value of SRAM_SCRATCH_SPACE_ADDR is not changeable > >>as it comes from the ROM bootloader. > > > >No, we define the scratch space, but there's important restrictions. > > Ah, with ./arch/arm/mach-omap2/lowlevel_init.S > > 20 #ifdef CONFIG_SPL > 21 ENTRY(save_boot_params) > 22 ldr r1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS > 23 str r0, [r1] > 24 b save_boot_params_ret > 25 ENDPROC(save_boot_params) > > and in the AM437x TRM "5.2.5.1 Overview" I read: > """ > When ROM transfers control to the ISW, it passes a parameter to a > Boot Parameter Structure in R0. The Boot Parameter Structure can > be used to determine the boot device, reset reason, etc. The fields > of this structure are described in Table 5-9 > """
Yup. And please bear in mind that what you see there has been true since OMAP2 days, iirc, and is true for all 32bit Cortex-A TI platforms, basically. It's possible that the keystone platforms are the exception to the rule here, actually. But lots and lots of SoCs with a large age range on them. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot