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.f...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
