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

[Wolfgang Denk]

Dear Darwin,

In message <5374E64B.1060104 at broadcom.com> you wrote:
> 
> > This makes no sense to me.  CONFIG_SYS_TEXT_BASE is a compile time
> > constant.  So the result of all this is always known at compile time,
> > too.  I feel you misunderstand that CONFIG_SYS_TEXT_BASE is just the
> > start address of the text segment.  If you want to offset this by a
> > specific amount, you can just define this as needed.
> 
> May I respectfully ask that you please bear with me a just a bit longer so
> I can try to explain things better?
> 
> CONFIG_SYS_TEXT_BASE is also used by the relocation calculations at runtime
> to determine the relocation offset, which is also used for the symbol fixup
> logic. It is known at compile time, but is used at runtime by the stock
> u-boot code to determine the relocation offset. I am doing nothing more than
> existing code in this regard.

Let's have a look at your proposed code:

>> +		int offset = CONFIG_SYS_TEXT_BASE % 4096;
>> +		if (offset) {
>> +			addr += offset;
>> +			debug("Relocation Addr bumped to 0x%08lx\n", addr);
>> +		}

> If I set it to 0x88000020, then the code crashes because the symbol fixup
> depends on the relocation offset which is now wrong. The reason is that the
> relocation offset calculated in the code doesn't account for this offset.
> If we adjust the relocation address, then the relocation offset is now
> correct and the symbol fixups work perfectly.

First, please keep in mind that you cannot set CONFIG_SYS_TEXT_BASE in
arbitrary ways, at least not without adjusting your linker script
accordingly; also you may have limitations due to the way how the code
gets loaded / booted.  

_If_ your code is correct, then the target address computed for the
relocation is completely irrelevant.

> Here's an example:
> CONFIG_SYS_TEXT_BASE = 0x88000020
> relocated address = 0xfffa8000   (This 4K alignment assumption breaks the relocation)
> relocation offset = 0x77fa7fe0   (This is now wrong and the relocation breaks)
> 
> My patch does the following:
> CONFIG_SYS_TEXT_BASE = 0x88000020
> relocated address = 0xfffa8020
> relocation offset = 0x77fa8000   (symbol fixups now work)

You are mixing up copying code to another address range and relocating
symbols.

> So this patch just gives us a way to run u-boot at text sections with
> smaller alignments. In the past I never really understood why
> CONFIG_SYS_TEXT_BASE had to be on specific alignments like XXXXX000 for
> our architecture and the symbol fixup issue helps to explain this.

In many cases there is no strict reason.  When storing the images in
NOR flash or other block oriented storage it is usually convenient to
align them to sector boundaaries.  In systems where you have a MMU on,
it may be useful / convenient / necessary to have it aligned to page
boundaries.  But al this is totally irrelevant here.  Consider the
address arbitrarily chosen, it does not matter.

Also, moving the relocation address around by arbitrary amounts (that
are big enough not to cause alignment issues, say anything that is a
multiple of the cache line size) does not change anything.

If there are problems, these are somewhere in your implementation, and
not in the generic code.

> I know this is not the normal use case but it does fix the crash in the
> symbol relocation with arm64 and allows u-boot to be more flexible in
> it's text alignment requirements.

You ask for a "flexibility" that actually is already there; it's just
conveniend when debugging etc. to have "nice" addresses.  If there is
something not working, it's in your code.

Setting CONFIG_SYS_TEXT_BASE to something like 0x88000020 is extremly
fishy.  If you want to add some header data to your image, you should
not shift the text segment, but rather include your header in the
start of the text segment.  Or keep it completely separate, without
messing with CONFIG_SYS_TEXT_BASE.  


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
"We don't care.  We don't have to.  We're the Phone Company."