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. Stefano > > Hmm... I see, the NON_SECURE_SRAM_IMG_END is fix defined, and we cannot > move it. > > Ok, looking on my own now on the hardware: > > => md 40337a04 > 40337a04: 40338dc4 8f943b1e 8138beca 4ea1b2c2 ..3@.;....8.... > ^ > pointer to bootparms struct > > => md.b 40338dc4 > 40338dc4: ff ff ff ff 08 8f 33 40 07 01 00 00 00 00 00 00 > ......3@........ > ^^ > bootmode 0x07 -> mmc0 > > Nothing overwritten here! Puuh... > > But I have a bad feeling reading the bootmode again from U-Boot, as > the boot_params info is may in space, where stack can overwrite it ... > >>> I agree here. Fixing things up such that we can pass things we know >>> =66rom one stage to another in a defined manner, rather than ad-hoc >>> manner, is good. We could even, probably, re-work most of that use of >>> scratch space to be done in another way, or make it safe to re-use >>> later. >> >> Thanks a lot! Let's go for it. > > To be safe here, we should really pass the bootmode (or more common, > the infos collected already in GD) from SPL to U-Boot ... > > bye, > Heiko -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
