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