by Laurent Pinchart

[permalink] [raw]

Subject: Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

On Thu, Dec 07, 2023 at 01:52:53PM -0700, Simon Glass wrote:
> On Thu, 7 Dec 2023 at 07:38, Laurent Pinchart wrote:
> > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > Hi Simon,
> > > >
> > > > Thank you for the patch.
> > > >
> > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > containing the built kernel and associated devicetree files.
> > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > performance.
> > > > >
> > > > > The files compress from about 86MB to 24MB using this approach.
> > > > >
> > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > devicetree, matching the compatible string of the running board with
> > > > > the closest compatible string in the FIT. There is no need for
> > > > > filenames or other workarounds.
> > > > >
> > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > FIT_COMPRESSION to select a different algorithm.
> > > > >
> > > > > The FIT can be examined using 'dumpimage -l'.
> > > > >
> > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > requires compression utilities for the algorithm being used. Supported
> > > > > compression options are the same as the Image.xxx files. For now there
> > > > > is no way to change the compression other than by editing the rule for
> > > > > $(obj)/image.fit
> > > > >
> > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > this here, since it must be built separately from the Linux build.
> > > >
> > > > FIT images are very useful, so I think this is a very welcome addition
> > > > to the kernel build system. It can get tricky though: given the
> > > > versatile nature of FIT images, there can't be any
> > > > one-size-fits-them-all solution to build them, and striking the right
> > > > balance between what makes sense for the kernel and the features that
> > > > users may request will probably lead to bikeshedding. As we all love
> > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > > to delay merging this series.
> > > >
> > > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > extending the supported command line arguments. It would perhaps be more
> > > > difficult to integrate in the kernel build system though. This leads me
> > > > to a second question: would you consider merging extensions to this
> > > > script if they are not used by the kernel build system, but meant for
> > > > users who manually invoke the script ? More generally, is the script
> > >
> > > We'd also be interested in some customization, though in a different way.
> > > We imagine having a rule file that says X compatible string should map
> > > to A base DTB, plus B and C DTBO for the configuration section. The base
> > > DTB would carry all common elements of some device, while the DTBOs
> > > carry all the possible second source components, like different display
> > > panels or MIPI cameras for instance. This could drastically reduce the
> > > size of FIT images in ChromeOS by deduplicating all the common stuff.
> >
> > Do you envision the "mapping" compatible string mapping to a config
> > section in the FIT image, that would bundle the base DTB and the DTBOs ?
> >
> > > > meant to be used stand-alone as well, in which case its command line
> > > > arguments need to remain backward-compatible, or do you see it as being
> > > > internal to the kernel ?
>
> It is great to see all this discussion! I did send a proposal to the
> U-Boot ML about extensions but it was mixed up with other things, so
> I'll start a new thread.
>
> For now, I am really just waiting for this to be applied, before
> talking too much about future possibilities.

Sure, I don't see any reason to delay this series until you have fixed
everybody's system images problems :-)

--
Regards,

Laurent Pinchart

2023-12-08 11:48:33

by Nicolas Schier

[permalink] [raw]

Subject: Re: [PATCH v9 1/2] arm64: Add BOOT_TARGETS variable

On Fri, Dec 01, 2023 at 08:54:41PM -0700, Simon Glass wrote:
> Add a new variable containing a list of possible targets. Mark them as
> phony. This matches the approach taken for arch/arm
>
> Signed-off-by: Simon Glass <[email protected]>
> ---

Reviewed-by: Nicolas Schier <[email protected]>

Attachments:

(No filename) (300.00 B)
signature.asc (849.00 B)
Download all attachments

2023-12-08 11:49:36

2023-12-14 04:03:32

by Chen-Yu Tsai

[permalink] [raw]

Subject: Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

On Sun, Dec 10, 2023 at 1:31 AM Geert Uytterhoeven <[email protected]> wrote:
>
> Hi Laurent,
>
> On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart
> <[email protected]> wrote:
> > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> > > <[email protected]> wrote:
> > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > > containing the built kernel and associated devicetree files.
> > > > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > > > performance.
> > > > > > >
> > > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > > >
> > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > > devicetree, matching the compatible string of the running board with
> > > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > > filenames or other workarounds.
> > > > > > >
> > > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > >
> > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > >
> > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > > > requires compression utilities for the algorithm being used. Supported
> > > > > > > compression options are the same as the Image.xxx files. For now there
> > > > > > > is no way to change the compression other than by editing the rule for
> > > > > > > $(obj)/image.fit
> > > > > > >
> > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > > > this here, since it must be built separately from the Linux build.
> > > > > >
> > > > > > FIT images are very useful, so I think this is a very welcome addition
> > > > > > to the kernel build system. It can get tricky though: given the
> > > > > > versatile nature of FIT images, there can't be any
> > > > > > one-size-fits-them-all solution to build them, and striking the right
> > > > > > balance between what makes sense for the kernel and the features that
> > > > > > users may request will probably lead to bikeshedding. As we all love
> > > > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > > > > to delay merging this series.
> > > > > >
> > > > > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > > > extending the supported command line arguments. It would perhaps be more
> > > > > > difficult to integrate in the kernel build system though. This leads me
> > > > > > to a second question: would you consider merging extensions to this
> > > > > > script if they are not used by the kernel build system, but meant for
> > > > > > users who manually invoke the script ? More generally, is the script
> > > > >
> > > > > We'd also be interested in some customization, though in a different way.
> > > > > We imagine having a rule file that says X compatible string should map
> > > > > to A base DTB, plus B and C DTBO for the configuration section. The base
> > > > > DTB would carry all common elements of some device, while the DTBOs
> > > > > carry all the possible second source components, like different display
> > > > > panels or MIPI cameras for instance. This could drastically reduce the
> > > > > size of FIT images in ChromeOS by deduplicating all the common stuff.
> > > >
> > > > Do you envision the "mapping" compatible string mapping to a config
> > > > section in the FIT image, that would bundle the base DTB and the DTBOs ?
> > >
> > > That's exactly the idea. The mapping compatible string could be untied
> > > from the base board's compatible string if needed (which we probably do).
> > >
> > > So something like:
> > >
> > > config {
> > > config-1 {
> > > compatible = "google,krane-sku0";
> > > fdt = "krane-baseboard", "krane-sku0-overlay";
> > > };
> > > };
> > >
> > > With "krane-sku0-overlay" being an overlay that holds the differences
> > > between the SKUs, in this case the display panel and MIPI camera (not
> > > upstreamed) that applies to SKU0 in particular.
> >
> > The kernel DT makefiles already contain information on what overlays to
> > apply to what base boards, in order to test the overlays and produce
> > "full" DTBs. Maybe that information could be leveraged to create the
> > configurations in the FIT image ?
>
> Although the "full" DTBs created may only be a subset of all possible
> combinations (I believe Rob just started with creating one "full" DTB
> for each overlay, cfr. the additions I made in commit a09c3e105a208580
> ("arm64: dts: renesas: Apply overlays to base dtbs")), that could
> definitely be a start.
>
> Now, since the kernel build system already creates "full" DTBs, does
> that mean that all of the base DTBs, overlays, and "full" DTBs will
> end up in the FIT image?

