[U-Boot] Appended DTB Android boot image support

Discussion:

Ramon Fried

2018-04-30 13:04:46 UTC

Hi all.
I'm currently adding support for Qualcomm Dragonboards to U-boot as a
primary bootloader without chain-loading using LK which is currently
already supported in mainline U-boot.

Qualcomm Android images are regular android images where the DTB's are
appended to the image. Qualcomm used the "unused" field in the image
header to populate the size of the DTB *.

I'm looking for a more standard version for supporting these kind of images.
Currently, to boot these images, you must provide DTB somewhere in mem
and provide it as argument to bootm for instance.

My goal is to add support that U-boot will parse the image, see that
the DTB is included and use that as the FDT automatically.

I'm looking at the "secondary" fields which are currently not used as
a valid option to point to the DTB and it's size.

Do you know if someone is working on something similar, or do you have
any suggestions for the right approach to this issue ?

Thanks,
Ramon

* - Actually, Qualcomm appends a pack of DTBs with offset table and
chooses the right DTB in runtime.

Simon Glass

2018-04-30 23:12:34 UTC

Permalink

Hi Ramon,

Post by Ramon Fried
Hi all.
I'm currently adding support for Qualcomm Dragonboards to U-boot as a
primary bootloader without chain-loading using LK which is currently
already supported in mainline U-boot.
Qualcomm Android images are regular android images where the DTB's are
appended to the image. Qualcomm used the "unused" field in the image
header to populate the size of the DTB *.
I'm looking for a more standard version for supporting these kind of images.
Currently, to boot these images, you must provide DTB somewhere in mem
and provide it as argument to bootm for instance.
My goal is to add support that U-boot will parse the image, see that
the DTB is included and use that as the FDT automatically.
I'm looking at the "secondary" fields which are currently not used as
a valid option to point to the DTB and it's size.
Do you know if someone is working on something similar, or do you have
any suggestions for the right approach to this issue ?

Have you thought of using FIT? It suppose multiple DTB files, multiple
kernels, compression, etc. and is readily extensible.

Regards,
Simon

Ramon Fried

2018-05-01 05:31:03 UTC

Permalink

Post by Simon Glass
Hi Ramon,

Have you thought of using FIT? It suppose multiple DTB files, multiple
kernels, compression, etc. and is readily extensible.

It's an option I'm considering, but I think it will much more suitable
to keep the
android image format, this way I could support fastboot and also still
use qualcomm proprietary tools
for flashing the images in the right place.

I did notice also that building uImage in Linux kernel doesn't work on
arm64 targets, did I miss something ?

Post by Simon Glass
Regards,
Simon

Alex Deymo

2018-05-01 09:20:18 UTC

Permalink

Hi Ramon,

What "header_version" is the boot image you have? The
include/android_image.h in U-Boot is a little bit old so it only defines
the v0 format. The "unused" field in v0 was renamed to "header_version"
where 0 means v0. The v1 adds a few more fields, including a DTB/DTBO for
*recovery* mode.
See
https://android.googlesource.com/platform/system/core/+/master/mkbootimg/include/bootimg/bootimg.h

Having multiple DTs and picking one or merge overlays at runtime is a
reasonable thing and there's some documentation in AOSP on how to do it in
Android: https://source.android.com/devices/architecture/dto/multiple (and
other sections around it). There are some options on where to store these
and even a supported format for placing multiple .dtbo in a single "dtbo"
partition (but appending multiple DTBs at the end of the kernel is not one
of these).

Which are the "seconday" fields you are referring to?
I'm not familiar with the Dragonboard images, but it looks like they just
extended this over the reserved space in a different way. Maybe you can
convert the header to the newer format, but that still requires work in
U-Boot to support the new format.

Regards,
Alex

Ramon Fried

2018-05-01 10:52:35 UTC

Permalink

Yes, the U-boot has the v0 version.

