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

[Heiko Schocher]

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

this makes sense now ... thanks for clarifying.

I think, in the first step we do not need to change this here.

I try to investigate some time for passing gd_t between TPL/SPL and
U-Boot ... may this makes sense for variables like dram start, size
bootparameters, baudrate ... but gd_t needs some cleanup restructuring
here.

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