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

[Bin Chen]

On 14 July 2017 at 00:06, Daniel Thompson <daniel.thompson at linaro.org>
wrote:

> On 13/07/17 08:33, Bin Chen wrote:
>
>> Hi Tom,
>>
>> Thanks for the review.
>>
>> On 13 July 2017 at 04:25, Tom Rini <trini at konsulko.com <mailto:
>> 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 <mailto:
>> 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.
>>
>
> All arm64 kernels are multi-platform (even if for some minimized builds
> only drivers for one platform are actually enabled). That means a uImage
> kernel target is problematic because the kernel build system does not know
> its eventual physical load address. On arm64 that is entirely delegated to
> the bootloader.
>
> That doesn't mean uImage can never be used; just that the kernel build
> system has no business authoring one.


Yes, that's exactly what I mean, and why I'm tentative adding a uImage
target for arm64.
Actually I did add that target and found the issue you described.


>
>
>
>> 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.
>>
>>
>>     The analogy would be that we use bootm for Android
>>     on arm not bootz.  Thanks!
>>
>>     --
>>     Tom
>>
>>
>>
>>
>> --
>> Regards,
>> Bin
>>
>
>


-- 
Regards,
Bin