[PATCH] configs: ast2600: Move SPL bss section to DRAM space

ChiaWei Wang chiawei_wang at aspeedtech.com
Wed Jun 29 02:36:04 CEST 2022


Hi Joel,

> From: Joel Stanley <joel at jms.id.au>
> Sent: Tuesday, June 28, 2022 12:24 PM
> 
> Hi Chai Wei,
> 
> On Wed, 1 Jun 2022 at 08:21, Chia-Wei Wang
> <chiawei_wang at aspeedtech.com> wrote:
> >
> > The commit b583348ca8c8 ("image: fit: Align hash output buffers")
> > places the hash output buffer at the .bss section. However, AST2600 by
> > default executes SPL in the NOR flash XIP way. This results in the
> > hash output cannot be written to the buffer as it is located at the R/X only
> region.
> >
> > We need to move the .bss section out of the SPL body to the DRAM
> > space, where hash output can be written to. This patch includes:
> >  - Define the .bss section base and size
> >  - A new SPL linker script is added with a separate .bss region
> > specified
> >  - Enable CONFIG_SPL_SEPARATE_BSS kconfig option
> >
> > Signed-off-by: Chia-Wei Wang <chiawei_wang at aspeedtech.com>
> 
> This patch breaks booting for me.
> 
> My concern with the approach is it creates extra maintenance work.
> When changes are made to the main linker script they need to be mirrored
> here, or else the aspeed port will miss out. (Having the machine tested in CI
> will help this somewhat, but only for the code paths we can test under
> emulation).

The patch was trying to solve the hash buffer allocation change to common code and to avoid similar issues.
But I agree there is additional maintenance work on the customized linker script.

> 
> I know the patch has been merged, but I have a few questions:
> 
> I imagine the ast2600 is not the only board that runs XIP. How do other boards
> solve the problem?
> 
> What happens when a symbol that is used before DRAM training has
> completed is placed in bss?

Honestly, I am not sure how other platforms/boards dealing with this.
But like U-Boot REAME stated, the initial global data is read-only.
I guess we have to be careful about the global variable use before DRAM initialization or even variable relocation.

> 
> How do you plan to support systems that don't have NOR?

We would like to have another defconfig for eMMC booting.
If the NOR-based linker script is not applicable, the default one can be used.

Chiawei


More information about the U-Boot mailing list