Post by Simon Glass
Having multiple DTs and picking one or merge overlays at runtime is a
reasonable thing and there's some documentation in AOSP on how to do it in
Android: https://source.android.com/devices/architecture/dto/multiple (and
other sections around it). There are some options on where to store these
and even a supported format for placing multiple .dtbo in a single "dtbo"
partition (but appending multiple DTBs at the end of the kernel is not one
of these).
Which are the "seconday" fields you are referring to?

uint32_t second_size; /* size in bytes */
uint32_t second_addr; /* physical load addr */

In https://android.googlesource.com/platform/system/core/+/master/mkbootimg/include/bootimg/bootimg.h

Post by Simon Glass
I'm not familiar with the Dragonboard images, but it looks like they just
extended this over the reserved space in a different way. Maybe you can
convert the header to the newer format, but that still requires work in
U-Boot to support the new format.

I'm willing to do it, I just want to get some approval from
maintainers before I dive in.

Thanks,
Ramon

Post by Simon Glass
Regards,
Alex

Simon Glass

2018-05-04 21:38:05 UTC

Permalink

Hi,

Post by Ramon Fried

https://android.googlesource.com/platform/system/core/+/master/mkbootimg/include/bootimg/bootimg.h

Post by Ramon Fried
Yes, the U-boot has the v0 version.

uint32_t second_size; /* size in bytes */
uint32_t second_addr; /* physical load addr */
In

https://android.googlesource.com/platform/system/core/+/master/mkbootimg/include/bootimg/bootimg.h

Post by Ramon Fried

I'm willing to do it, I just want to get some approval from
maintainers before I dive in.
Thanks,
Ramon

Post by Simon Glass
Regards,
Alex

Does every vendor just do its own thing, or is there a standard header
structure?

How can we detect multiple incompatible options? Just by the machine
architecture?

Can we just use FIT perhaps?

Post by Ramon Fried

Post by Simon Glass

Post by Ramon Fried
Thanks,
Ramon
* - Actually, Qualcomm appends a pack of DTBs with offset table and
chooses the right DTB in runtime.
_______________________________________________
U-Boot mailing list
https://lists.denx.de/listinfo/u-boot

Regards,
Simon

Sam Protsenko

2018-05-05 21:37:52 UTC

Permalink

Post by Simon Glass
Hi Ramon,
What "header_version" is the boot image you have? The
include/android_image.h in U-Boot is a little bit old so it only defines
the v0 format. The "unused" field in v0 was renamed to "header_version"
where 0 means v0. The v1 adds a few more fields, including a DTB/DTBO for
*recovery* mode.
See
https://android.googlesource.com/platform/system/core/+/master/mkbootimg/include/bootimg/bootimg.h
Having multiple DTs and picking one or merge overlays at runtime is a
reasonable thing and there's some documentation in AOSP on how to do it in
Android: https://source.android.com/devices/architecture/dto/multiple (and
other sections around it). There are some options on where to store these
and even a supported format for placing multiple .dtbo in a single "dtbo"
partition (but appending multiple DTBs at the end of the kernel is not one
of these).

Hi Alex,

Can you please review these (related) patches [1,2] I sent recently? I
think it would be nice to have those in upstream U-Boot, as Android
documentation recommends its usage [3].

Also, do you know is it mandatory to use that format [3] for Android,
or it's just a recommendation? I haven't found any mentioning in
Android docs that it's strictly required. We'd like to just use FIT,
as it was already established before Android DT image format, and TI
was already using it for regular Linux boot. Do you know if Google has
any plans to make it mandatory to use [3] in the future, like for
project Treble, etc?

Thanks!

[1] https://lists.denx.de/pipermail/u-boot/2018-April/326050.html
[2] https://lists.denx.de/pipermail/u-boot/2018-April/326051.html
[3] https://source.android.com/devices/architecture/dto/partitions

Post by Simon Glass
Which are the "seconday" fields you are referring to?
I'm not familiar with the Dragonboard images, but it looks like they just
extended this over the reserved space in a different way. Maybe you can
convert the header to the newer format, but that still requires work in
U-Boot to support the new format.
Regards,
Alex

_______________________________________________
U-Boot mailing list
https://lists.denx.de/listinfo/u-boot