* [U-Boot] Wandboard boot failure when HAB support is enabled @ 2019-08-27 18:03 Jon Szymaniak 2019-08-28 13:07 ` Fabio Estevam 2019-08-28 17:13 ` Breno Matheus Lima 0 siblings, 2 replies; 4+ messages in thread From: Jon Szymaniak @ 2019-08-27 18:03 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* [U-Boot] Wandboard boot failure when HAB support is enabled 2019-08-27 18:03 [U-Boot] Wandboard boot failure when HAB support is enabled Jon Szymaniak @ 2019-08-28 13:07 ` Fabio Estevam 2019-08-28 17:13 ` Breno Matheus Lima 1 sibling, 0 replies; 4+ messages in thread From: Fabio Estevam @ 2019-08-28 13:07 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] Wandboard boot failure when HAB support is enabled 2019-08-27 18:03 [U-Boot] Wandboard boot failure when HAB support is enabled Jon Szymaniak 2019-08-28 13:07 ` Fabio Estevam @ 2019-08-28 17:13 ` Breno Matheus Lima 2019-08-28 18:16 ` Jon Szymaniak 1 sibling, 1 reply; 4+ messages in thread From: Breno Matheus Lima @ 2019-08-28 17:13 UTC (permalink / raw) To: u-boot Hi Jon, Em qua, 28 de ago de 2019 Ã s 09:49, Jon Szymaniak <jon.szymaniak.foss@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 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. Thanks, Breno Lima ^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] Wandboard boot failure when HAB support is enabled 2019-08-28 17:13 ` Breno Matheus Lima @ 2019-08-28 18:16 ` Jon Szymaniak 0 siblings, 0 replies; 4+ messages in thread From: Jon Szymaniak @ 2019-08-28 18:16 UTC (permalink / raw) To: u-boot Hi Breno, On Wed, Aug 28, 2019 at 12:14 PM Breno Matheus Lima <brenomatheus@gmail.com> wrote: > > Hi Jon, > > Em qua, 28 de ago de 2019 Ã s 09:49, Jon Szymaniak > <jon.szymaniak.foss@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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-08-28 18:16 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-27 18:03 [U-Boot] Wandboard boot failure when HAB support is enabled Jon Szymaniak 2019-08-28 13:07 ` Fabio Estevam 2019-08-28 17:13 ` Breno Matheus Lima 2019-08-28 18:16 ` Jon Szymaniak
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.