[U-Boot] [PATCH 1/2] [rfc] parse the second area of android image
The second area of android image was intended to put a 2nd stage bootloader but in practice were rarely used (in my knowledge).
An proposal was made to the AOSP to (re)use the second area as the dtb[1], This patch itself doesn't depend on that proposal being accepted but it won't be that helpful as well if that proposal won't be accepted. But don't do any harm as well.
[1] https://android-review.googlesource.com/#/c/417447/ Signed-off-by: Bin Chen bin.chen@linaro.org --- common/image-android.c | 19 +++++++++++++++++++ include/image.h | 2 ++ 2 files changed, 21 insertions(+)
diff --git a/common/image-android.c b/common/image-android.c index ee03b96..7daa5fa 100644 --- a/common/image-android.c +++ b/common/image-android.c @@ -146,6 +146,25 @@ int android_image_get_ramdisk(const struct andr_img_hdr *hdr, return 0; }
+int android_image_get_second(const struct andr_img_hdr *hdr, + ulong *second_data, ulong *second_len) +{ + if (!hdr->second_size) { + *second_data = *second_len = 0; + return -1; + } + + *second_data = (unsigned long)hdr; + *second_data += hdr->page_size; + *second_data += ALIGN(hdr->kernel_size, hdr->page_size); + *second_data += ALIGN(hdr->ramdisk_size, hdr->page_size); + + printf("second address is 0x%lx\n",*second_data); + + *second_len = hdr->second_size; + return 0; +} + #if !defined(CONFIG_SPL_BUILD) /** * android_print_contents - prints out the contents of the Android format image diff --git a/include/image.h b/include/image.h index 3f26f9b..8264c52 100644 --- a/include/image.h +++ b/include/image.h @@ -1237,6 +1237,8 @@ int android_image_get_kernel(const struct andr_img_hdr *hdr, int verify, ulong *os_data, ulong *os_len); int android_image_get_ramdisk(const struct andr_img_hdr *hdr, ulong *rd_data, ulong *rd_len); +int android_image_get_second(const struct andr_img_hdr *hdr, + ulong *second_data, ulong *second_len); ulong android_image_get_end(const struct andr_img_hdr *hdr); ulong android_image_get_kload(const struct andr_img_hdr *hdr); void android_print_contents(const struct andr_img_hdr *hdr);
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(-)
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"
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!
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:
- 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.
- 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: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 ofbootm, > 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, andI 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.
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.
- 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:
- 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.
- 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: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:
- 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.
- 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:
- 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.
- 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:
- 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 .
- 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
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:
- 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!
- 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:
- 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' ?
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.
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/boo...
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
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/boo...
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.
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.
* 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:
- 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.
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:
- 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.
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:
- 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.
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.
On Tue, Jul 11, 2017 at 03:56:03PM +1000, Bin Chen wrote:
The second area of android image was intended to put a 2nd stage bootloader but in practice were rarely used (in my knowledge).
An proposal was made to the AOSP to (re)use the second area as the dtb[1], This patch itself doesn't depend on that proposal being accepted but it won't be that helpful as well if that proposal won't be accepted. But don't do any harm as well.
[1] https://android-review.googlesource.com/#/c/417447/ Signed-off-by: Bin Chen bin.chen@linaro.org
Reviewed-by: Tom Rini trini@konsulko.com
Hi Tom and other maintainers：
2017-07-13 2:25 GMT+08:00 Tom Rini trini@konsulko.com:
On Tue, Jul 11, 2017 at 03:56:03PM +1000, Bin Chen wrote:
The second area of android image was intended to put a 2nd stage bootloader but in practice were rarely used (in my knowledge).
An proposal was made to the AOSP to (re)use the second area as the
dtb[1],
This patch itself doesn't depend on that proposal being accepted but it
won't
be that helpful as well if that proposal won't be accepted. But don't do any harm as well.
[1] https://android-review.googlesource.com/#/c/417447/ Signed-off-by: Bin Chen bin.chen@linaro.org
Reviewed-by: Tom Rini trini@konsulko.com
Can we get this patch applied now[1/2]？Because some ARM32 platforms also want to use the second area to stored dtb or other resource .
-- Tom
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On 24 August 2017 at 12:58, Andy Yan andyshrk@gmail.com wrote:
Hi Tom and other maintainers：
2017-07-13 2:25 GMT+08:00 Tom Rini trini@konsulko.com:
On Tue, Jul 11, 2017 at 03:56:03PM +1000, Bin Chen wrote:
The second area of android image was intended to put a 2nd stage bootloader but in practice were rarely used (in my knowledge).
An proposal was made to the AOSP to (re)use the second area as the
dtb[1],
This patch itself doesn't depend on that proposal being accepted but it
won't
be that helpful as well if that proposal won't be accepted. But don't do any harm as well.
[1] https://android-review.googlesource.com/#/c/417447/ Signed-off-by: Bin Chen bin.chen@linaro.org
Reviewed-by: Tom Rini trini@konsulko.com
Can we get this patch applied now[1/2]？Because some ARM32 platforms also want to use the second area to stored dtb or other resource .
Let me know if I need to rebase it or something.
p.s: sorry I was busy with other stuff, so wasn't able timely resend/update the patches.
-- Tom
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
participants (5)
-
Andy Yan -
Bin Chen -
Daniel Thompson -
Rob Herring -
Tom Rini