| Message ID | 20241109200610.1615430-2-aford173@gmail.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Fabio Estevam |
| Headers | show |
| Series | Fix FSPI booting on i.MX8M Mini and Nano | expand |
On 11/9/24 9:06 PM, Adam Ford wrote: > When FSPI_CONF_HEADER is set, the binary needs to be built such > that there is a configuration file located at 0x400 and the start > of the file that would normally be flash.bin starts at 0x1000. > This used to be done properly until the device tree was converted to > nxp_imx8mimage. > > Building these with the offsets built into the binman device tree > changes impacts how the actual image is built and the locations > of the various blobs aren't fetched properly and booting fails. > > Fix this by building a standard image as if it were to boot from > eMMC or SD, then use that image as the input for a second image This seems like a workaround for some broken offset calculation in binman ?
On Sat, Nov 9, 2024 at 7:34 PM Marek Vasut <marex@denx.de> wrote: > > On 11/9/24 9:06 PM, Adam Ford wrote: > > When FSPI_CONF_HEADER is set, the binary needs to be built such > > that there is a configuration file located at 0x400 and the start > > of the file that would normally be flash.bin starts at 0x1000. > > This used to be done properly until the device tree was converted to > > nxp_imx8mimage. > > > > Building these with the offsets built into the binman device tree > > changes impacts how the actual image is built and the locations > > of the various blobs aren't fetched properly and booting fails. > > > > Fix this by building a standard image as if it were to boot from > > eMMC or SD, then use that image as the input for a second image > > This seems like a workaround for some broken offset calculation in binman ? This used to work until it was migrated to nxp_imx8mimage. The blobs appear to be at the proper offsets, but the contents of what's stored at those offsets are not the same. If you're going to claim there is a bug somewhere, I would argue that it's somewhere i nxp_imx8mimage. However, if you look at this series, the added benefit is the ability for Nano to be able to build both a SD/eMMC image and FSPI images with one config which allows for the elimination of extra defconfig files. I am guessing Plus would have a similar benefit since they have similar bootloaders. adam
On 11/10/24 2:15 PM, Adam Ford wrote: > On Sat, Nov 9, 2024 at 7:34 PM Marek Vasut <marex@denx.de> wrote: >> >> On 11/9/24 9:06 PM, Adam Ford wrote: >>> When FSPI_CONF_HEADER is set, the binary needs to be built such >>> that there is a configuration file located at 0x400 and the start >>> of the file that would normally be flash.bin starts at 0x1000. >>> This used to be done properly until the device tree was converted to >>> nxp_imx8mimage. >>> >>> Building these with the offsets built into the binman device tree >>> changes impacts how the actual image is built and the locations >>> of the various blobs aren't fetched properly and booting fails. >>> >>> Fix this by building a standard image as if it were to boot from >>> eMMC or SD, then use that image as the input for a second image >> >> This seems like a workaround for some broken offset calculation in binman ? > > This used to work until it was migrated to nxp_imx8mimage. > The blobs appear to be at the proper offsets, but the contents of > what's stored at those offsets are not the same. I know, this is what Lukasz reported too. > If you're going to claim there is a bug somewhere, I would argue that > it's somewhere i nxp_imx8mimage I agree with that claim. Well, by extension, the problem might also be in binman itself. >. However, if you look at this series, > the added benefit is the ability for Nano to be able to build both a > SD/eMMC image and FSPI images with one config which allows for the > elimination of extra defconfig files. I am guessing Plus would have a > similar benefit since they have similar bootloaders. This I do not agree with. If the intent is to generate two images, then there should be two full binman descriptors, one for each image (one for flash-plain.bin and one for flash-fspi.bin or some such naming). Can you try and fix the FSPI generation first, so an FSPI compatible flash.bin can be generated using binman only, without the dependency on processing non-FSPI compatible flash.bin ? I think the intention of binman was to replace all that ad-hoc pre/postprocessing of blobs.
On Sun, Nov 10, 2024 at 10:42 AM Marek Vasut <marex@denx.de> wrote: > > On 11/10/24 2:15 PM, Adam Ford wrote: > > On Sat, Nov 9, 2024 at 7:34 PM Marek Vasut <marex@denx.de> wrote: > >> > >> On 11/9/24 9:06 PM, Adam Ford wrote: > >>> When FSPI_CONF_HEADER is set, the binary needs to be built such > >>> that there is a configuration file located at 0x400 and the start > >>> of the file that would normally be flash.bin starts at 0x1000. > >>> This used to be done properly until the device tree was converted to > >>> nxp_imx8mimage. > >>> > >>> Building these with the offsets built into the binman device tree > >>> changes impacts how the actual image is built and the locations > >>> of the various blobs aren't fetched properly and booting fails. > >>> > >>> Fix this by building a standard image as if it were to boot from > >>> eMMC or SD, then use that image as the input for a second image > >> > >> This seems like a workaround for some broken offset calculation in binman ? > > > > This used to work until it was migrated to nxp_imx8mimage. > > The blobs appear to be at the proper offsets, but the contents of > > what's stored at those offsets are not the same. > > I know, this is what Lukasz reported too. > > > If you're going to claim there is a bug somewhere, I would argue that > > it's somewhere i nxp_imx8mimage > > I agree with that claim. Well, by extension, the problem might also be > in binman itself. > > >. However, if you look at this series, > > the added benefit is the ability for Nano to be able to build both a > > SD/eMMC image and FSPI images with one config which allows for the > > elimination of extra defconfig files. I am guessing Plus would have a > > similar benefit since they have similar bootloaders. > This I do not agree with. If the intent is to generate two images, then > there should be two full binman descriptors, one for each image (one for > flash-plain.bin and one for flash-fspi.bin or some such naming). > > Can you try and fix the FSPI generation first, so an FSPI compatible I am not a python programmer, and I couldn't determine what was going on. > flash.bin can be generated using binman only, without the dependency on > processing non-FSPI compatible flash.bin ? I think the intention of > binman was to replace all that ad-hoc pre/postprocessing of blobs.
On 11/10/24 6:21 PM, Adam Ford wrote: > On Sun, Nov 10, 2024 at 10:42 AM Marek Vasut <marex@denx.de> wrote: >> >> On 11/10/24 2:15 PM, Adam Ford wrote: >>> On Sat, Nov 9, 2024 at 7:34 PM Marek Vasut <marex@denx.de> wrote: >>>> >>>> On 11/9/24 9:06 PM, Adam Ford wrote: >>>>> When FSPI_CONF_HEADER is set, the binary needs to be built such >>>>> that there is a configuration file located at 0x400 and the start >>>>> of the file that would normally be flash.bin starts at 0x1000. >>>>> This used to be done properly until the device tree was converted to >>>>> nxp_imx8mimage. >>>>> >>>>> Building these with the offsets built into the binman device tree >>>>> changes impacts how the actual image is built and the locations >>>>> of the various blobs aren't fetched properly and booting fails. >>>>> >>>>> Fix this by building a standard image as if it were to boot from >>>>> eMMC or SD, then use that image as the input for a second image >>>> >>>> This seems like a workaround for some broken offset calculation in binman ? >>> >>> This used to work until it was migrated to nxp_imx8mimage. >>> The blobs appear to be at the proper offsets, but the contents of >>> what's stored at those offsets are not the same. >> >> I know, this is what Lukasz reported too. >> >>> If you're going to claim there is a bug somewhere, I would argue that >>> it's somewhere i nxp_imx8mimage >> >> I agree with that claim. Well, by extension, the problem might also be >> in binman itself. >> >>> . However, if you look at this series, >>> the added benefit is the ability for Nano to be able to build both a >>> SD/eMMC image and FSPI images with one config which allows for the >>> elimination of extra defconfig files. I am guessing Plus would have a >>> similar benefit since they have similar bootloaders. >> This I do not agree with. If the intent is to generate two images, then >> there should be two full binman descriptors, one for each image (one for >> flash-plain.bin and one for flash-fspi.bin or some such naming). >> >> Can you try and fix the FSPI generation first, so an FSPI compatible > > I am not a python programmer, and I couldn't determine what was going on. I am hoping Simon could offer some input here ... Can you try the attached diff on MX8MM (use "git show -w" to view the diff better) ? It will generate two files, flash.bin and flash-fspi.bin , the later should have the fspi header and maybe even correct offsets? Applies on top of 56accc56b9aa ("bios_emulator: fix first argument of pci_{read,write}_config_* function calls") . I noticed that there is some dependency issue where fspi_header.bin may not be generated yet when binman is triggered -- that needs to be fixed. You can detect the failure by running 'hexdump -C flash-fspi.bin | head' , if there is no FCFB header then this failure occurred. The easiest way to work around this is to run 'rm flash.bin ; make flash.bin'. The real fix is likely a matter of some Makefile tweak.
On Sun, Nov 10, 2024 at 6:49 PM Marek Vasut <marex@denx.de> wrote: > > On 11/10/24 6:21 PM, Adam Ford wrote: > > On Sun, Nov 10, 2024 at 10:42 AM Marek Vasut <marex@denx.de> wrote: > >> > >> On 11/10/24 2:15 PM, Adam Ford wrote: > >>> On Sat, Nov 9, 2024 at 7:34 PM Marek Vasut <marex@denx.de> wrote: > >>>> > >>>> On 11/9/24 9:06 PM, Adam Ford wrote: > >>>>> When FSPI_CONF_HEADER is set, the binary needs to be built such > >>>>> that there is a configuration file located at 0x400 and the start > >>>>> of the file that would normally be flash.bin starts at 0x1000. > >>>>> This used to be done properly until the device tree was converted to > >>>>> nxp_imx8mimage. > >>>>> > >>>>> Building these with the offsets built into the binman device tree > >>>>> changes impacts how the actual image is built and the locations > >>>>> of the various blobs aren't fetched properly and booting fails. > >>>>> > >>>>> Fix this by building a standard image as if it were to boot from > >>>>> eMMC or SD, then use that image as the input for a second image > >>>> > >>>> This seems like a workaround for some broken offset calculation in binman ? > >>> > >>> This used to work until it was migrated to nxp_imx8mimage. > >>> The blobs appear to be at the proper offsets, but the contents of > >>> what's stored at those offsets are not the same. > >> > >> I know, this is what Lukasz reported too. > >> > >>> If you're going to claim there is a bug somewhere, I would argue that > >>> it's somewhere i nxp_imx8mimage > >> > >> I agree with that claim. Well, by extension, the problem might also be > >> in binman itself. > >> > >>> . However, if you look at this series, > >>> the added benefit is the ability for Nano to be able to build both a > >>> SD/eMMC image and FSPI images with one config which allows for the > >>> elimination of extra defconfig files. I am guessing Plus would have a > >>> similar benefit since they have similar bootloaders. > >> This I do not agree with. If the intent is to generate two images, then > >> there should be two full binman descriptors, one for each image (one for > >> flash-plain.bin and one for flash-fspi.bin or some such naming). > >> > >> Can you try and fix the FSPI generation first, so an FSPI compatible > > > > I am not a python programmer, and I couldn't determine what was going on. > I am hoping Simon could offer some input here ... > > Can you try the attached diff on MX8MM (use "git show -w" to view the > diff better) ? It will generate two files, flash.bin and flash-fspi.bin > , the later should have the fspi header and maybe even correct offsets? I reset my branch to to U-Boot master from wedneday a7a96a37cbd8 "Merge https://source.denx.de/u-boot/custodians/u-boot-riscv") I verified the FCFB header is present. Unfortunately, when I burn the FSPI on my 8MM and attempt to boot, nothing happens. However, I changed the "nxp,boot-from" parameter to "fspi" and it booted! U-Boot SPL 2025.01-rc1-00168-ga7a96a37cbd8-dirty (Nov 10 2024 - 19:27:21 -0600) WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout) SEC0: RNG instantiated Trying to boot from NOR <snip> I looked at your patch, and noticed your FIXME. Once we get the code working, we'll likely need a way to pass the header offset, because it's different between Mini (0x0) and Nano / Plus (0x400). I'd like to suggest we #iifndef the section filename where "flash.bin" currently sits, and remove it if we are building for flexspi. This way we get what you originally requested, which is a single binary. I have attached my diff file, so you can see my proposal. I am happy to test either Mini or Nano, but I am traveling this week starting Wednesday afternoon (US Central time) until Sunday night, so I won't be able to test in that window. Let me know how/if you want to proceed. Thanks for looking into this. adam > > Applies on top of 56accc56b9aa ("bios_emulator: fix first argument of > pci_{read,write}_config_* function calls") . > > I noticed that there is some dependency issue where fspi_header.bin may > not be generated yet when binman is triggered -- that needs to be fixed. > You can detect the failure by running 'hexdump -C flash-fspi.bin | head' > , if there is no FCFB header then this failure occurred. The easiest way > to work around this is to run 'rm flash.bin ; make flash.bin'. The real > fix is likely a matter of some Makefile tweak.
On 11/11/24 2:46 AM, Adam Ford wrote: [...] >> I am hoping Simon could offer some input here ... >> >> Can you try the attached diff on MX8MM (use "git show -w" to view the >> diff better) ? It will generate two files, flash.bin and flash-fspi.bin >> , the later should have the fspi header and maybe even correct offsets? > > I reset my branch to to U-Boot master from wedneday a7a96a37cbd8 > "Merge https://source.denx.de/u-boot/custodians/u-boot-riscv") > > I verified the FCFB header is present. Unfortunately, when I burn the > FSPI on my 8MM and attempt to boot, nothing happens. > > However, I changed the "nxp,boot-from" parameter to "fspi" and it booted! Uh oh, look at tools/imx8mimage.c and search for both 'fspi' and 'CONFIG_FSPI_CONF_HEADER' . I have a feeling that building with the CONFIG_FSPI_CONF_HEADER changes mkimage -T imx8mimage behavior, which may even interfere with binman. Can you try and remove all the CONFIG_FSPI_CONF_HEADER stuff from imx8mimage.c , so it doesn't accidentally generate FSPI header, but keeps the fspi 0x1000 offset ? > U-Boot SPL 2025.01-rc1-00168-ga7a96a37cbd8-dirty (Nov 10 2024 - 19:27:21 -0600) > WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout) > SEC0: RNG instantiated > Trying to boot from NOR > <snip> > > I looked at your patch, and noticed your FIXME. Once we get the code > working, we'll likely need a way to pass the header offset, because > it's different between Mini (0x0) and Nano / Plus (0x400). Try and add offset=<0x400> into fspi_conf_block {} for MX8MN/MP . > I'd like to suggest we #iifndef the section filename where "flash.bin" > currently sits, and remove it if we are building for flexspi. This > way we get what you originally requested, which is a single binary. I was hoping we would be able to generate both SD capable and FSPI capable boot blob at the same time, maybe we can even do it with one binman description. > I have attached my diff file, so you can see my proposal. I am happy > to test either Mini or Nano, but I am traveling this week starting > Wednesday afternoon (US Central time) until Sunday night, so I won't > be able to test in that window. No worries > Let me know how/if you want to proceed. I suspect a patch to imx8mimage.c to remove the fspi stuff would be good, and then DT changes are also fine. I am not sure about the python part though. > Thanks for looking into this. You're welcome [...]
diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi index 6875c6d44f..157e6b9a26 100644 --- a/arch/arm/dts/imx8mn-u-boot.dtsi +++ b/arch/arm/dts/imx8mn-u-boot.dtsi @@ -91,185 +91,195 @@ }; &binman { - filename = "flash.bin"; - section { - pad-byte = <0x00>; + multiple-images; -#ifdef CONFIG_FSPI_CONF_HEADER - fspi_conf_block { - filename = CONFIG_FSPI_CONF_FILE; - type = "blob-ext"; - offset = <0x400>; - }; -#endif + standard_image: image1 { + filename = "flash.bin"; + section { + pad-byte = <0x00>; #ifdef CONFIG_IMX_HAB - nxp-imx8mcst@0 { - filename = "u-boot-spl-mkimage.signed.bin"; - nxp,loader-address = <CONFIG_SPL_TEXT_BASE>; - nxp,unlock; - args; /* Needed by mkimage etype superclass */ -#endif - - binman_imx_spl: nxp-imx8mimage { - filename = "u-boot-spl-mkimage.bin"; - nxp,boot-from = "sd"; - nxp,rom-version = <2>; + nxp-imx8mcst@0 { + filename = "u-boot-spl-mkimage.signed.bin"; nxp,loader-address = <CONFIG_SPL_TEXT_BASE>; + nxp,unlock; args; /* Needed by mkimage etype superclass */ +#endif - section { - filename = "u-boot-spl-ddr.bin"; - pad-byte = <0xff>; - align-size = <4>; - align = <4>; - - u-boot-spl { - align-end = <4>; - filename = "u-boot-spl.bin"; - }; + binman_imx_spl: nxp-imx8mimage { + filename = "u-boot-spl-mkimage.bin"; + nxp,boot-from = "sd"; + nxp,rom-version = <2>; + nxp,loader-address = <CONFIG_SPL_TEXT_BASE>; + args; /* Needed by mkimage etype superclass */ + + section { + filename = "u-boot-spl-ddr.bin"; + pad-byte = <0xff>; + align-size = <4>; + align = <4>; + + u-boot-spl { + align-end = <4>; + filename = "u-boot-spl.bin"; + }; - ddr-1d-imem-fw { + ddr-1d-imem-fw { #ifdef CONFIG_IMX8M_LPDDR4 - filename = "lpddr4_pmu_train_1d_imem.bin"; + filename = "lpddr4_pmu_train_1d_imem.bin"; #elif CONFIG_IMX8M_DDR4 - filename = "ddr4_imem_1d_201810.bin"; + filename = "ddr4_imem_1d_201810.bin"; #else - filename = "ddr3_imem_1d.bin"; + filename = "ddr3_imem_1d.bin"; #endif - type = "blob-ext"; - align-end = <4>; - }; + type = "blob-ext"; + align-end = <4>; + }; - ddr-1d-dmem-fw { + ddr-1d-dmem-fw { #ifdef CONFIG_IMX8M_LPDDR4 - filename = "lpddr4_pmu_train_1d_dmem.bin"; + filename = "lpddr4_pmu_train_1d_dmem.bin"; #elif CONFIG_IMX8M_DDR4 - filename = "ddr4_dmem_1d_201810.bin"; + filename = "ddr4_dmem_1d_201810.bin"; #else - filename = "ddr3_dmem_1d.bin"; + filename = "ddr3_dmem_1d.bin"; #endif - type = "blob-ext"; - align-end = <4>; - }; + type = "blob-ext"; + align-end = <4>; + }; #if defined(CONFIG_IMX8M_LPDDR4) || defined(CONFIG_IMX8M_DDR4) - ddr-2d-imem-fw { + ddr-2d-imem-fw { #ifdef CONFIG_IMX8M_LPDDR4 - filename = "lpddr4_pmu_train_2d_imem.bin"; + filename = "lpddr4_pmu_train_2d_imem.bin"; #else - filename = "ddr4_imem_2d_201810.bin"; + filename = "ddr4_imem_2d_201810.bin"; #endif - type = "blob-ext"; - align-end = <4>; - }; + type = "blob-ext"; + align-end = <4>; + }; - ddr-2d-dmem-fw { + ddr-2d-dmem-fw { #ifdef CONFIG_IMX8M_LPDDR4 - filename = "lpddr4_pmu_train_2d_dmem.bin"; + filename = "lpddr4_pmu_train_2d_dmem.bin"; #else - filename = "ddr4_dmem_2d_201810.bin"; + filename = "ddr4_dmem_2d_201810.bin"; #endif - type = "blob-ext"; - align-end = <4>; - }; + type = "blob-ext"; + align-end = <4>; + }; #endif + }; }; - }; #ifdef CONFIG_IMX_HAB - }; + }; - nxp-imx8mcst@1 { - filename = "u-boot-fit.signed.bin"; - nxp,loader-address = <CONFIG_SPL_LOAD_FIT_ADDRESS>; -#ifdef CONFIG_FSPI_CONF_HEADER - offset = <0x59000>; -#else - offset = <0x58000>; -#endif - args; /* Needed by mkimage etype superclass */ + nxp-imx8mcst@1 { + filename = "u-boot-fit.signed.bin"; + nxp,loader-address = <CONFIG_SPL_LOAD_FIT_ADDRESS>; + offset = <0x58000>; + args; /* Needed by mkimage etype superclass */ #endif - binman_imx_fit: fit { - description = "Configuration to load ATF before U-Boot"; - filename = "u-boot.itb"; + binman_imx_fit: fit { + description = "Configuration to load ATF before U-Boot"; + filename = "u-boot.itb"; #ifndef CONFIG_IMX_HAB - fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>; + fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>; #endif - fit,fdt-list = "of-list"; - #address-cells = <1>; -#ifdef CONFIG_FSPI_CONF_HEADER - offset = <0x59000>; -#else - offset = <0x58000>; -#endif - - images { - uboot { - arch = "arm64"; - compression = "none"; - description = "U-Boot (64-bit)"; - load = <CONFIG_TEXT_BASE>; - type = "standalone"; - - uboot-blob { - filename = "u-boot-nodtb.bin"; - type = "blob-ext"; + fit,fdt-list = "of-list"; + #address-cells = <1>; + offset = <0x58000>; + + images { + uboot { + arch = "arm64"; + compression = "none"; + description = "U-Boot (64-bit)"; + load = <CONFIG_TEXT_BASE>; + type = "standalone"; + + uboot-blob { + filename = "u-boot-nodtb.bin"; + type = "blob-ext"; + }; }; - }; #ifndef CONFIG_ARMV8_PSCI - atf { - arch = "arm64"; - compression = "none"; - description = "ARM Trusted Firmware"; - entry = <0x960000>; - load = <0x960000>; - type = "firmware"; - - atf-blob { - filename = "bl31.bin"; - type = "atf-bl31"; + atf { + arch = "arm64"; + compression = "none"; + description = "ARM Trusted Firmware"; + entry = <0x960000>; + load = <0x960000>; + type = "firmware"; + + atf-blob { + filename = "bl31.bin"; + type = "atf-bl31"; + }; }; - }; #endif - binman_fip: fip { - arch = "arm64"; - compression = "none"; - description = "Trusted Firmware FIP"; - load = <0x40310000>; - type = "firmware"; - }; + binman_fip: fip { + arch = "arm64"; + compression = "none"; + description = "Trusted Firmware FIP"; + load = <0x40310000>; + type = "firmware"; + }; - @fdt-SEQ { - compression = "none"; - description = "NAME"; - type = "flat_dt"; + @fdt-SEQ { + compression = "none"; + description = "NAME"; + type = "flat_dt"; - uboot-fdt-blob { - filename = "u-boot.dtb"; - type = "blob-ext"; + uboot-fdt-blob { + filename = "u-boot.dtb"; + type = "blob-ext"; + }; }; }; - }; - configurations { - default = "@config-DEFAULT-SEQ"; + configurations { + default = "@config-DEFAULT-SEQ"; - @config-SEQ { - description = "NAME"; - fdt = "fdt-SEQ"; - firmware = "uboot"; + @config-SEQ { + description = "NAME"; + fdt = "fdt-SEQ"; + firmware = "uboot"; #ifndef CONFIG_ARMV8_PSCI - loadables = "atf"; + loadables = "atf"; #endif + }; }; }; - }; #ifdef CONFIG_IMX_HAB - }; + }; #endif + }; + }; + +#ifdef CONFIG_FSPI_CONF_HEADER + flexspi_image: image2 { + filename = "flexspi.bin"; + section { + pad-byte = <0x00>; + + fspi_conf_block { + filename = CONFIG_FSPI_CONF_FILE; + type = "blob-ext"; + offset = <0x400>; + }; + + flashbin { + filename = "flash.bin"; + type = "blob-ext"; + offset = <0x1000>; + }; + }; + }; +#endif };
When FSPI_CONF_HEADER is set, the binary needs to be built such that there is a configuration file located at 0x400 and the start of the file that would normally be flash.bin starts at 0x1000. This used to be done properly until the device tree was converted to nxp_imx8mimage. Building these with the offsets built into the binman device tree changes impacts how the actual image is built and the locations of the various blobs aren't fetched properly and booting fails. Fix this by building a standard image as if it were to boot from eMMC or SD, then use that image as the input for a second image which adds this FSPI header at 0x400, and then places the standard image at offset 0x1000. This also has the benefit of being able to create both SD/eMMC image at the same time as a fspi image called flexspi.bin. Fixes: 37e50627efac ("ARM: dts: imx: Convert i.MX8M flash.bin image generation to binman") Signed-off-by: Adam Ford <aford173@gmail.com> --- arch/arm/dts/imx8mn-u-boot.dtsi | 266 +++++++++++++++++--------------- 1 file changed, 138 insertions(+), 128 deletions(-)