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

Fri Mar 15 16:10:23 UTC 2019

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190315/d81c0d23/attachment.sig>