I suppose we could add an option to the packing tool to be able to _not_
add the "full" DTBs if they can also be assembled with a base DTB and
overlays. Think of it as a firmware compatibility option: if the firmware
supports overlays, then you almost always want the deconstructed parts,
not the fully assembled ones. Vice versa.

If we don't we could end up with two configurations that have the same
compatible string?

ChenYu

> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds

2023-12-14 06:13:00

by Masahiro Yamada

[permalink] [raw]

Subject: Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

On Thu, Dec 14, 2023 at 1:03 PM Chen-Yu Tsai <[email protected]> wrote:
>
> On Sun, Dec 10, 2023 at 1:31 AM Geert Uytterhoeven <[email protected]> wrote:
> >
> > Hi Laurent,
> >
> > On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart
> > <[email protected]> wrote:
> > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> > > > <[email protected]> wrote:
> > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > > > containing the built kernel and associated devicetree files.
> > > > > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > > > > performance.
> > > > > > > >
> > > > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > > > >
> > > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > > > devicetree, matching the compatible string of the running board with
> > > > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > > > filenames or other workarounds.
> > > > > > > >
> > > > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > >
> > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > >
> > > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > > > > requires compression utilities for the algorithm being used. Supported
> > > > > > > > compression options are the same as the Image.xxx files. For now there
> > > > > > > > is no way to change the compression other than by editing the rule for
> > > > > > > > $(obj)/image.fit
> > > > > > > >
> > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > > > > this here, since it must be built separately from the Linux build.
> > > > > > >
> > > > > > > FIT images are very useful, so I think this is a very welcome addition
> > > > > > > to the kernel build system. It can get tricky though: given the
> > > > > > > versatile nature of FIT images, there can't be any
> > > > > > > one-size-fits-them-all solution to build them, and striking the right
> > > > > > > balance between what makes sense for the kernel and the features that
> > > > > > > users may request will probably lead to bikeshedding. As we all love
> > > > > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > > > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > > > > > to delay merging this series.
> > > > > > >
> > > > > > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > > > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > > > > extending the supported command line arguments. It would perhaps be more
> > > > > > > difficult to integrate in the kernel build system though. This leads me
> > > > > > > to a second question: would you consider merging extensions to this
> > > > > > > script if they are not used by the kernel build system, but meant for
> > > > > > > users who manually invoke the script ? More generally, is the script
> > > > > >
> > > > > > We'd also be interested in some customization, though in a different way.
> > > > > > We imagine having a rule file that says X compatible string should map
> > > > > > to A base DTB, plus B and C DTBO for the configuration section. The base
> > > > > > DTB would carry all common elements of some device, while the DTBOs
> > > > > > carry all the possible second source components, like different display
> > > > > > panels or MIPI cameras for instance. This could drastically reduce the
> > > > > > size of FIT images in ChromeOS by deduplicating all the common stuff.
> > > > >
> > > > > Do you envision the "mapping" compatible string mapping to a config
> > > > > section in the FIT image, that would bundle the base DTB and the DTBOs ?
> > > >
> > > > That's exactly the idea. The mapping compatible string could be untied
> > > > from the base board's compatible string if needed (which we probably do).
> > > >
> > > > So something like:
> > > >
> > > > config {
> > > > config-1 {
> > > > compatible = "google,krane-sku0";
> > > > fdt = "krane-baseboard", "krane-sku0-overlay";
> > > > };
> > > > };
> > > >
> > > > With "krane-sku0-overlay" being an overlay that holds the differences
> > > > between the SKUs, in this case the display panel and MIPI camera (not
> > > > upstreamed) that applies to SKU0 in particular.
> > >
> > > The kernel DT makefiles already contain information on what overlays to
> > > apply to what base boards, in order to test the overlays and produce
> > > "full" DTBs. Maybe that information could be leveraged to create the
> > > configurations in the FIT image ?
> >
> > Although the "full" DTBs created may only be a subset of all possible
> > combinations (I believe Rob just started with creating one "full" DTB
> > for each overlay, cfr. the additions I made in commit a09c3e105a208580
> > ("arm64: dts: renesas: Apply overlays to base dtbs")), that could
> > definitely be a start.
> >
> > Now, since the kernel build system already creates "full" DTBs, does
> > that mean that all of the base DTBs, overlays, and "full" DTBs will
> > end up in the FIT image?
>
> I suppose we could add an option to the packing tool to be able to _not_
> add the "full" DTBs if they can also be assembled with a base DTB and
> overlays. Think of it as a firmware compatibility option: if the firmware
> supports overlays, then you almost always want the deconstructed parts,
> not the fully assembled ones. Vice versa.
>
> If we don't we could end up with two configurations that have the same
> compatible string?

