On 14 July 2017 at 00:55, Rob Herring rob.herring@linaro.org wrote:
On Thu, Jul 13, 2017 at 2:33 AM, Bin Chen bin.chen@linaro.org wrote:
Hi Tom,
Thanks for the review.
On 13 July 2017 at 04:25, Tom Rini trini@konsulko.com wrote:
On Tue, Jul 11, 2017 at 03:56:04PM +1000, Bin Chen wrote:
It's my understanding that we are supposed to use booti, instead of bootm, for arm64 image. But booti lacks of android image support. Bootm has the andriod image support but lack of the arm64 image handling.
So, what is suppose the right way of booting an android arm64 image? or, should we create a separate command?
This patch is an invitation for that discussion.
It *hacked* the booti command and it aslo assume the dtb is in the second area of android boot image. It also has other belives like u-boot should be in control of where to put the kernnel/ramdisk/dtb images so it
ignores
the value specified in the android images.
Signed-off-by: Bin Chen bin.chen@linaro.org
So, booti is very much for the "Image" format described in the Linux kernel in Documentation/arm64/booting.txt. One can (and people have) used bootm on aarch64 for "uImage" style kernels and FIT kernels, and I would see being able to boot an aarch64 Android image with bootm as the way to go forward.
Are you suggesting that we should use bootm path, instead of booti?
I have two questions regarding this:
- currently arm64 kernel don't have a uImage kernel target. And I'm not
sure if adding that will be something that is wanted and/or sensible.
Sure it does. You just run mkimage with the Image and create one. I suppose you mean that step is not integrated into the kernel build.
Yes, that's what I mean.
That is not wanted. As Daniel pointed out, a uImage is platform specific is the first reason. Also, putting every bootloader's custom format into the kernel build doesn't really scale.
Thanks for the clarification.
- bootm path doesn't have the logic that is currently in the booti,
such as
the kernel relocation.
Also, one other question raised during internal discussion was why the
booti
was created in the first place, if we could have had that implemented in
the
bootm path.
I think for simplicity. The bootm logic and command line options are already complicated enough.
I can appreciate that :)
Of course with that logic, we should have made Android images a separate command too (some pre-mainline versions of Android boot support did do a boota command). Though, IIRC I think you can boot an Android boot image containing a uImage for the kernel
I tried but didn't succeed on that (using bootm with uImage created from a arm64 Image ). I didn't dig deeper and changed the route to trying the booti path instead.
But there are a few things I observed on the bootm path:
- load address: uImage specified the load address that isn't quite right for arch64 (as Daniel pointed out) (and in general, bootm path don't arm64 boot requirement correctly as booti did) - dtb handling : for arm64 , dtb must be provided; while arm32 kernel can handle concatenated dtb. And since android image don't have a place to put the dtb, so it seems not possible to get that implemented generically. I don't know how the boota command is implemented to pass the dtb information.
(not something I'd recommend).
Rob