El Mon, Jul 25, 2022 at 12:54:04PM +0200, Quentin Schulz deia: > You'd need a new binman entry I assume for calling mkenvimage. >
> It's not a super safe assumption that CONFIG_ENV_OFFSET will be used for > declaring where the environment is stored. E.g., CONFIG_ENV_OFFSET for Puma > declares where the env is located on SPI-NOR, however for MMC devices, it is > specified with u-boot,mmc-env-offset DT property (though, if it is not > defined, it defaults to CONFIG_ENV_OFFSET, c.f. env/mmc.c). But maybe the > same comment as I did for CONFIG_SYS_SPI_U_BOOT_OFFS would be enough? e.g. > states that this should be in sync with the DT property if there's one for > the board in question. See: > https://lore.kernel.org/u-boot/20220722160655.3904213-13-foss+ub...@0leil.net/ > for what I needed to do for Puma to get u-boot-rockchip-spi.bin support. > > But that overall seems like a reasonable feature to add. > But it is interesting enough ? I mean once you could call mkenvimage you'd still need to give it some environment (variables values). And what would you give it that would be different from the default environment ? Maybe what's wanted is just to fail to read the environment the first time. And the user can save it from hush (or run mkenvimage themselves). > > Or maybe we should just disable CONFIG_ENV_IS_IN_MMC in the board ? (I > > think it conflicts with trust settings anyway). > > > > Yes, anything but ENV_IS_NOWHERE depends on !CHAIN_OF_TRUST. So I guess a > check on #ifndef CONFIG_CHAIN_OF_TRUST for that section in binman would do > the trick? > If we need to add the environment to binman we could just check ENV_IS_IN_... because those will already be false if CHAIN_OF_TRUST is false, I think. But mayeb we don't need to do that, or we just want to leave some empty space somewhere (yeah, difficult to know where if the offset can be in dt or Kconfig). > > If there's no environment where U-Boot is looking for it, it'll not fatally > fail right now. The next time you save the environment (saveenv), it'll be > written in the correct location and read during next boot. Again, this patch > series does not modify u-boot-rockchip.bin current behavior :) > You're right, so maybe we don't really need to run mkenvimage to build the image, we leave the environment empty, and let the user do their thing. We may want to make sure we don't put something else there, though. > > Now that we have Quentin's patches maybe we can remove the Makefile > > warning about CONFIG_USE_SPL_FIT_GENERATOR and move the task that > > arch/arm/mach-rockchip/make_fit_atf.py is doing to binman. > > I wasn't aware of this entry, maybe it is actually possible. That'd be nice > to have :) > I'm playing with this right now. I don't have anything that boots. First attempt complains that SPL can't allocate so much RAM to fit the internal image (not really feeling like increasing space a lot for many boards) and 2nd attempt at having an external image to make it closer to what make_fit_atf.py used to do and have less breakage, then it doesn't even complain, just stops short of running ATF. I'll play some more... > > My understanding is that there's a will to replace make_fit_atf.py output > generated by binman instead, if binman supports everything needed to do this > migration, I don't know. > Thanks for your confirmation.