Right.

We would end up with such situations because applying
an overlay does not change the compatible string.

With this code in arch/arm64/boot/dts/ti/Makefile:

k3-am642-tqma64xxl-mbax4xxl-sdcard-dtbs := \
k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs := \
k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo

$ fdtdump arch/arm64/boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb
2>/dev/null| head -n15 | tail -n2
model = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
compatible = "tq,am642-tqma6442l-mbax4xxl", "tq,am642-tqma6442l",
"ti,am642";

$ fdtdump arch/arm64/boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl-wlan.dtb
2>/dev/null| head -n15 | tail -n2
model = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
compatible = "tq,am642-tqma6442l-mbax4xxl", "tq,am642-tqma6442l",
"ti,am642";

These two go into image.fit, but one of them is completely dead
since there is no way to distinguish them.

$ fdtdump arch/arm64/boot/image.fit

...

conf-10 {
compatible = "tq,am642-tqma6442l-mbax4xxl",
"tq,am642-tqma6442l", "ti,am642";
description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
fdt = "fdt-10";
kernel = "kernel";
};

...

conf-25 {
compatible = "tq,am642-tqma6442l-mbax4xxl",
"tq,am642-tqma6442l", "ti,am642";
description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
fdt = "fdt-25";
kernel = "kernel";
};

I agree with Chen-Yu.

FIT should not include full DTBs.

Bootloaders should assemble the final DTB
from base and overlays on-the-fly.

The FIT spec allows the "fdt" property to list
multiple image nodes.

o config-1
|- description = "configuration description"
|- kernel = "kernel sub-node unit name"
|- fdt = "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", ...]
|- loadables = "loadables sub-node unit-name"
|- script = "
|- compatible = "vendor

>
> ChenYu
>
>
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like that.
> > -- Linus Torvalds

--
Best Regards
Masahiro Yamada

2023-12-14 07:34:29

by Masahiro Yamada

[permalink] [raw]

Subject: Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

