[U-Boot] [PATCH 1/2] [rfc] parse the second area of android image

[U-Boot] [PATCH 1/2] [rfc] parse the second area of android image

[Bin Chen]

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);
-- 
1.9.1

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Bin Chen]

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"
-- 
1.9.1

[U-Boot] [PATCH 1/2] [rfc] parse the second area of android image

[Tom Rini]

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>

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170712/a46bef24/attachment.sig>

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170712/f4071d0f/attachment.sig>

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Bin Chen]

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] [PATCH 2/2] [rfc] support booting arm64 android image

[Daniel Thompson]

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 at 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

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Rob Herring]

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

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Bin Chen]

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 at 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 at 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
>>
>
>


-- 
Regards,
Bin

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Bin Chen]

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
>



-- 
Regards,
Bin

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Andy Yan]

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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Andy Yan]

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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170718/8b8db43f/attachment.sig>

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Bin Chen]

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
>



-- 
Regards,
Bin

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Bin Chen]

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 at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>>
>
>


-- 
Regards,
Bin

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170718/7dd0904c/attachment.sig>

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Bin Chen]

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
>



-- 
Regards,
Bin

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170723/24bc2bf8/attachment.sig>

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Bin Chen]

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
>



-- 
Regards,
Bin

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Bin Chen]

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
>



-- 
Regards,
Bin

[U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170725/668f36d2/attachment.sig>

[U-Boot] [PATCH 1/2] [rfc] parse the second area of android image

[Andy Yan]

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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
>

[U-Boot] [PATCH 1/2] [rfc] parse the second area of android image

[Bin Chen]

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 at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>>
>>
>


-- 
Regards,
Bin