Re: [SPAM] Re: [PATCH v2] xilinx: zynqmp: Do not use 0 as spl bss start address

From: Xavier Drudis Ferran <xdrudis@tinet.cat>
To: Stefan Herbrechtsmeier <stefan.herbrechtsmeier-oss@weidmueller.com>
Cc: Michal Simek <monstr@monstr.eu>, U-Boot <u-boot@lists.denx.de>,
	Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>,
	Michal Simek <michal.simek@amd.com>
Subject: Re: [SPAM] Re: [PATCH v2] xilinx: zynqmp: Do not use 0 as spl bss start address
Date: Fri, 10 Jun 2022 18:48:13 +0200	[thread overview]
Message-ID: <20220610164813.GE1735@begut> (raw)
In-Reply-To: <25751198-541e-9fa0-a23a-db0069eb9327@weidmueller.com>

El Fri, Jun 10, 2022 at 04:42:55PM +0200, Stefan Herbrechtsmeier deia:
> Hi Michal,
> 
> what is the default entry address for the aft / bl31.bin?
> 
> I have a bl31.bin with an entry address of 0x1000 and this is inside the
> BSS.
>

Me too, load address at 0x1000, but for me in SPL text, not BSS.

I have a litle customized, a little old TF-A  for rk3399 / Rock pi 4
loading at address 0 with entry at 0x1000. 

But include/configs/rk3399_common.h sets my 
CONFIG_SPL_BSS_START_ADDR=0x400000, away from harm.
I had problems booting anyway.

Now I can load U-Boot from MMC with these patches 
https://lists.denx.de/pipermail/u-boot/2022-June/485497.html

In particular 
CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x15000

This is defined in arch/arm/mach-rockchip/Kconfig and says it's 
to avoid conflicts with SPL text area, not BSS

But I found other boards with CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000,
so I thought some low addresses where normal. I don't know.

I had to modify the code loading from SPI because, unlike MMC code, it
thought address 0 meant no destination (I can send those patches when
I have them cleaner if anyone wants them).

I just realised that I have CONFIG_SPL_TEXT_BASE=0x0.  I'm not finding
where that's defined, maybe it's simply because it's not defined
anywhere, so maybe the solution for me would be setting CONFIG_SPL_TEXT_BASE
to 0x10000000 or something. Or maybe it needs to be at 0x0 because
it is bootrom who is loading it, and it won't look where I define it?
I can't remember whether I tried this. 

Maybe you can try to look at the size of a file bl31_0x00000000.bin
that is generated when you build U-boot with BL31 pointing at your
bl31.elf (check u-boot.its if that's not the name for you).

Then set CONFIG_SPL_BSS_START_ADDR to that size + L (L= value of load property 
in entry atf_1 of u-boot.its). This should leave a hole at the beginning
of U-Boot to make room for your TF-A, and leave BSS elsewhere. 

The sources and build scripts for TF-A are public, so maybe one could 
look at what's the criteria for putting images at different addresses?