[U-Boot] Wandboard boot failure when HAB support is enabled

Wed Aug 28 18:16:18 UTC 2019

Hi Breno,

On Wed, Aug 28, 2019 at 12:14 PM Breno Matheus Lima
<brenomatheus at gmail.com> wrote:
>
> Hi Jon,
>
> Em qua, 28 de ago de 2019 às 09:49, Jon Szymaniak
> <jon.szymaniak.foss at 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