From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jon Szymaniak <jon.szymaniak.foss@gmail.com>
Date: Tue, 27 Aug 2019 13:03:20 -0500
Subject: [U-Boot] Wandboard boot failure when HAB support is enabled
Message-ID: <CAPxrFVkYn=OCpAFT4Myxxeh5gC6AX8H9J6X+Fpvgh3PsYPkOag@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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