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

Tue Jul 25 22:13:36 UTC 2017

On Tue, Jul 25, 2017 at 02:55:18PM +1000, Bin Chen wrote:
> On 24 July 2017 at 00:41, Tom Rini <trini at konsulko.com> wrote:
> 
> > On Sun, Jul 23, 2017 at 11:48:53PM +1000, Bin Chen wrote:
> > > On 19 July 2017 at 12:53, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > > On Wed, Jul 19, 2017 at 12:44:48PM +1000, Bin Chen wrote:
> > > > > 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?
> > > >
> > > > I think the best path forward today is to make sure that whatever
> > > > aarch64-Image support code that's needed from cmd/booti.c is available
> > > >
> > >
> > > Just to confirm you are suggesting to move the aarch64-Image support
> > code(*)
> > > from cmd/booti.c to common/bootm.c, is that right? This sounds good to
> > me.
> >
> > Well, I think we need to change how cmd/booti.c handles the logic to be
> > more like how cmd/bootz.c does.  Perhaps arch/arm/lib/image.c.
> >
> 
> I took a quick look at the bootz code. the bootz.c will call bootz_setup,
> which
> defined in the arch/arm/lib/zImage.c so here you want to follow the same
> pattern,
> by moving booti_setup to the  arm/arm/lib/image.c (yet to be created).
> 
> That looks good to me.
> 
> The only question I have is where in the bootm path we are going call
> booti_setup (
> or we won't?) for arch64 andriod image (which contains an Image within).
> 
> And, the code in booti_setup() is equivalent to the BOOTM_STATE_FINDOS and
> BOOTM_STATE_LOADOS, and that is overlapped or conflict with the bootm
> implementation done in bootm_find_os and bootm_load_os.  We can do some
> checks in those path/functions, if it is the Image format, we will wait
> that to be done
> in the booti_setup(). But seems a little bit messy.
> 
> Am I on the right path?

You'll have to do some experimenting to see how to best re-use the code
here, but yes, I think you're on the right track.

-- 
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/20170725/668f36d2/attachment.sig>