On Thu, Dec 14, 2023 at 3:12 PM Masahiro Yamada <[email protected]> wrote:
>
> On Thu, Dec 14, 2023 at 1:03 PM Chen-Yu Tsai <[email protected]> wrote:
> >
> > On Sun, Dec 10, 2023 at 1:31 AM Geert Uytterhoeven <[email protected]> wrote:
> > >
> > > Hi Laurent,
> > >
> > > On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart
> > > <[email protected]> wrote:
> > > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> > > > > <[email protected]> wrote:
> > > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > > > > containing the built kernel and associated devicetree files.
> > > > > > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > > > > > performance.
> > > > > > > > >
> > > > > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > > > > >
> > > > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > > > > devicetree, matching the compatible string of the running board with
> > > > > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > > > > filenames or other workarounds.
> > > > > > > > >
> > > > > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > > >
> > > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > > >
> > > > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > > > > > requires compression utilities for the algorithm being used. Supported
> > > > > > > > > compression options are the same as the Image.xxx files. For now there
> > > > > > > > > is no way to change the compression other than by editing the rule for
> > > > > > > > > $(obj)/image.fit
> > > > > > > > >
> > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > > > > > this here, since it must be built separately from the Linux build.
> > > > > > > >
> > > > > > > > FIT images are very useful, so I think this is a very welcome addition
> > > > > > > > to the kernel build system. It can get tricky though: given the
> > > > > > > > versatile nature of FIT images, there can't be any
> > > > > > > > one-size-fits-them-all solution to build them, and striking the right
> > > > > > > > balance between what makes sense for the kernel and the features that
> > > > > > > > users may request will probably lead to bikeshedding. As we all love
> > > > > > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > > > > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > > > > > > to delay merging this series.
> > > > > > > >
> > > > > > > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > > > > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > > > > > extending the supported command line arguments. It would perhaps be more
> > > > > > > > difficult to integrate in the kernel build system though. This leads me
> > > > > > > > to a second question: would you consider merging extensions to this
> > > > > > > > script if they are not used by the kernel build system, but meant for
> > > > > > > > users who manually invoke the script ? More generally, is the script
> > > > > > >
> > > > > > > We'd also be interested in some customization, though in a different way.
> > > > > > > We imagine having a rule file that says X compatible string should map
> > > > > > > to A base DTB, plus B and C DTBO for the configuration section. The base
> > > > > > > DTB would carry all common elements of some device, while the DTBOs
> > > > > > > carry all the possible second source components, like different display
> > > > > > > panels or MIPI cameras for instance. This could drastically reduce the
> > > > > > > size of FIT images in ChromeOS by deduplicating all the common stuff.
> > > > > >
> > > > > > Do you envision the "mapping" compatible string mapping to a config
> > > > > > section in the FIT image, that would bundle the base DTB and the DTBOs ?
> > > > >
> > > > > That's exactly the idea. The mapping compatible string could be untied
> > > > > from the base board's compatible string if needed (which we probably do).
> > > > >
> > > > > So something like:
> > > > >
> > > > > config {
> > > > > config-1 {
> > > > > compatible = "google,krane-sku0";
> > > > > fdt = "krane-baseboard", "krane-sku0-overlay";
> > > > > };
> > > > > };
> > > > >
> > > > > With "krane-sku0-overlay" being an overlay that holds the differences
> > > > > between the SKUs, in this case the display panel and MIPI camera (not
> > > > > upstreamed) that applies to SKU0 in particular.
> > > >
> > > > The kernel DT makefiles already contain information on what overlays to
> > > > apply to what base boards, in order to test the overlays and produce
> > > > "full" DTBs. Maybe that information could be leveraged to create the
> > > > configurations in the FIT image ?
> > >
> > > Although the "full" DTBs created may only be a subset of all possible
> > > combinations (I believe Rob just started with creating one "full" DTB
> > > for each overlay, cfr. the additions I made in commit a09c3e105a208580
> > > ("arm64: dts: renesas: Apply overlays to base dtbs")), that could
> > > definitely be a start.
> > >
> > > Now, since the kernel build system already creates "full" DTBs, does
> > > that mean that all of the base DTBs, overlays, and "full" DTBs will
> > > end up in the FIT image?
> >
> > I suppose we could add an option to the packing tool to be able to _not_
> > add the "full" DTBs if they can also be assembled with a base DTB and
> > overlays. Think of it as a firmware compatibility option: if the firmware
> > supports overlays, then you almost always want the deconstructed parts,
> > not the fully assembled ones. Vice versa.
> >
> > If we don't we could end up with two configurations that have the same
> > compatible string?
>
>
> Right.
>
> We would end up with such situations because applying
> an overlay does not change the compatible string.
>
>
>
> With this code in arch/arm64/boot/dts/ti/Makefile:
>
> k3-am642-tqma64xxl-mbax4xxl-sdcard-dtbs := \
> k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
> k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs := \
> k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
>
>
>
>
> $ fdtdump arch/arm64/boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb
> 2>/dev/null| head -n15 | tail -n2
> model = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
> compatible = "tq,am642-tqma6442l-mbax4xxl", "tq,am642-tqma6442l",
> "ti,am642";
>
>
> $ fdtdump arch/arm64/boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl-wlan.dtb
> 2>/dev/null| head -n15 | tail -n2
> model = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
> compatible = "tq,am642-tqma6442l-mbax4xxl", "tq,am642-tqma6442l",
> "ti,am642";
>
>
>
>
>
> These two go into image.fit, but one of them is completely dead
> since there is no way to distinguish them.
>
>
> $ fdtdump arch/arm64/boot/image.fit
>
> ...
>
> conf-10 {
> compatible = "tq,am642-tqma6442l-mbax4xxl",
> "tq,am642-tqma6442l", "ti,am642";
> description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
> fdt = "fdt-10";
> kernel = "kernel";
> };
>
> ...
>
> conf-25 {
> compatible = "tq,am642-tqma6442l-mbax4xxl",
> "tq,am642-tqma6442l", "ti,am642";
> description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
> fdt = "fdt-25";
> kernel = "kernel";
> };
>
>
>
>
>
> I agree with Chen-Yu.
>
> FIT should not include full DTBs.
>
> Bootloaders should assemble the final DTB
> from base and overlays on-the-fly.
>
>
> The FIT spec allows the "fdt" property to list
> multiple image nodes.
>
>
> o config-1
> |- description = "configuration description"
> |- kernel = "kernel sub-node unit name"
> |- fdt = "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", ...]
> |- loadables = "loadables sub-node unit-name"
> |- script = "
> |- compatible = "vendor

This is a question for U-Boot (and barebox).

images {
base {
...
};

addon1 {
...
};

addon2 {
...
};
};

configurations {
...
fdt = "base", "addon1", "addon2";
};

Is U-Boot's "bootm" command able to dynamically construct
the full DTB from "base" + "addon1" + "addon2"
and pass to the kernel?

When I used overlay from U-Boot command line last time,
I typed complicated commands, following this manual:
https://docs.u-boot.org/en/latest/usage/fdt_overlays.html

One more question to confirm if I can use this
for my practical use-cases.

Is U-Boot able to handle FIT (includes kernel + DTs)
and a separate initrd?

# bootm <fit-address>:<conf-name> <ramdisk-address>

Presumably, it would be difficult to inject initramdisk
into image.fit later, so I am hoping bootm would work like that,
but I did not delve into U-Boot code.

If it works, is it possible to verify the integrity of initrd?
The kernel and DTs inside FIT will be verified, but not sure
if it is possible for ramdisk.

--
Best Regards
Masahiro Yamada

2023-12-14 07:58:13

by Geert Uytterhoeven

[permalink] [raw]

Subject: Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

Hi Yamada-san,

