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@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: h...@denx.de
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to