[U-Boot] [PATCH] arm: Allow u-boot to run from offset base address

[Wolfgang Denk]

Dear Darwin,

In message <5374CC3B.7000504 at broadcom.com> you wrote:
> 
> I mean that the loader loads u-boot to it's correct address, which is
> offset by a small amount because of a previous header requiring alignment.
> Here's an example. u-boot is compiled to run at 0x88000020 because we want
> to put a small header in front of the image, which starts at 0x88000000 and
> needs to be aligned for its own reasons. Now for arm64, I believe that u-boot
> cannot normally be positioned at any alignment less than 0x800 hex. So

I thing you have some misunderstanding of the meaning of the start
address of the image versus the entry point address.  These are not
related.  You can add any headers or padding you like to the image,
and put the entry point at an arbitrary address.

The restrictions we usually face are due to the bootmodes of the SoC,
which may start from a fixed reset address (whwere we then must make
sure that this is also the entry point address in the image), or where
the ROM boot loader may have specific requirements.

If you add some custom image header, you can also start at some random
entry point addres.. Just adapt your linker script as needed.

> And in these cases the relocation works fine. But if we want to position u-boot
> at a smaller offset than 0x800, the symbol relocation breaks for arm64. It
> turns out that there is a trivial fix so that u-boot can run at smaller offset
> addresses, which I have provided here, is tested, and solves our problem nicely,
> but only for arm64 right now.

No, your patch is highly dubious actually.  Note that the entry point
address which we are talking about is where code execution starts
_before_ relocation.  Relocation is a totally different topic.  The
address where we relocate to gets computed at runtime, and does not
depend on CONFIG_SYS_TEXT_BASE at all.  Also, as had been pointed out
before, memory allocation happens top down, so any adjustments you
want to make must be to lower addresses, never upward.

> Yes, I agree, but I am not sure if this is a arm64-only problem or not.

Unfortunaltely you don't explain what you really want to do. We have
the same task (loading the U-Boot image and starting it) in many,
nmany configurations either when a ROM boot loader performs the
loading, or where the SPL does it.  This is a well understood
procedure, and it has no such problem as you claim to have.

I suspect you have bugs elsewhere in your port, may it be the linker
script or your implementation of a special image header or whatever.

> can provide on how to proceed would be appreciated. And if the fix is
> not suitable for upstreaming, then we should know it.

Please understand that this is not a question of suitable for
upstreaming or not, it is a matter of correct or not.  I am pretty
much convinced that your modifcation cannot be right.

> Also there might be a generic fix possible that works for all architectures
> (by removing the ifdef CONFIG_ARM64), but I don't have the resources to test
> them. Maybe it would be best to decide if we want to support this feature or
> not first. Thanks!

Please define "this feature" in an exact way, and why you think it
would cause any problems.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Disc space - the final frontier!