[U-Boot] beagle-bone fdt booting problem

[Simon Glass]

+Tom, Albert for this bug

Hi Belisko,

On 28 March 2014 03:40, Belisko Marek <marek.belisko at gmail.com> wrote:

> Hello,
>
> On Thu, Mar 27, 2014 at 4:28 PM, Simon Glass <sjg at chromium.org> wrote:
> > Hi,
> >
> > On 26 March 2014 00:10, Belisko Marek <marek.belisko at gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> I'm playing with fdt booting on beaglebone board. I'm using latest
> >> u-boot git HEAD (2c072c958bb544c72f0e848375803dbd6971f022) + I've
> >> added to am335x_evm confing :
> >> #ifndef CONFIG_SPL_BUILD
> >> #define CONFIG_OF_CONTROL
> >> #define CONFIG_OF_SEPARATE
> >> #endif
> >>
> >> I took beaglebone devicetree from kernel. Then I took patch [1] to
> >> build image from u-boot and my compiled DT blob.
> >>
> >> Booting this image always fails with:
> >> No valid FDT found - please append one to U-Boot binary, use
> >> u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d
> >> <file.dtb>
> >> ** CONFIG_OF_CONTROL defined but no FDT - please see
> >> doc/README.fdt-control
> >>
> >> I poke around this and find out that when CONFIG_OF_SEPARATE is used
> >> then fdt_blob is set to address of .__end pointer. When evaluate image
> >> with hexdump it seems that fdt blob (in my particular case and
> >> configuration) is shifted by 312 bytes from .__end. When I point
> >> gd->fdt_blob (hack in code) to that address it boots fine. Any ideas
> >> what I'm doing wrong (I must do something wrong as it seems nobody
> >> complains  :)).
> >>
> >> [1] -
> >>
> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=d4ab2022cdfe098e93819c58188ad36174160872
> >
> >
> > You might be best taking this from the u-boot-x86.git branch 'bone'. It
> is a
> > little old but it does work.
> It was based on that patches just [1] was reworked to fit latest
> u-boot (applied with errors):
>
> diff --git a/Makefile b/Makefile
> index 538c3bf..0505678 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -752,8 +752,13 @@ u-boot-dtb.bin: u-boot.bin dts/dt.dtb FORCE
>  quiet_cmd_copy = COPY    $@
>        cmd_copy = cp $< $@
>
> +ifneq ($(DEV_TREE_BIN),)
> +u-boot.dtb:
> +       cp $(DEV_TREE_BIN) $@
> +else
>  u-boot.dtb: dts/dt.dtb
>         $(call cmd,copy)
> +endif
>
>  OBJCOPYFLAGS_u-boot.hex := -O ihex
>
> @@ -799,7 +804,7 @@ MKIMAGEFLAGS_u-boot.kwb = -n
> $(srctree)/$(CONFIG_SYS_KWD_CONFIG:"%"=%) \
>  MKIMAGEFLAGS_u-boot.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:"%"=%) \
>                 -R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:"%"=%) -T pblimage
>
> -u-boot.img u-boot.kwb u-boot.pbl: u-boot.bin FORCE
> +u-boot.img u-boot.kwb u-boot.pbl: u-boot$(if
> $(CONFIG_OF_SEPARATE),-dtb,).bin FORCE
>         $(call if_changed,mkimage)
>
>  u-boot.imx: u-boot.bin
> >
> > The patches for this were never applied unfortunately. I'll update them
> to
> > mainline again at some point and resubmit.
> OK. Basically it was working I just hit 2 issues. One with odd skip
> 312 bytes and second
> that signature wasn't added to final image and verification was check
> only sha1 not rsa2048 ( I check when enable debug for some modules):
>  Verifying Hash Integrity ... fit_image_verify_required_sigs: No
> signature node found: FDT_ERR_NOTFOUND
> I took some patches from next (which seems fixed signature issue) but
> it doesn't solve above problem.
>

The 312 bytes issue turns out to be a problem with the hash section being
appended after the supposed end of U-Boot. It was introduced in  b02bfc4
and will go out in this release unless we fix it. I've got a patch which
fixes it - will be doing some more testing and then submit along with a
resubmit of the Beaglebone black verified boot patches.

Regards,
Simon