On 3/31/22 18:03, Tim Harvey wrote:
On Thu, Mar 31, 2022 at 8:26 AM Marek Vasut <ma...@denx.de> wrote:
On 3/31/22 17:09, Tim Harvey wrote:
On Mon, Mar 28, 2022 at 7:55 AM Marek Vasut <ma...@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@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?
Do '$ git grep env_get_location' , you will find board-level examples
where this function is implemented and it returns ENVL_* based on
various hardware-specific conditions.
I _think_ there is even imx arch specific implementation for this
env_get_location() which automatically picks SD/eMMC/FlexSPI for you
right now.
Marek,
I guess where I keep getting hung up is how to configure the ENV for
multiple env drivers as there is only one CONFIG_ENV_OFFSET Kconfig
which means for all devices your going to have the same offset/redund
configuration which is likely not appropriate for mmc/nand/spi for
example. I don't see any way currently to configure those separately.
Unless I'm missing something obvious I suppose get_env_location()
could be augmented to be able to return board-specific env location
config as well.
e.g. env/mmc.c has the following:
78 } dt_prop = {
79 .offset_redund = "u-boot,mmc-env-offset-redundant",
80 .partition = "u-boot,mmc-env-partition",
81 .offset = "u-boot,mmc-env-offset",
82 };
So use that to specify per-env-driver offset. Indeed, the
CONFIG_ENV*OFFSET is shared by all env driver.
