On 24 July 2017 at 00:41, Tom Rini <tr...@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 <tr...@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 <tr...@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 <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. > > > > > > > > > > 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? > -- > Tom > -- Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
