On 7/25/22 13:20, Xavier Drudis Ferran wrote:
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://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_u-2Dboot_20220722160655.3904213-2D13-2Dfoss-2Buboot-400leil.net_&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=vRiCOa3kkluAD8H-j_n6Ah5cU-awcHa_QffxMmj8DZv5-_BNT1IcyP3RMiDj_ZWl&s=ptlh1k3KoLVMT-Zk2f-cUxoHrQeWZTVCLIP83D3NVuQ&e=
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 ?
Nothing, but that's the point? So you don't need to run a saveenv first
to save the environment on the storage medium? Which is useful when you
have userspace modifying the environment (e.g. A/B partition choice).
But that's off-topic anyways and I'm not entirely sure this is actually
easily doable for the simple reason that I think sections are ordered in
DTB and we don't know where the user wants the environment on their
storage medium and that might change the order of the sections.
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...
Don't really want to hijack the thread with something slightly unrelated
but posting this here for posterity:
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
b/arch/arm/dts/rockchip-u-boot.dtsi
index daa5dea3d5..0af11341a1 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -11,8 +11,8 @@
};
};
-#ifdef CONFIG_SPL
&binman {
+#ifdef CONFIG_SPL
simple-bin {
filename = "u-boot-rockchip.bin";
pad-byte = <0xff>;
@@ -31,13 +31,66 @@
};
#ifdef CONFIG_ARM64
- blob {
- filename = "u-boot.itb";
+ fit {
+ offset = <((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64)
* 512)>;
+
+ description = "FIT image for U-Boot with bl31 (TF-A)";
+ #address-cells = <1>;
+ fit,fdt-list = "of-list";
+
+ images {
+ uboot {
+ description = "U-Boot (64-bit)";
+ type = "standalone";
+ os = "U-Boot";
+ arch = "arm64";
+ compression = "none";
+ load = <CONFIG_SYS_TEXT_BASE>;
+
+ u-boot-nodtb {
+ };
+ };
+
+ @atf-SEQ {
+ fit,operation = "split-elf";
+ description = "ARM Trusted Firmware";
+ type = "firmware";
+ arch = "arm64";
+ os = "arm-trusted-firmware";
+ compression = "none";
+ fit,load;
+ fit,entry;
+ fit,data;
+
+ atf-bl31 {
+ };
+ };
+
+ @fdt-SEQ {
+ description = "NAME";
+ type = "flat_dt";
+ compression = "none";
+
+ u-boot-dtb {
+ };
+ };
+ };
+
+ configurations {
+ default = "@config-DEFAULT-SEQ";
+ @config-SEQ {
+ description = "NAME";
+ firmware = "atf-1";
+ loadables = "uboot","atf-2","atf-3";
+ fdt = "fdt-SEQ";
+ };
+ };
+ };
#else
u-boot-img {
-#endif
offset = <((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64)
* 512)>;
};
+#endif
};
#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
@@ -69,5 +122,5 @@
};
};
#endif
-};
#endif
+};
is what I have currently done and the outcome of this is:
U-Boot TPL 2022.07-00811-gf6815f93eb-dirty (Jul 25 2022 - 18:24:06)
Channel 0: DDR3, 666MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
Channel 1: DDR3, 666MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
256B stride
Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL 2022.07-00811-gf6815f93eb-dirty (Jul 25 2022 - 18:24:06 +0200)
Trying to boot from MMC2
alloc space exhausted
FIT buffer of 1018880 bytes
Could not get FIT buffer of 1018880 bytes
check CONFIG_SYS_SPL_MALLOC_SIZE
No valid device tree binary found at 00000000002c0e88
initcall sequence 0000000000286bd0 failed at call 0000000000279604 (err=-1)
### ERROR ### Please RESET the board ###
The new u-boot-rockchip.bin is only about 2KB bigger. The name and
addresses are correctly returned by mkimage -l when comparing the
current implementation and with the patch above applied.
Cheers,
Quentin
