[U-Boot] passing info from SPL to U-Boot
Stefano Babic
sbabic at denx.de
Wed Mar 13 08:51:29 UTC 2019
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 at 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 at .;....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 at ........
> ^^
> 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: sbabic at denx.de
=====================================================================
More information about the U-Boot
mailing list