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

[Tom Rini]

On Tue, Jul 25, 2017 at 02:55:18PM +1000, Bin Chen wrote:
> On 24 July 2017 at 00:41, Tom Rini  wrote:
> 
> > On Sun, Jul 23, 2017 at 11:48:53PM +1000, Bin Chen wrote:
> > > On 19 July 2017 at 12:53, Tom Rini  wrote:
> > >
> > > > On Wed, Jul 19, 2017 at 12:44:48PM +1000, Bin Chen wrote:
> > > > > On 18 July 2017 at 22:32, Tom Rini  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  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 
> > > > > > > >
> > > > > > > > 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.
> > > > > >
> > > > >
> > > > 

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

[Bin Chen]

On 24 July 2017 at 00:41, Tom Rini  wrote:

> On Sun, Jul 23, 2017 at 11:48:53PM +1000, Bin Chen wrote:
> > On 19 July 2017 at 12:53, Tom Rini  wrote:
> >
> > > On Wed, Jul 19, 2017 at 12:44:48PM +1000, Bin Chen wrote:
> > > > On 18 July 2017 at 22:32, Tom Rini  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  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 
> > > > > > >
> > > > > > > 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?
> 

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

[Bin Chen]

On 24 July 2017 at 00:41, Tom Rini  wrote:

> On Sun, Jul 23, 2017 at 11:48:53PM +1000, Bin Chen wrote:
> > On 19 July 2017 at 12:53, Tom Rini  wrote:
> >
> > > On Wed, Jul 19, 2017 at 12:44:48PM +1000, Bin Chen wrote:
> > > > On 18 July 2017 at 22:32, Tom Rini  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  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 
> > > > > > >
> > > > > > > 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?
> 

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

[Tom Rini]

On Sun, Jul 23, 2017 at 11:48:53PM +1000, Bin Chen wrote:
> On 19 July 2017 at 12:53, Tom Rini  wrote:
> 
> > On Wed, Jul 19, 2017 at 12:44:48PM +1000, Bin Chen wrote:
> > > On 18 July 2017 at 22:32, Tom Rini  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  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 
> > > > > >
> > > > > > 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 

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

[Bin Chen]

On 19 July 2017 at 12:53, Tom Rini  wrote:

> On Wed, Jul 19, 2017 at 12:44:48PM +1000, Bin Chen wrote:
> > On 18 July 2017 at 22:32, Tom Rini  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  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 
> > > > >
> > > > > 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.

* basically special handling of the BOOTM_STATE_LOADOS for Image format

so that 'bootm' can see that we have an Android-style image and then
> further that we have an Image underneath it, rather than a zImage, and
> handle running it appropriately.

I think bootm, aka "boot application
> image from memory" is the best place to handle both 32 and 64bit Android
> style 

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

[Tom Rini]

On Wed, Jul 19, 2017 at 12:44:48PM +1000, Bin Chen wrote:
> On 18 July 2017 at 22:32, Tom Rini  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  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 
> > > >
> > > > 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
so that 'bootm' can see that we have an Android-style image and then
further that we have an Image underneath it, rather than a zImage, and
handle running it appropriately.  I think bootm, aka "boot application
image from memory" is the best place to handle both 32 and 64bit Android
style images, as things stand today, at least.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Bin Chen]

Andy,

On 14 July 2017 at 17:30, Andy Yan  wrote:

> Hi:
>
> 2017-07-13 15:33 GMT+08:00 Bin Chen :
>
>> Hi Tom,
>>
>> Thanks for the review.
>>
>> On 13 July 2017 at 04:25, Tom Rini  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 
>> >
>> > 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.
>>
>>
>   It seems that bootm doesn't always require a uImage kernel. Consider we
> use bootm to boot a ARM32 based android boot.img.
> we pack the zImage in boot.img directly, without make it to uImage .
>

You are right!


> 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
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>>
>
>


-- 
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Bin Chen]

On 18 July 2017 at 22:32, Tom Rini  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  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 
> > >
> > > 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [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  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 
> >
> > 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


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Andy Yan]

Hi:

2017-07-13 15:33 GMT+08:00 Bin Chen :

> Hi Tom,
>
> Thanks for the review.
>
> On 13 July 2017 at 04:25, Tom Rini  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 
> >
> > 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.
>
>
  It seems that bootm doesn't always require a uImage kernel. Consider we
use bootm to boot a ARM32 based android boot.img.
we pack the zImage in boot.img directly, without make it to uImage .

> 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
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Andy Yan]

Hi:

2017-07-13 15:33 GMT+08:00 Bin Chen :

> Hi Tom,
>
> Thanks for the review.
>
> On 13 July 2017 at 04:25, Tom Rini  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 
> >
> > 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.
>
>


> 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
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Bin Chen]

On 14 July 2017 at 00:55, Rob Herring  wrote:

