[EXT] [PATCH] ARM: imx: romapi: Repair FlexSPI NOR boot offset
Tim Harvey
tharvey at gateworks.com
Thu Mar 31 17:09:51 CEST 2022
On Mon, Mar 28, 2022 at 7:55 AM Marek Vasut <marex at denx.de> wrote:
>
> On 3/28/22 08:54, Ye Li wrote:
> > Hi Marek,
>
> Hi,
>
> [...]
>
> >>> 2. Update the u-boot.itb offset in imx8mp-u-boot.dtsi, set the
> >>> offset
> >>> to 0x5f000. The previous offset 0x58000 is for SD, calculated by
> >>> 0x60000 - 0x8000 (32KB image offset).
> >>>
> >>> uboot: blob-ext at 2 {
> >>> filename = "u-boot.itb";
> >>> offset = <0x5f000>;
> >>> };
> >> But that breaks booting from SD card for me ?
> >
> > Do you want to use one flash.bin for both SD and flexspi?
>
> Yes, the board I use can boot from SD/eMMC/FlexSPI. I don't want to
> build multiple confusing "flash.bin" files, one for each boot media.
>
> > When first introduced 8m support by imx8mimage.c, we expected the u-
> > boot.itb at same device offset (0x60000) on SD/emmc and flexspi. The
> > imx8mimage will calculate the offset inside the flash.bin automatically
> > according to different IVT offset. The ROMAPI driver also works
> > correspondingly.
> > After using binman, the u-boot.itb offset inside the flash.bin has to
> > be manually set in this DTS node. To follow the original design, this
> > offset should be different. That's why I asked to update this dts node
> > for flexspi.
>
> This does imply that there are currently no users that boot from flexspi
> in upstream U-Boot, because such users would have to manually modify
> both arch/arm/dts/imx8m?-u-boot.dtsi and board/*/imximage.cfg to
> generate suitable flash.bin which can be started from FlexSPI.
>
> Also, git grep confirms that there are no users:
>
> u-boot$ git grep BOOT_FROM.*fspi
> doc/imx/mkimage/imx8image.txt:BOOT_FROM
> [sd|emmc_fastboot|fspi|nand_4k|nand_8k|nand_16k] [sector_size]
>
> > If you change the ROM API driver, that will break our design. You can
> > try to overwrite spl_romapi_get_uboot_base for your board only.
>
> Since there are no users which boot from flexspi upstream, this design
> can still be fixed such that it does not require different flash.bin for
> different boot media, but rather one flash.bin works on all boot media.
> I think that is much better.
>
Marek,
I'm also a fan of single U-Boot binaries supporting multiple boards
and configurations.
How are you handling env for the various boot devices? I haven't
looked in a while... can multiple env support co-exist now between
MMC/SPI and be selected at runtime?
Best Regards,
Tim
More information about the U-Boot
mailing list