On Tue, Jul 25, 2017 at 02:55:18PM +1000, Bin Chen wrote:
On 24 July 2017 at 00:41, Tom Rini trini@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@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@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@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@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.