[U-Boot] passing info from SPL to U-Boot

[Heiko Schocher]

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 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.

If I am not wrong, the value of SRAM_SCRATCH_SPACE_ADDR is not changeable
as it comes from the ROM bootloader.

bye,
Heiko
> 
> 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-52   Fax: +49-8142-66989-80   Email: hs at denx.de