Dear Simon Glass, On Tue, Jun 3, 2014 at 6:42 AM, Simon Glass <[email protected]> wrote: > Hi Belisko, > > On 28 April 2014 00:30, Belisko Marek <[email protected]> wrote: >> Hi Simon, >> >> On Wed, Apr 16, 2014 at 4:41 PM, Simon Glass <[email protected]> wrote: >>> This series fixes a few problems that have come up since the secure boot >>> series was merged: >>> >>> - A recent commit broken the assumption that u-boot.bin ends at a known >>> address (thus making things appended to U-Boot inaccessible from the code). >>> This is fixed for Beaglebone and also a new test is added to the Makefile >>> to ensure that it does not break again. All boards have been tested. >>> >>> - A way is needed to provide an externally-build device tree binary for >>> U-Boot. This allows signing to happen outside the U-Boot build system. >>> >>> - The .img files generated by an OMAP build need to include the FDT if one >>> is appended. >>> >>> - Adding signatures to an FDT can cause the FDT to run out of space. The >>> fix is to regenerate the FDT from scratch with different dtc parameters, so >>> pretty painful. Instead, we automatically expand the FDT. >>> >>> The last two commits enable secure boot on Beaglebone (this will have no >>> effect unless signed images are used). This could be moved to a separate >>> configuration if required, or these patches could even be ignored: >> I've tested this patch series and I found some issues. When I use dtb >> build from latest 3.15-rc3 kernel >> I got during signing this errors: >> Couldn't create signature node: FDT_ERR_NOSPACE >> Failed to add verification data for 'signature@1' signature node in >> 'conf@1' image node >> >> which was fixed by those 2 small patches: >> - this one doesn't overwrite return value because upper layer then >> stop with no space error and doesn't allocate more space >> --- a/lib/rsa/rsa-sign.c >> +++ b/lib/rsa/rsa-sign.c >> @@ -405,7 +405,7 @@ int rsa_add_verify_data(struct image_sign_info >> *info, void *keydest) >> if (parent < 0) { >> fprintf(stderr, "Couldn't create signature node: >> %s\n", >> fdt_strerror(parent)); >> - return -EINVAL; >> + return parent; >> } >> } >> >> --- a/tools/image-host.c >> +++ b/tools/image-host.c >> @@ -612,7 +612,7 @@ static int fit_config_process_sig(const char >> *keydir, void *keydest, >> if (ret) { >> printf("Failed to add verification data for >> '%s' signature node in '%s' image node\n", >> node_name, conf_name); >> - return ret == FDT_ERR_NOSPACE ? -ENOSPC : -EIO; >> + return ret == -FDT_ERR_NOSPACE ? -ENOSPC : -EIO; >> } >> } >> >> With this small changes I can create signed fit image. Other problem >> appear during booting. I'm using simple uEnv.txt >> to get fit image to ram and boot (setenv loadaddr '0x8050000'; run >> loadimage; bootm). Booting of kernel fails with data abort: >> >> Importing environment from mmc ... >> Running uenvcmd ... >> reading /uImage >> 4322274 bytes read in 585 ms (7 MiB/s) >> ## Loading kernel from FIT Image at 80500000 ... >> Using 'conf@1' configuration >> Verifying Hash Integrity ... sha1,rsa2048:dev+ OK >> Trying 'kernel@1' kernel subimage >> Description: Linux kernel >> Type: Kernel Image >> Compression: uncompressed >> Data Start: 0x805000e4 >> Data Size: 4289584 Bytes = 4.1 MiB >> Architecture: ARM >> OS: Linux >> Load Address: 0x80008000 >> Entry Point: 0x80008000 >> Hash algo: sha1 >> Hash value: 74d429a5c48d72ce3f569ba7eaa072c8c1eaab20 >> Verifying Hash Integrity ... sha1+ OK >> ## Loading fdt from FIT Image at 80500000 ... >> Using 'conf@1' configuration >> Trying 'fdt@1' fdt subimage >> Description: Flattened Device Tree blob >> Type: Flat Device Tree >> Compression: uncompressed >> Data Start: 0x80917608 >> Data Size: 29802 Bytes = 29.1 KiB >> Architecture: ARM >> Hash algo: sha1 >> Hash value: e86cfd55c3e869c6b3014c758825b2a1ade3991e >> Verifying Hash Integrity ... sha1+ OK >> Booting using the fdt blob at 0x80917608 >> Loading Kernel Image ... OK >> Using Device Tree in place at 80917608, end 80921a71 >> >> Starting kernel ... >> >> data abort >> pc : [<81a80020>] lr : [<80008008>] >> sp : 8e71b528 ip : 0000000c fp : 00000400 >> r10: 8f7a3d60 r9 : 8e723f28 r8 : 00000000 >> r7 : 00000000 r6 : 00000ffc r5 : 0ffc0004 r4 : 000000f7 >> r3 : fc7391ff r2 : 80917608 r1 : 00000e05 r0 : 80917608 >> Flags: Nzcv IRQs off FIQs on Mode SVC_32 >> Resetting CPU ... >> >> I wasn't able yet track down what is causing this issue but it >> happened when jumping to kernel >> image (kernel_entry(0, machid, r2);). Any ideas what to check? Thanks >> in advance. > > For this I'm not sure, perhaps your load address is wrong? Yes I've fixed this issue some time ago. What about those two mentioned patches? Without them I cannot create FIT properly.
> > I just sent out a new series (available in u-boot-x86.git branch > 'bone') which adds some step-by-step documentation. It also collects > all the fixes in one place. Thanks I'll look on that. > > [snip] > > Regards, > Simon BR, marek -- as simple and primitive as possible ------------------------------------------------- Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
