diff mbox series

[U-Boot,v2,5/5] fdt: boot_get_fdt: android: use ENV 'fdtaddr' as fallback

Message ID 20190401105252.30002-1-erosca@de.adit-jv.com
State Accepted
Commit 62392675cdea46ca38a4d2b9be2c82e29b3b6da3
Delegated to: Simon Glass
Headers show
Series boot_get_fdt: clean up and use 'fdtaddr' as fallback for Android | expand

Commit Message

Eugeniu Rosca April 1, 2019, 10:52 a.m. UTC
Our platform doesn't store the DTB into the Android image second area,
but rather copies the DTB to RAM from a dedicated dtb.img partition [0],
prior to booting the Android image by calling bootm.

Similar to [1], we find it useful to just call 'bootm' and have the
right DTB being passed to OS (assuming its address has been previously
stored in 'fdtaddr' by calling `fdt addr <dtb-addr>`).

Booting Android with DTB from 'fdtaddr' will only occur if:
 - No DTB is embedded in the second area of Android image
 - 'fdtaddr' points to a valid DTB in RAM

[0] https://source.android.com/devices/architecture/dto/partitions
[1] https://patchwork.ozlabs.org/patch/1046652/
    ("Support boot Android image without address on bootm command")

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
Changes in v2:
 - Removed fdt_totalsize() computation, since FDT size verification is
   only relevant for blobs embedded in U-Boot-supported images
 - Link v1: https://patchwork.ozlabs.org/patch/1071591/
---
 common/image-fdt.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

Comments

Eugeniu Rosca April 1, 2019, 3:26 p.m. UTC | #1
Hi All, especially the Android specialists,

On Mon, Apr 01, 2019 at 12:52:52PM +0200, Eugeniu Rosca wrote:
> Our platform doesn't store the DTB into the Android image second area,
> but rather copies the DTB to RAM from a dedicated dtb.img partition [0],
> prior to booting the Android image by calling bootm.
> 
> Similar to [1], we find it useful to just call 'bootm' and have the
> right DTB being passed to OS (assuming its address has been previously
> stored in 'fdtaddr' by calling `fdt addr <dtb-addr>`).
> 
> Booting Android with DTB from 'fdtaddr' will only occur if:
>  - No DTB is embedded in the second area of Android image
>  - 'fdtaddr' points to a valid DTB in RAM
> 
> [0] https://source.android.com/devices/architecture/dto/partitions
> [1] https://patchwork.ozlabs.org/patch/1046652/
>     ("Support boot Android image without address on bootm command")

FWIW, I believe this patch could make use of the "second address" [1]
stored in the Android image to fulfill my use-case, even if the second
area is left empty. I believe some consensus is needed about that in
community.

With this alternative approach, changing the DTB RAM address would mean
regenerating the Android image, so it would be somewhat less flexible.

I am curious if anybody has gone through the same use-case, as it is
hard to believe I am the first one booting an image lacking the DTB
in its second area.

Best regards,
Eugeniu.

[1] => iminfo 4c000000

## Checking Image at 4c000000 ...
   Android image found
   kernel size:      85b9d1
   kernel address:   48080000
   ramdisk size:     54ddbc
   ramdisk addrress: 4a180000
   second size:      0  
   second address:   48000800
   tags address:     48000100
   page size:        800
   os_version:       1200012a (ver: 0.9.0, level: 2018.10)
   name:                
   cmdline:          buildvariant=userdebug
Simon Glass April 21, 2019, 7:26 p.m. UTC | #2
Hi Eugeniu,

On Mon, 1 Apr 2019 at 03:54, Eugeniu Rosca <erosca@de.adit-jv.com> wrote:
>
> Our platform doesn't store the DTB into the Android image second area,
> but rather copies the DTB to RAM from a dedicated dtb.img partition [0],
> prior to booting the Android image by calling bootm.
>
> Similar to [1], we find it useful to just call 'bootm' and have the
> right DTB being passed to OS (assuming its address has been previously
> stored in 'fdtaddr' by calling `fdt addr <dtb-addr>`).
>
> Booting Android with DTB from 'fdtaddr' will only occur if:
>  - No DTB is embedded in the second area of Android image
>  - 'fdtaddr' points to a valid DTB in RAM
>
> [0] https://source.android.com/devices/architecture/dto/partitions
> [1] https://patchwork.ozlabs.org/patch/1046652/
>     ("Support boot Android image without address on bootm command")
>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---
> Changes in v2:
>  - Removed fdt_totalsize() computation, since FDT size verification is
>    only relevant for blobs embedded in U-Boot-supported images
>  - Link v1: https://patchwork.ozlabs.org/patch/1071591/
> ---
>  common/image-fdt.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

We could really use a simple test of Android booting (not the whole
process, just the setup and the different cases we support)

Regards,
Simon
Simon Glass April 22, 2019, 2:38 a.m. UTC | #3
Hi Eugeniu,

On Mon, 1 Apr 2019 at 03:54, Eugeniu Rosca <erosca@de.adit-jv.com> wrote:
>
> Our platform doesn't store the DTB into the Android image second area,
> but rather copies the DTB to RAM from a dedicated dtb.img partition [0],
> prior to booting the Android image by calling bootm.
>
> Similar to [1], we find it useful to just call 'bootm' and have the
> right DTB being passed to OS (assuming its address has been previously
> stored in 'fdtaddr' by calling `fdt addr <dtb-addr>`).
>
> Booting Android with DTB from 'fdtaddr' will only occur if:
>  - No DTB is embedded in the second area of Android image
>  - 'fdtaddr' points to a valid DTB in RAM
>
> [0] https://source.android.com/devices/architecture/dto/partitions
> [1] https://patchwork.ozlabs.org/patch/1046652/
>     ("Support boot Android image without address on bootm command")
>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---
> Changes in v2:
>  - Removed fdt_totalsize() computation, since FDT size verification is
>    only relevant for blobs embedded in U-Boot-supported images
>  - Link v1: https://patchwork.ozlabs.org/patch/1071591/
> ---
>  common/image-fdt.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

We could really use a simple test of Android booting (not the whole
process, just the setup and the different cases we support)

Regards,
Simon

Applied to u-boot-dm, thanks!
diff mbox series

Patch

diff --git a/common/image-fdt.c b/common/image-fdt.c
index a5d8b41d0209..3aa5ffff0f69 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -469,7 +469,15 @@  int boot_get_fdt(int flag, int argc, char * const argv[], uint8_t arch,
 
 			debug("## Using FDT in Android image second area\n");
 		} else {
-			goto no_fdt;
+			fdt_addr = env_get_hex("fdtaddr", 0);
+			if (!fdt_addr)
+				goto no_fdt;
+
+			fdt_blob = map_sysmem(fdt_addr, 0);
+			if (fdt_check_header(fdt_blob))
+				goto no_fdt;
+
+			debug("## Using FDT at ${fdtaddr}=Ox%lx\n", fdt_addr);
 		}
 #endif
 	} else {