On Thu, Dec 14, 2023 at 7:12 AM Masahiro Yamada <[email protected]> wrote:
> On Thu, Dec 14, 2023 at 1:03 PM Chen-Yu Tsai <[email protected]> wrote:
> > On Sun, Dec 10, 2023 at 1:31 AM Geert Uytterhoeven <[email protected]> wrote:
> > > On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart
> > > <[email protected]> wrote:
> > > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> > > > > <[email protected]> wrote:
> > > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > > > > containing the built kernel and associated devicetree files.
> > > > > > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > > > > > performance.
> > > > > > > > >
> > > > > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > > > > >
> > > > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > > > > devicetree, matching the compatible string of the running board with
> > > > > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > > > > filenames or other workarounds.
> > > > > > > > >
> > > > > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > > >
> > > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > > >
> > > > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > > > > > requires compression utilities for the algorithm being used. Supported
> > > > > > > > > compression options are the same as the Image.xxx files. For now there
> > > > > > > > > is no way to change the compression other than by editing the rule for
> > > > > > > > > $(obj)/image.fit
> > > > > > > > >
> > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > > > > > this here, since it must be built separately from the Linux build.
> > > > > > > >
> > > > > > > > FIT images are very useful, so I think this is a very welcome addition
> > > > > > > > to the kernel build system. It can get tricky though: given the
> > > > > > > > versatile nature of FIT images, there can't be any
> > > > > > > > one-size-fits-them-all solution to build them, and striking the right
> > > > > > > > balance between what makes sense for the kernel and the features that
> > > > > > > > users may request will probably lead to bikeshedding. As we all love
> > > > > > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > > > > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > > > > > > to delay merging this series.
> > > > > > > >
> > > > > > > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > > > > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > > > > > extending the supported command line arguments. It would perhaps be more
> > > > > > > > difficult to integrate in the kernel build system though. This leads me
> > > > > > > > to a second question: would you consider merging extensions to this
> > > > > > > > script if they are not used by the kernel build system, but meant for
> > > > > > > > users who manually invoke the script ? More generally, is the script
> > > > > > >
> > > > > > > We'd also be interested in some customization, though in a different way.
> > > > > > > We imagine having a rule file that says X compatible string should map
> > > > > > > to A base DTB, plus B and C DTBO for the configuration section. The base
> > > > > > > DTB would carry all common elements of some device, while the DTBOs
> > > > > > > carry all the possible second source components, like different display
> > > > > > > panels or MIPI cameras for instance. This could drastically reduce the
> > > > > > > size of FIT images in ChromeOS by deduplicating all the common stuff.
> > > > > >
> > > > > > Do you envision the "mapping" compatible string mapping to a config
> > > > > > section in the FIT image, that would bundle the base DTB and the DTBOs ?
> > > > >
> > > > > That's exactly the idea. The mapping compatible string could be untied
> > > > > from the base board's compatible string if needed (which we probably do).
> > > > >
> > > > > So something like:
> > > > >
> > > > > config {
> > > > > config-1 {
> > > > > compatible = "google,krane-sku0";
> > > > > fdt = "krane-baseboard", "krane-sku0-overlay";
> > > > > };
> > > > > };
> > > > >
> > > > > With "krane-sku0-overlay" being an overlay that holds the differences
> > > > > between the SKUs, in this case the display panel and MIPI camera (not
> > > > > upstreamed) that applies to SKU0 in particular.
> > > >
> > > > The kernel DT makefiles already contain information on what overlays to
> > > > apply to what base boards, in order to test the overlays and produce
> > > > "full" DTBs. Maybe that information could be leveraged to create the
> > > > configurations in the FIT image ?
> > >
> > > Although the "full" DTBs created may only be a subset of all possible
> > > combinations (I believe Rob just started with creating one "full" DTB
> > > for each overlay, cfr. the additions I made in commit a09c3e105a208580
> > > ("arm64: dts: renesas: Apply overlays to base dtbs")), that could
> > > definitely be a start.
> > >
> > > Now, since the kernel build system already creates "full" DTBs, does
> > > that mean that all of the base DTBs, overlays, and "full" DTBs will
> > > end up in the FIT image?
> >
> > I suppose we could add an option to the packing tool to be able to _not_
> > add the "full" DTBs if they can also be assembled with a base DTB and
> > overlays. Think of it as a firmware compatibility option: if the firmware
> > supports overlays, then you almost always want the deconstructed parts,
> > not the fully assembled ones. Vice versa.
> >
> > If we don't we could end up with two configurations that have the same
> > compatible string?
>
> Right.
>
> We would end up with such situations because applying
> an overlay does not change the compatible string.

That is correct. Which is one of the reasons for not using overlays
for this, cfr. the details in my reply in the other thread
"Re: Proposal: FIT support for extension boards / overlays"
https://lore.kernel.org/all/CAMuHMdXQdMeXUOAAw5nDO4+q5_HFvUc86Wi8ykMwjUwPex6wvQ@mail.gmail.com/

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

2023-12-14 12:48:54

[permalink] [raw]

Subject: Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

Hi,

