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

[Tom Rini]

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' ?

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

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170718/8b8db43f/attachment.sig>