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 ...
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-52 Fax: +49-8142-66989-80 Email: h...@denx.de
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