On Wed, 31 Jan 2024 at 15:03, Rob Herring <[email protected]> wrote:
>
> On Tue, Jan 30, 2024 at 3:16 AM Masahiro Yamada <masahiroy@kernelorg> wrote:
> >
> > On Fri, Jan 26, 2024 at 1:04 AM Simon Glass <[email protected]> wrote:
> > >
> > > Hi,
> > >
> > > On Wed, 17 Jan 2024 at 06:14, Simon Glass <[email protected]> wrote:
> > > >
> > > > Hi Masahiro, Tom,
> > > >
> > > > On Tue, 9 Jan 2024 at 07:33, Tom Rini <[email protected]> wrote:
> > > > >
> > > > > On Tue, Jan 09, 2024 at 11:01:42PM +0900, Masahiro Yamada wrote:
> > > > > > Hi Simon,
> > > > > >
> > > > > >
> > > > > > On Wed, Jan 3, 2024 at 8:47 AM Simon Glass <[email protected]> wrote:
> > > > > > >
> > > > > > > Hi Masahiro,
> > > > > > >
> > > > > > > On Wed, Dec 13, 2023 at 5:14 AM Will Deacon <[email protected]> wrote:
> > > > > > > >
> > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > > > > containing the built kernel and associated devicetree files.
> > > > > > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > > > > > performance.
> > > > > > > > >
> > > > > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > > > > >
> > > > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > > > > devicetree, matching the compatible string of the running board with
> > > > > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > > > > filenames or other workarounds.
> > > > > > > > >
> > > > > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > > >
> > > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > > >
> > > > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > > > > > requires compression utilities for the algorithm being used. Supported
> > > > > > > > > compression options are the same as the Image.xxx files. For now there
> > > > > > > > > is no way to change the compression other than by editing the rule for
> > > > > > > > > $(obj)/image.fit
> > > > > > > > >
> > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > > > > > this here, since it must be built separately from the Linux build.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Simon Glass <[email protected]>
> > > > > > > > > ---
> > > > > > > > >
> > > > > > > > > Changes in v9:
> > > > > > > > > - Move the compression control into Makefile.lib
> > > > > > > > >
> > > > > > > > > Changes in v8:
> > > > > > > > > - Drop compatible string in FDT node
> > > > > > > > > - Correct sorting of MAINTAINERS to before ARM64 PORT
> > > > > > > > > - Turn compress part of the make_fit.py comment in to a sentence
> > > > > > > > > - Add two blank lines before parse_args() and setup_fit()
> > > > > > > > > - Use 'image.fit: dtbs' instead of BUILD_DTBS var
> > > > > > > > > - Use '$(<D)/dts' instead of '$(dir $<)dts'
> > > > > > > > > - Add 'mkimage' details Documentation/process/changes.rst
> > > > > > > > > - Allow changing the compression used
> > > > > > > > > - Tweak cover letter since there is only one clean-up patch
> > > > > > > > >
> > > > > > > > > Changes in v7:
> > > > > > > > > - Add Image as a dependency of image.fit
> > > > > > > > > - Drop kbuild tag
> > > > > > > > > - Add dependency on dtbs
> > > > > > > > > - Drop unnecessary path separator for dtbs
> > > > > > > > > - Rebase to -next
> > > > > > > > >
> > > > > > > > > Changes in v5:
> > > > > > > > > - Drop patch previously applied
> > > > > > > > > - Correct compression rule which was broken in v4
> > > > > > > > >
> > > > > > > > > Changes in v4:
> > > > > > > > > - Use single quotes for UIMAGE_NAME
> > > > > > > > >
> > > > > > > > > Changes in v3:
> > > > > > > > > - Drop temporary file image.itk
> > > > > > > > > - Drop patch 'Use double quotes for image name'
> > > > > > > > > - Drop double quotes in use of UIMAGE_NAME
> > > > > > > > > - Drop unnecessary CONFIG_EFI_ZBOOT condition for help
> > > > > > > > > - Avoid hard-coding "arm64" for the DT architecture
> > > > > > > > >
> > > > > > > > > Changes in v2:
> > > > > > > > > - Drop patch previously applied
> > > > > > > > > - Add .gitignore file
> > > > > > > > > - Move fit rule to Makefile.lib using an intermediate file
> > > > > > > > > - Drop dependency on CONFIG_EFI_ZBOOT
> > > > > > > > > - Pick up .dtb files separately from the kernel
> > > > > > > > > - Correct pylint too-many-args warning for write_kernel()
> > > > > > > > > - Include the kernel image in the file count
> > > > > > > > > - Add a pointer to the FIT spec and mention of its wide industry usage
> > > > > > > > > - Mention the kernel version in the FIT description
> > > > > > > > >
> > > > > > > > > Documentation/process/changes.rst | 9 +
> > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > arch/arm64/Makefile | 7 +-
> > > > > > > > > arch/arm64/boot/.gitignore | 1 +
> > > > > > > > > arch/arm64/boot/Makefile | 6 +-
> > > > > > > > > scripts/Makefile.lib | 16 ++
> > > > > > > > > scripts/make_fit.py | 291 ++++++++++++++++++++++++++++++
> > > > > > > > > 7 files changed, 334 insertions(+), 3 deletions(-)
> > > > > > > > > create mode 100755 scripts/make_fit.py
> > > > > > > >
> > > > > > > > I'll need Masahiro's Ack on the scripts/ changes before I can take this
> > > > > > > > one.
> > > > > > >
> > > > > > > Any thoughts on this request, please?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Simon
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > As I mentioned before, I am concerned with having
> > > > > > the same "compatible" entries, with different contents,
> > > > > > as you use the "compatible" string as an ID to selecting
> > > > > > the target config node, right?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > $ fdtdump arch/arm64/boot/image.fit
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > conf-10 {
> > > > > > compatible = "tq,am642-tqma6442l-mbax4xxl",
> > > > > > "tq,am642-tqma6442l", "ti,am642";
> > > > > > description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
> > > > > > fdt = "fdt-10";
> > > > > > kernel = "kernel";
> > > > > > };
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > conf-25 {
> > > > > > compatible = "tq,am642-tqma6442l-mbax4xxl",
> > > > > > "tq,am642-tqma6442l", "ti,am642";
> > > > > > description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
> > > > > > fdt = "fdt-25";
> > > > > > kernel = "kernel";
> > > > > > };
> > > > >
> > > > > I had asked Rob a while ago about if having the same compatible for two
> > > > > functionally different machines is a feature, or a bug, and I don't
> > > > > think either of us fully agreed either way. I'd be leaning towards
> > > > > saying the above example is a bug in the dts files, it's just not been a
> > > > > bug people have worried about before due to (sadly) how little the
> > > > > top-level compatible has been used.
>
> I much prefer being able to use compatibles over filenames.

