Hi Jon,
[Adding Breno on Cc, who is familiar with HAB support].
On Tue, Aug 27, 2019 at 3:03 PM Jon Szymaniak jon.szymaniak.foss@gmail.com wrote:
Hello all,
I'd like to get U-Boot >= 2019.07 booting on a Wandboard Quad with HAB support enabled, but appear to be running into either some regressions (or matters of PEBKAC). For the scope of this discussion, I'm only concerned with booting an "insecure" HAB-enabled U-Boot image (ideally FIT), on a device that has not yet been fused (i.e., with the U-Boot commands need to fuse and verify successful image authentication prior to enforcing ROM-based authentication of the SPL).
As of commit df516569, I am able to use the default Wandboard configuration, enable HAB support (CONFIG_SECURE_BOOT=y) via menufconfig, build and then successfully boot the resulting SPL + u-boot-ivt.img combination on a Wandboard Quad (B1).
However, as of commit 5b85858 (and onwards), I am no longer able to boot the second stage U-Boot image when HAB support is enabled (the SPL still works, however). Disabling HAB support (the default configuration state) still works, of course.
Issue #1: u-boot-ivt.img load address changed from 0x17800000 to 0x00000000
It appears that the generation of u-boot-ivt.img "breaks" in df516569 because the associated MKIMAGEFLAGS_u-boot-ivt.img definition, present in an else clause of the top-level Makefile, is no longer used, now that the default configuration enables SPL FIT support. As a result, the generated image contains a load address of 0x0, which results in a boot loop.
I've tried to work around this with the following change, which leads me to Issue #2. I'm unclear on whether a multi-DTB IVT image should be instead be produced to address this, or whether "legacy" boot images should continue to work.
diff --git a/Makefile b/Makefile index f3857ab6a9..07fa36b4c1 100644 --- a/Makefile +++ b/Makefile @@ -1243,12 +1243,13 @@ else MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" +endif
MKIMAGEFLAGS_u-boot-ivt.img = -A $(ARCH) -T firmware_ivt -C none -O u-boot \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" u-boot-ivt.img: MKIMAGEOUTPUT = u-boot-ivt.img.log CLEAN_FILES += u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-boot.imx.log -endif
MKIMAGEFLAGS_u-boot-dtb.img = $(MKIMAGEFLAGS_u-boot.img)
Issue #2: u-boot-ivt.img stuck in lib/hang.c's hang()
Once executing u-boot-ivt.img from 0x17800000, I'm seeing the following call path occurring:
board_init_f() -> initcall_run_list @ fdtdec_setup() errors out --> hang() -> bootstage_error(BOOTSTAGE_ID_NEED_RESET)
I'm still trying to determine specifically where in fdtdec_setup() the failure is, but before I dig too much deeper, I was hoping to get some feedback on whether this is simply a matter of needing to produce a modified image that isn't currently being built.
Again, I'm not entirely clear what the expectation is here -- should I simply not be attempting to boot the u-boot-ivt.img? Should this still work despite not being a FIT image? Do we need to generate a FIT-based IVT image for this configuration?
Thank you in advance for your time and help!
Best regards, Jon Szymaniak