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

[Bin Chen]

On 14 July 2017 at 00:55, Rob Herring <rob.herring at linaro.org> wrote:

> 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.
>

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.

>
> > 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.


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
>



-- 
Regards,
Bin