> On Thu, Jul 13, 2017 at 2:33 AM, Bin Chen  wrote:
> > Hi Tom,
> >
> > Thanks for the review.
> >
> > On 13 July 2017 at 04:25, Tom Rini  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 
> >>
> >> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Bin Chen]

On 14 July 2017 at 00:06, Daniel Thompson 
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  tr...@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.c...@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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Rob Herring]

On Thu, Jul 13, 2017 at 2:33 AM, Bin Chen  wrote:
> Hi Tom,
>
> Thanks for the review.
>
> On 13 July 2017 at 04:25, Tom Rini  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 
>>
>> 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.
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.

> 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. 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
(not something I'd recommend).

Rob
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Daniel Thompson]

On 13/07/17 08:33, Bin Chen wrote:

Hi Tom,

Thanks for the review.

On 13 July 2017 at 04:25, Tom Rini > 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 >

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.





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


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Bin Chen]

Hi Tom,

Thanks for the review.

On 13 July 2017 at 04:25, Tom Rini  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 
>
> 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.

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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Tom Rini]

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 

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

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Bin Chen]

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 
---
 cmd/booti.c | 80 -
 1 file changed, 79 insertions(+), 1 deletion(-)

diff --git a/cmd/booti.c b/cmd/booti.c
index da6fb01..8fab96c 100644
--- a/cmd/booti.c
+++ b/cmd/booti.c
@@ -9,8 +9,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -130,7 +132,7 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
return 0;
 }
 
-int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+int do_booti_a(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
int ret;
 
@@ -159,6 +161,82 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
return ret;
 }
 
+int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   struct andr_img_hdr *hdr;
+   ulong kernel_addr = 0;
+   ulong kernel_len = 0;
+   ulong ramdisk_addr = 0;
+   ulong ramdisk_len = 0;
+   ulong fdt_addr = 0;
+   ulong fdt_len = 0;
+   ulong ramdisk_addr_env = 0;
+   ulong fdt_addr_env = 0;
+
+   if (argc == 4) {
+   debug("normal %s %s %s %s\n", argv[0], argv[1], argv[2], 
argv[3]);
+   return do_booti_a(cmdtp, flag, argc, argv);
+   }
+
+   debug("boot android arm64 bootimage\n");
+   hdr = (struct andr_img_hdr *)simple_strtoul(argv[1], NULL, 16);
+   if (android_image_check_header(hdr)) {
+   printf("invalid android image\n");
+   return -1;
+   }
+
+   android_image_get_kernel(hdr, false, _addr, _len);
+   android_image_get_ramdisk(hdr, _addr, _len);
+   android_image_get_second(hdr, _addr, _len);
+
+   if (fdt_check_header((void*)fdt_addr)) {
+   printf(" error: invalid fdt\n");
+   return -1;
+   }
+
+   /* relocate ramdisk and fdt to the address defined by the environment 
variable.
+* that means we'll ignore the load address of ramdisk and dtb defined 
in the
+* abootimg, since it make more sense letting u-boot handling where to 
put what.
+* kernel relocation will be handled in booti_setup
+*/
+   ramdisk_addr_env = getenv_ulong("ramdisk_addr_r", 16, 0);;
+   fdt_addr_env = getenv_ulong("fdt_addr_r", 16, 0);
+
+   if (!ramdisk_addr_env) {
+   printf(" error: didn't define ramdisk_addr_r\n");
+   return -1;
+   }
+   memmove((void *)ramdisk_addr_env, (void *)ramdisk_addr, ramdisk_len);
+
+   if (!fdt_addr_env) {
+   printf(" error: didn't define fdt_addr_r\n");
+   return -1;
+   }
+   memmove((void *)fdt_addr_env, (void *)fdt_addr, fdt_len);
+
+   const int max_length = 40;
+   const int new_argc = 4;
+   char *new_argv[new_argc];
+
+   for (int i = 0; i < new_argc; i++) {
+   new_argv[i] = (char*) malloc(max_length);
+   }
+
+   strcpy(new_argv[0], "booti");
+   snprintf(new_argv[1], max_length, "0x%lx", kernel_addr);
+   snprintf(new_argv[2], max_length, "0x%lx:%ld", 
ramdisk_addr_env,ramdisk_len);
+   snprintf(new_argv[3], max_length, "0x%lx", fdt_addr_env);
+
+   debug("android: %s %s %s %s\n", new_argv[0], new_argv[1], new_argv[2], 
new_argv[3]);
+
+   int ret = do_booti_a(cmdtp, flag, new_argc, new_argv);
+
+   for (int i = 0; i < new_argc; i++) {
+   free(new_argv[i]);
+   }
+
+   return ret;
+}
 #ifdef CONFIG_SYS_LONGHELP
 static char booti_help_text[] =
"[addr [initrd[:size]] [fdt]]\n"
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot