On Saturday, April 25, 2015 at 08:22:26 AM, Maxime Ripard wrote:
On Thu, Apr 23, 2015 at 02:00:01PM +0200, Marek Vasut wrote:
On Thursday, April 23, 2015 at 09:41:04 AM, Maxime Ripard wrote:
On Wed, Apr 22, 2015 at 05:56:23PM +0200, Marek Vasut wrote:
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.
Looks like MX6 DRAM base address, so this should definitelly not be fixed to this address here. The +0x8000 offset is the kernel load offset.
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.
Yep.
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'd expect the image to be correct in the first place though ;-)
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.
Then I'd say such "default" address should be something like 0xffffffff .
I'd probably agree if we were on a perfect world :)
But the fact is that the tools that are creating these boot.img in Android all have this default, and *will* fill the kernel address header to this value.
https://android.googlesource.com/platform/system/core/+/master/fastboot /fas tboot.cpp, line 72 https://android.googlesource.com/platform/system/core/+/master/mkbootim g/m kbootimg.c, line 112
So even if we send a patch to Android itself, that won't fix the tools that are already in the source code of published Android versions, or the packages bundled in the distribution.
So I think that instead of blindly trusting these tools, U-Boot should handle that address has the de facto default, even if it doesn't make any sense :)
OK, now I agree. Maybe we should fix both -- the tools and U-Boot.
I'll try to cook up a patch, send it to AOSP and see how it goes.
Ok, thank you!
Best regards, Marek Vasut