+Tom, Albert for this bug Hi Belisko,
On 28 March 2014 03:40, Belisko Marek <marek.beli...@gmail.com> wrote: > Hello, > > On Thu, Mar 27, 2014 at 4:28 PM, Simon Glass <s...@chromium.org> wrote: > > Hi, > > > > On 26 March 2014 00:10, Belisko Marek <marek.beli...@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
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
