[U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意,邮件由sjg at google.com代发】

Simon Glass sjg at chromium.org
Wed May 22 19:39:52 UTC 2019


Hi Andy,

On Tue, 21 May 2019 at 19:43, Andy Yan <andyshrk at gmail.com> wrote:
>
> Hi Andre:
>
> Andre Przywara <andre.przywara at arm.com> 于2019年5月20日周一 下午11:59写道:
>
> > On Mon, 20 May 2019 14:34:01 +0800
> > Andy Yan <andy.yan at rock-chips.com> wrote:
> >
> > Hi,
> >
> > > On 2019/5/19 上午12:26, Simon Glass wrote:
> > > > Hi Andy,
> > > >
> > > > Instead of this could you:
> > > >
> > > > - move ATF?
> > >
> > > All rockchip based arm64 ATF run from the start 64KB of dram as this
> > > will give convenient for kernel manage the memory.
> >
> > This is just BL31 of ATF, right?
> > ATF recently gained PIE support for BL31 [1], so by just enabling this in
> > platform.mk you will get a relocatable BL31 image, with a very minimal
> > runtime linker. Worked out of the box on Allwinner for me, but YMMV.
> > So you could load newer ATF builds everywhere.
> >
> >
> This is not the root case, actually we want put ATF as close as possible to
> the start of dram, this give linux kernel convenient to manage the memory.

But instead of 64KB you could put it at 32KB or 128KB. It's still in
the first 1MB. Linux won't care, right?

>
>
>
> > Does that help you?
> >
> > > On the other hand, change the ATF load address will break the
> > > compatibility of the exiting firmware.
> >
> > I am not sure what you mean with "compatibility of existing firmware"?
> > Surely you combine all the firmware components (SPL/TPL/ATF/U-Boot proper)
> > into one image? And there would be no real mix and match, with older
> > pre-compiled builds? So by changing the ATF base address and the load
> > address in TPL at the same time you won't have issues?
> >
>
> I mean older pre-compiled builds published by rockchip rkbin [1], many
> projects and popular boards directly use this , for example Armbian. How to
> change the base address of the pre-build binary?
>  [1] https://github.com/rockchip-linux/rkbin

Perhaps I am misunderstanding your intent here, but mainline U-Boot
should not be bound to the design decisions of old closed-source
binaries.

[...]

Regards,
Simon


More information about the U-Boot mailing list