Hi Breno, On Wed, Aug 28, 2019 at 12:14 PM Breno Matheus Lima <brenomath...@gmail.com> wrote: > > Hi Jon, > > Em qua, 28 de ago de 2019 às 09:49, Jon Szymaniak > <jon.szymaniak.f...@gmail.com> escreveu: > > > > 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? > > Thanks for reporting the issue. > > We have a related discussion in thread below, this issue is happening > with all i.MX targets supporting FIT image: > https://lists.denx.de/pipermail/u-boot/2019-June/373287.html > > HABv4 authenticate image API requires an IVT to work, so in my opinion > we need to generate an IVT header for the FIT image. We are using > similar structure in NXP U-Boot for i.MX8M devices: > https://lists.denx.de/pipermail/u-boot/2019-June/373287.html > > HABv4 should be able to authenticate FIT image in memory in case we > provide a valid IVT, we can specif multiple blocks and offsets as in > CSF example below: > https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4/csf_examples/mx8m_mx8mm/csf_fit.txt?h=imx_v2018.03_4.14.98_2.0.0_ga >
Thank you! I will spend some more time familiarizing myself with these discussions, along with revisiting the HAB and FIT documentation. Based on my cursory review of these, am I correct in understanding that the planned layout for IVT+FIT for the i.MX8M(M) will largely be a superset of what is needed for the i.MX6/7 series (i.e. sans the added/optional components), and therefore the resulting image changes should be usable by both 6/7 and 8? > I don't see a reason to use the "legacy" boot images as HAB should be > able to authenticate the FIT image layout, we may need to understand > how to adapt the current image layout. FWIW, I agree and most definitely prefer the use of FIT. Regarding my usage of the "legacy" image -- I was just initially a little bit confused by the build artifacts produced when I enabled CONFIG_SECURE_BOOT=y, and wasn't sure what the expected behavior and image format was. > > Thanks, > Breno Lima _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
