[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Rob Herring]

On Thu, Jul 13, 2017 at 2:33 AM, Bin Chen <bin.chen at linaro.org> wrote:
> Hi Tom,
>
> Thanks for the review.
>
> On 13 July 2017 at 04:25, Tom Rini <trini at 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 at 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:
>
> 1. 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.
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.

> 2. 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. 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
(not something I'd recommend).

Rob