So do I.

There is no check that each dts has a unique compatible string (e.g.
in the first position). Perhaps we should add that and have vendors
fix up their strings?

[..]

>
> Rob

Regards,
Simon

2024-02-02 16:09:50

by Simon Glass

[permalink] [raw]

Subject: Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

Hi Masahiro,

On Tue, 30 Jan 2024 at 02:16, Masahiro Yamada <[email protected]> wrote:
>
> On Fri, Jan 26, 2024 at 1:04 AM Simon Glass <[email protected]> wrote:
> >
> > Hi,
> >
> > On Wed, 17 Jan 2024 at 06:14, Simon Glass <[email protected]> wrote:
> > >
> > > Hi Masahiro, Tom,
> > >
> > > On Tue, 9 Jan 2024 at 07:33, Tom Rini <[email protected]> wrote:
> > > >
> > > > On Tue, Jan 09, 2024 at 11:01:42PM +0900, Masahiro Yamada wrote:
> > > > > Hi Simon,
> > > > >
> > > > >
> > > > > On Wed, Jan 3, 2024 at 8:47 AM Simon Glass <[email protected]> wrote:
> > > > > >
> > > > > > Hi Masahiro,
> > > > > >
> > > > > > On Wed, Dec 13, 2023 at 5:14 AM Will Deacon <[email protected]> wrote:
> > > > > > >
> > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > > > containing the built kernel and associated devicetree files.
> > > > > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > > > > performance.
> > > > > > > >
> > > > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > > > >
> > > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > > > devicetree, matching the compatible string of the running board with
> > > > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > > > filenames or other workarounds.
> > > > > > > >
> > > > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > >
> > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > >
> > > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > > > > requires compression utilities for the algorithm being used Supported
> > > > > > > > compression options are the same as the Image.xxx files. For now there
> > > > > > > > is no way to change the compression other than by editing the rule for
> > > > > > > > $(obj)/image.fit
> > > > > > > >
> > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > > > > this here, since it must be built separately from the Linux build.
> > > > > > > >
> > > > > > > > Signed-off-by: Simon Glass <[email protected]>
> > > > > > > > ---
> > > > > > > >
> > > > > > > > Changes in v9:
> > > > > > > > - Move the compression control into Makefile.lib
> > > > > > > >
> > > > > > > > Changes in v8:
> > > > > > > > - Drop compatible string in FDT node
> > > > > > > > - Correct sorting of MAINTAINERS to before ARM64 PORT
> > > > > > > > - Turn compress part of the make_fit.py comment in to a sentence
> > > > > > > > - Add two blank lines before parse_args() and setup_fit()
> > > > > > > > - Use 'image.fit: dtbs' instead of BUILD_DTBS var
> > > > > > > > - Use '$(<D)/dts' instead of '$(dir $<)dts'
> > > > > > > > - Add 'mkimage' details Documentation/process/changes.rst
> > > > > > > > - Allow changing the compression used
> > > > > > > > - Tweak cover letter since there is only one clean-up patch
> > > > > > > >
> > > > > > > > Changes in v7:
> > > > > > > > - Add Image as a dependency of image.fit
> > > > > > > > - Drop kbuild tag
> > > > > > > > - Add dependency on dtbs
> > > > > > > > - Drop unnecessary path separator for dtbs
> > > > > > > > - Rebase to -next
> > > > > > > >
> > > > > > > > Changes in v5:
> > > > > > > > - Drop patch previously applied
> > > > > > > > - Correct compression rule which was broken in v4
> > > > > > > >
> > > > > > > > Changes in v4:
> > > > > > > > - Use single quotes for UIMAGE_NAME
> > > > > > > >
> > > > > > > > Changes in v3:
> > > > > > > > - Drop temporary file image.itk
> > > > > > > > - Drop patch 'Use double quotes for image name'
> > > > > > > > - Drop double quotes in use of UIMAGE_NAME
> > > > > > > > - Drop unnecessary CONFIG_EFI_ZBOOT condition for help
> > > > > > > > - Avoid hard-coding "arm64" for the DT architecture
> > > > > > > >
> > > > > > > > Changes in v2:
> > > > > > > > - Drop patch previously applied
> > > > > > > > - Add .gitignore file
> > > > > > > > - Move fit rule to Makefile.lib using an intermediate file
> > > > > > > > - Drop dependency on CONFIG_EFI_ZBOOT
> > > > > > > > - Pick up .dtb files separately from the kernel
> > > > > > > > - Correct pylint too-many-args warning for write_kernel()
> > > > > > > > - Include the kernel image in the file count
> > > > > > > > - Add a pointer to the FIT spec and mention of its wide industry usage
> > > > > > > > - Mention the kernel version in the FIT description
> > > > > > > >
> > > > > > > > Documentation/process/changes.rst | 9 +
> > > > > > > > MAINTAINERS | 7 +
> > > > > > > > arch/arm64/Makefile | 7 +-
> > > > > > > > arch/arm64/boot/.gitignore | 1 +
> > > > > > > > arch/arm64/boot/Makefile | 6 +-
> > > > > > > > scripts/Makefile.lib | 16 ++
> > > > > > > > scripts/make_fit.py | 291 ++++++++++++++++++++++++++++++
> > > > > > > > 7 files changed, 334 insertions(+), 3 deletions(-)
> > > > > > > > create mode 100755 scripts/make_fit.py
> > > > > > >
> > > > > > > I'll need Masahiro's Ack on the scripts/ changes before I can take this
> > > > > > > one.
> > > > > >
> > > > > > Any thoughts on this request, please?
> > > > > >
> > > > > > Regards,
> > > > > > Simon
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > As I mentioned before, I am concerned with having
> > > > > the same "compatible" entries, with different contents,
> > > > > as you use the "compatible" string as an ID to selecting
> > > > > the target config node, right?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > $ fdtdump arch/arm64/boot/image.fit
> > > > >
> > > > > ...
> > > > >
> > > > > conf-10 {
> > > > > compatible = "tq,am642-tqma6442l-mbax4xxl",
> > > > > "tq,am642-tqma6442l", "ti,am642";
> > > > > description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
> > > > > fdt = "fdt-10";
> > > > > kernel = "kernel";
> > > > > };
> > > > >
> > > > > ...
> > > > >
> > > > > conf-25 {
> > > > > compatible = "tq,am642-tqma6442l-mbax4xxl",
> > > > > "tq,am642-tqma6442l", "ti,am642";
> > > > > description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
> > > > > fdt = "fdt-25";
> > > > > kernel = "kernel";
> > > > > };
> > > >
> > > > I had asked Rob a while ago about if having the same compatible for two
> > > > functionally different machines is a feature, or a bug, and I don't
> > > > think either of us fully agreed either way. I'd be leaning towards
> > > > saying the above example is a bug in the dts files, it's just not been a
> > > > bug people have worried about before due to (sadly) how little the
> > > > top-level compatible has been used.
> > >
> > > Yes I believe this is a bug in the files.
> > >
> > > What should the script do in this case? Print a warning, perhaps?
> >
> > Is there anything I should do here? Would a warning be helpful, or
> > just confusing?
>
>
>
> I do not think it is useful.
> You would almost always get a warning, and there is no way to fix it.
>
>
>
> With arm64 defconfig, image.fit will include a thousand DTBs.
>
>
> The config node of my board was listed 214th.
> (I found it by fdtdump)
>
>
> Then, I learned
>
> > bootm ${loadaddr}#conf-214
>
> is the correct command to boot my board.
>
>
> Of course, the "214" will be different in the future.
>
> The node names, conf-*, are useless.
>
>
>
> Only the useful way is to enable CONFIG_FIT_BEST_MATCH in U-Boot,
> but this relies on the uniqueness of a compatible string,
> which is not true.

