Dear Darwin,
In message 5374E64B.1060104@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