
On Wed, Apr 22, 2015 at 8:04 AM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi,
I've been trying to use fastboot (and especially the boot command) on sunxi recently, and got it to work pretty fine (apart from PSCI, but that's another story).
The only thing that worries me a bit is that by default, both the fastboot tool and mkbootimg will generate an image with the kernel address set to 0x10008000.
While it might work on some targets, it obviously doesn't on the Allwinner SoCs that most of the time have the RAM mapped to 0x4000000, which result in the kernel being relocated to some address that is not in RAM, failing badly.
I would expect U-Boot to relocate the kernel to some reasonable address, and not try to do something dumb by actually trusting completely the boot image.
I guess one way to solve this would be to really treat 0x10008000 as the default, and relocate the kernel to whatever value make sense on the current platform (even though that needs to be defined).
That way, "fastboot boot zImage" would actually work out of the box, without requiring to set the optional "-b" option to set the kernel base address to some decent value.
The others implementation I could find seem to just ignore this field in the image header, and always load it to the same address, which might not really be what we're after here.
What do you think?
Android boot image is pretty broken in a variety of ways and with vendors doing their own extensions/hacks. The issues I see are:
- Addresses are 32-bit - A boot image will only work on 1 platform (because of the kernel and ramdisk addresses) - Different kernel Image formats within boot.img: uImage, zImage, Image.gz, etc. - No standard way to deal with dtb. arm32 is somewhat "standard" with appended dtb. AOSP adds appended dtb for arm64, but it is never going upstream.
For the kernel address, we should probably just ignore it. For zImage, it doesn't really need to be moved from where ever the boot.img is loaded to (assuming it is within the zImage address requirements). It is going to relocate itself anyway. Putting in a correct kernel address will just cause a double copy. For arm64 Image, the image header defines the offset and u-boot must load it to that offset or you won't boot. There's only 1 correct address and 2^32 - 1 wrong addresses the boot.img could have.
Rob