See my other email, but I think this is a problem we should fix.

>
> (I do not know how to do it in barebox)
>
>
>
>
>
> I think using the file name as a config node
> mitigates the issue because a file name is
> considered unique.
>
>
> For example, with composite DTBs:
>
> imx8mm-venice-gw72xx-0x-imx219-dtbs := imx8mm-venice-gw72xx-0x.dtb
> imx8mm-venice-gw72xx-0x-imx219.dtbo
> imx8mm-venice-gw72xx-0x-rpidsi-dtbs := imx8mm-venice-gw72xx-0x.dtb
> imx8mm-venice-gw72xx-0x-rpidsi.dtbo
>
>
>
>
> configurations {
> imx8mm-venice-gw72xx-0x-imx219 {
> ...
> };
>
> imx8mm-venice-gw72xx-0x-rpidsi {
> ...
> }
> };
>
>
>
> Then, we can distinguish them by node, even if they have
> the same compatible string.
> At least we can do
>
> > bootm ${loadaddr}#imx8mm-venice-gw72xx-0x-imx219
>
>

Sure, but the goal with FIT is to be able to boot with the correct dtb
automatically. What you have above would require some sort of boot
script, or some other information about the configuration-node name.

>
>
> For the issue including stale DTBs, you can use my patch:
> [PATCH 1/4] kbuild: create a list of all built DTB files
> (https://lore.kernel.org/linux-kbuild/CAK7LNASOxi-gzve+_d-sCW9z_eEJ5TMMnzPEvN2Nj2AwgVjF9g@mail.gmail.com/T/#ma3595627a96a04554a78cbbd22056831e13db260)
>
>
> You can change scripts/make_fit.py to take
> the DTB files instead of the directory to search.
>
> Optionally, you can support '@' syntax to
> take command arguments from a file.
>
>
> scripts/make_fit.py ... @arch/$(SRCARCH)/boot/dts/dtbs-list

Thank you for doing that. I will take a look and send v10.

>
>
>
>
>
>
> For the separate base and overlays support,
> you can use my patch as a base:
> [PATCH 3/4] kbuild: create a list of base and overlays for each DTB
> (https://lore.kernel.org/linux-kbuild/CAK7LNASOxi-gzve+_d-sCW9z_eEJ5TMMnzPEvN2Nj2AwgVjF9g@mail.gmail.com/T/#m32c5bdde9098901b7c7776b932827493a05c82d5)
>
>
>
>
>
> Lastly, you do not need to require mkimage for
> args.external.
> You can simply concatenate files.

Yes, that's true. Do you think there is a problem with using mkimage?

Regards,
Simon