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

[Bin Chen]

On 18 July 2017 at 22:32, Tom Rini <trini at konsulko.com> wrote:

> On Thu, Jul 13, 2017 at 05:33:08PM +1000, Bin Chen 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.
>
> There's some confusion here.  bootm is not only for "uImage" kernels.
> It for example handles the aarch32 Android image format.
>
> > 2. bootm path doesn't have the logic that is currently in the booti, such
> > as the
> > kernel relocation.
>
> Now I'm confused, what is different in an "Android" image for aarch64
> than from a standard aarch64 Linux kernel 'Image' ?
>

Android image wraps the 'Image'. There is a section called “kernel” in
Android
image, and will place the Image there [1]. Do you think it is the right way
to do that?

I think that's the case for aarch32 android image as well, but replace the
'Image' with
aarch32 kernel build target - I don't know what the format of that target
is.

[1]
https://android.googlesource.com/platform/system/core/+/master/mkbootimg/bootimg.h


> > 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.
>
> Well, there's some discussion in the archives about this.  The short
> answer is that "bootm" wasn't supposed to become a "figure out whatever
> this image is, boot it" command.
>

Good to know the idea beyond that and what bootm isn't supposed to be.
That helps to decide whether we should stuff things into bootm or having a
separate one.


> In hindsight, now, I'm thinking that the aarch32 Android image support
> maybe should have gone into "bootandroid" and in turn it would be easier
> to get someone to write a new command, say "bootauto" that would ask
> bootm/bootelf/bootefi/bootandroid/bootz/booti/etc if it liked the image
> found at $address and if so, boot it, and if not, move on to checking
> the next type.
>

That seems the idea what many people agree upon. Not sure how easy
to move aarch32 support out and I don't have a aarch32 platform to test.
Do you think we'll want to start with aarch64 (considering that may be the
aarch
for most android phone out there) and have a separate boota(ndroid) command?


> --
> Tom
>



-- 
Regards,
Bin