* [U-Boot] Appended DTB Android boot image support @ 2018-04-30 13:04 Ramon Fried 2018-04-30 23:12 ` Simon Glass 2018-05-01 9:20 ` Alex Deymo 0 siblings, 2 replies; 8+ messages in thread From: Ramon Fried @ 2018-04-30 13:04 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] Appended DTB Android boot image support 2018-04-30 13:04 [U-Boot] Appended DTB Android boot image support Ramon Fried @ 2018-04-30 23:12 ` Simon Glass 2018-05-01 5:31 ` Ramon Fried 2018-05-01 9:20 ` Alex Deymo 1 sibling, 1 reply; 8+ messages in thread From: Simon Glass @ 2018-04-30 23:12 UTC (permalink / raw) To: u-boot Hi Ramon, On 30 April 2018 at 07:04, Ramon Fried <ramon.fried@gmail.com> wrote: > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] Appended DTB Android boot image support 2018-04-30 23:12 ` Simon Glass @ 2018-05-01 5:31 ` Ramon Fried 0 siblings, 0 replies; 8+ messages in thread From: Ramon Fried @ 2018-05-01 5:31 UTC (permalink / raw) To: u-boot On Tue, May 1, 2018 at 2:12 AM, Simon Glass <sjg@chromium.org> wrote: > Hi Ramon, > > On 30 April 2018 at 07:04, Ramon Fried <ramon.fried@gmail.com> wrote: >> 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. 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 ? > > Regards, > Simon ^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] Appended DTB Android boot image support 2018-04-30 13:04 [U-Boot] Appended DTB Android boot image support Ramon Fried 2018-04-30 23:12 ` Simon Glass @ 2018-05-01 9:20 ` Alex Deymo 2018-05-01 10:52 ` Ramon Fried 2018-05-05 21:37 ` Sam Protsenko 1 sibling, 2 replies; 8+ messages in thread From: Alex Deymo @ 2018-05-01 9:20 UTC (permalink / raw) To: u-boot 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 Le lun. 30 avr. 2018 à 16:17, Ramon Fried <ramon.fried@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 ? > > 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] Appended DTB Android boot image support 2018-05-01 9:20 ` Alex Deymo @ 2018-05-01 10:52 ` Ramon Fried 2018-05-04 21:38 ` Simon Glass 2018-05-05 21:37 ` Sam Protsenko 1 sibling, 1 reply; 8+ messages in thread From: Ramon Fried @ 2018-05-01 10:52 UTC (permalink / raw) To: u-boot On Tue, May 1, 2018 at 12:20 PM, Alex Deymo <deymo+@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@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 ? >> >> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] Appended DTB Android boot image support 2018-05-01 10:52 ` Ramon Fried @ 2018-05-04 21:38 ` Simon Glass 2018-05-08 16:44 ` Ramon Fried 0 siblings, 1 reply; 8+ messages in thread From: Simon Glass @ 2018-05-04 21:38 UTC (permalink / raw) To: u-boot Hi, On 1 May 2018 at 04:52, Ramon Fried <ramon.fried@gmail.com> wrote: > On Tue, May 1, 2018 at 12:20 PM, Alex Deymo <deymo+@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@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? How can we detect multiple incompatible options? Just by the machine architecture? Can we just use FIT perhaps? >>> >>> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] Appended DTB Android boot image support 2018-05-04 21:38 ` Simon Glass @ 2018-05-08 16:44 ` Ramon Fried 0 siblings, 0 replies; 8+ messages in thread From: Ramon Fried @ 2018-05-08 16:44 UTC (permalink / raw) To: u-boot On Fri, May 4, 2018, 10:38 PM Simon Glass <sjg@chromium.org> wrote: > Hi, > > On 1 May 2018 at 04:52, Ramon Fried <ramon.fried@gmail.com> wrote: > > On Tue, May 1, 2018 at 12:20 PM, Alex Deymo <deymo+@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@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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] Appended DTB Android boot image support 2018-05-01 9:20 ` Alex Deymo 2018-05-01 10:52 ` Ramon Fried @ 2018-05-05 21:37 ` Sam Protsenko 1 sibling, 0 replies; 8+ messages in thread From: Sam Protsenko @ 2018-05-05 21:37 UTC (permalink / raw) To: u-boot On 1 May 2018 at 12:20, Alex Deymo <deymo+@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 > > 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 > 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 > > > Le lun. 30 avr. 2018 à 16:17, Ramon Fried <ramon.fried@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 ? >> >> 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 >> > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > https://lists.denx.de/listinfo/u-boot ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-05-08 16:44 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-04-30 13:04 [U-Boot] Appended DTB Android boot image support Ramon Fried 2018-04-30 23:12 ` Simon Glass 2018-05-01 5:31 ` Ramon Fried 2018-05-01 9:20 ` Alex Deymo 2018-05-01 10:52 ` Ramon Fried 2018-05-04 21:38 ` Simon Glass 2018-05-08 16:44 ` Ramon Fried 2018-05-05 21:37 ` Sam Protsenko
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.