Hello Tim, On 20.07.21 00:23, Tim Harvey wrote: > On Sun, Jul 18, 2021 at 9:01 PM Heiko Schocher <[email protected]> wrote: >> >> Hello Tim, >> >> On 12.07.21 18:06, Tim Harvey wrote: >>> On Sat, Jul 10, 2021 at 5:24 AM Heiko Schocher <[email protected]> wrote: >>>> >>>> Hi Tim, Stefano, >>>> >>>> On 10.07.21 11:14, Stefano Babic wrote: >>>>> Hi Tim, >>>>> >>>>> On 10.07.21 02:05, Tim Harvey wrote: >>>>>> Greetings, >>>>>> >>>>>> Has anyone successfully used secure boot with IMX8M Mini or other >>>>>> IMX8M? Peng's recent series got merged with the exception of what >>>>>> looks like the addition of couple of 'caam' commands to blob/deblob >>>>>> DEK's. >>>>>> >>>>>> There are no guides yet however I'm following the guides for the >>>>>> downstream NXP U-Boot and thus far have been able to get the SPL to >>>>>> boot with no HAB events but when it tries to authenticate the FIT >>>>>> image it validate_ivt fails with 'Error: Invalid IVT structure'. >>>>> >>>>> Heiko tested this and found it, if I am not wrong he found the cause. >>>>> Added him in CC. >>>>> >>>>> I have also planned to test this, it is on my TODO list... >>>> >>>> I am currently not in my office, the whole next week ... so I could not >>>> check my current state of the patches... but I found a problem, yes. >>>> >>>> The problem was that the ROM API loaded the IVT header to a >>>> memallocated address, which does of course not fit with the >>>> address you have in IVT header ... >>>> >>>> I have not full access to my development setup ,and found on my local >>>> some old state of the patches .... may you can try them? >>>> >>>> Of course they need a rework, other solution, but it shows the problem >>>> hopefully... >>>> >>> >>> Heiko, >>> >>> Thank you - that was indeed the issue and your patches resolve it. I >> >> Cool! Thanks for testing! >> >>> have not seen your patch posted to the list and your commit msg makes >> >> Yes, as they are WIP not posted yet ... and I thought, I make something >> wrong ... but if you have the same problem, it seems it is a real bug! >> >>> it seem like your not sure if you should make it SoC dependent. Do you >>> plan on submitting these to the mailing list? >> >> The question is: is my approach to fix it the way to go? If you think so, >> I can send them .. but give me please some time as I am just back from >> vacation... >> >> Fast look into it: >> >> spl_load_simple_fit_fix_load() must also check if there is at "fit" >> pointer an IVT header, if not, return simply fit pointer. > > Yes, otherwise non-hab will fail, correct?
Yes. >> Question: dependent on SoC ... as it is in common code, and I think we >> need this "fix" only for imx8m?, so yes, it should be SoC dependent >> or better only imx8m? code defines this function... if possible. >> Therefore the weak function approach. >> >> If you find time for looking at it, I am fine, if you use my patches >> as base and you can post them? >> > > I may be able to look at it again later this week or next. Fine. > I did run into another snag in that I could not figure out a proper > CSF template for multiple DTB's. When I try to include mulitple DTB's > I get several HAB events. > > flash.log: > ... > ========= OFFSET dump ========= > Loader IMAGE: > header_image_off 0x0 > image_off 0x40 > csf_off 0x33200 > spl hab block: 0x7e0fc0 0x0 0x33200 > > Second Loader IMAGE: > sld_header_off 0x57c00 > sld_csf_off 0x58c20 > sld hab block: 0x401fcdc0 0x57c00 0x1020 > > csf_fit.txt: > ... > [Authenticate Data] > # Key slot index used to authenticate the image data > Verification index = 2 > # Authenticate Start Address, Offset, Length and file > Blocks = \ > 0x401fcdc0 0x00057c00 0x00001020 "flash.bin", \ > 0x40200000 0x0005ac00 0x000b0150 "flash.bin", \ > 0x402b0150 0x0010ad50 0x00008bc4 "flash.bin", \ > 0x00920000 0x00113914 0x00009159 "flash.bin" > > So that first block is the FIT image header I think (only 4128 bytes > long) using data from flash.log 'sld hab block:', the second block is Yes > u-boot-nodtb.bin from within the FIT image, the third block is the dtb Yes and yes > from within the FIT, and the fourth block is the ATF from within the > FIT. Yes > When I have multiple DTB's do I need a block per DTB? I haven't found > any example of a CSF template where CONFIG_OF_LIST has multiple dtb's. Hmm... good question... I think (not tested) when you have multiple DTBs the DTBs are packed into a FIT image, so you have again only one "dtb" part to sign... ./doc/README.multi-dtb-fit says: """ The relevant DTBs are packed into a FIT (list provided by CONFIG_OF_LIST). The FIT is automatically generated at the end of the compilation and appended to u-boot.bin so that U-Boot can locate it and select the correct DTB from inside the FIT. """ So I think no problem...or? bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: [email protected]
