| Message ID | 1499752564-10488-2-git-send-email-bin.chen@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2,rfc] parse the second area of android image | expand |
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. The analogy would be that we use bootm for Android on arm not bootz. Thanks! -- Tom
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. 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 >
On 13/07/17 08:33, Bin Chen wrote: > Hi Tom, > > Thanks for the review. > > On 13 July 2017 at 04:25, Tom Rini <trini@konsulko.com > <mailto: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 <mailto: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. 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
On Thu, Jul 13, 2017 at 2:33 AM, Bin Chen <bin.chen@linaro.org> 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. 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
On 14 July 2017 at 00:06, Daniel Thompson <daniel.thompson@linaro.org> 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 <trini@konsulko.com <mailto: >> 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 <mailto: >> 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. >> > > 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 >> > >
On 14 July 2017 at 00:55, Rob Herring <rob.herring@linaro.org> wrote: > On Thu, Jul 13, 2017 at 2:33 AM, Bin Chen <bin.chen@linaro.org> 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. > > 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 >
Hi: 2017-07-13 15:33 GMT+08:00 Bin Chen <bin.chen@linaro.org>: > 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. > > > 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 >
Hi: 2017-07-13 15:33 GMT+08:00 Bin Chen <bin.chen@linaro.org>: > 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. > > 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 >
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' ? > 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
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? > -- > Tom >
Andy, On 14 July 2017 at 17:30, Andy Yan <andyshrk@gmail.com> wrote: > Hi: > > 2017-07-13 15:33 GMT+08:00 Bin Chen <bin.chen@linaro.org>: > >> 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. >> >> > 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 >> > >
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 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
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. * 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 images, as things stand today, at least. I agree this method aligns best with what we have today (we are using bootm for 32 bit) and requires least code change (compared with having a separate bootandroid command, we can save it for another day though :) ). > > -- > Tom >
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. -- Tom
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. > OK. I'm not sure familiar with those files and will take a look at them and come back later (with more questions :) ). > -- > Tom >
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? > -- > Tom >
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. -- Tom
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 <bootm.h> #include <command.h> #include <image.h> +#include <libfdt.h> #include <lmb.h> #include <mapmem.h> +#include <stdlib.h> #include <linux/kernel.h> #include <linux/sizes.h> @@ -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, &kernel_addr, &kernel_len); + android_image_get_ramdisk(hdr, &ramdisk_addr, &ramdisk_len); + android_image_get_second(hdr, &fdt_addr, &fdt_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"
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> --- cmd/booti.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 79 insertions(+), 1 deletion(-)