[U-Boot] Appended DTB Android boot image support

[Ramon Fried]

On Fri, May 4, 2018, 10:38 PM Simon Glass <sjg at chromium.org> wrote:

> Hi,
>
> On 1 May 2018 at 04:52, Ramon Fried <ramon.fried at gmail.com> wrote:
> > On Tue, May 1, 2018 at 12:20 PM, Alex Deymo <deymo+ at google.com> wrote:
> >> 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
> >>
> > Yes, the U-boot has the v0 version.
> >
> >> 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
> >>
> >> 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
> >>
> >> Regards,
> >> Alex
> >>
> >>
> >> Le lun. 30 avr. 2018 à 16:17, Ramon Fried <ramon.fried at gmail.com> a
> écrit :
> >>>
> >>> 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 ?
>
> Does every vendor just do its own thing, or is there a standard header
> structure?
>
I don't know. I'm familiar only with Qualcomm way. Not sure about the rest.

>
> How can we detect multiple incompatible options? Just by the machine
> architecture?
>
Qualcomm is using the unused fields in version 1 of Android boot header. I
guess that ifdef in the source code is the only way.

>
> Can we just use FIT perhaps?
>
Of course we can, I already booted successfully with FIT. But it will
require users to repackage their kernel boot image.


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