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