On Wed, Jun 17, 2026 at 09:31:30AM +0300, Andy Shevchenko wrote: > On Tue, Jun 16, 2026 at 08:24:16AM -0600, Simon Glass wrote: > > Intel Atom SoCs (Medfield, Clovertrail, Merrifield and Moorefield) boot > > via an 'OS Image Profile' (OSIP): a 512-byte '$OS$' header which tells > > the boot ROM where the OS image lives, where to load it and where to > > start executing. On the Intel Edison (Merrifield) the OS image is > > U-Boot. > > > > The Edison image embeds this header as the static blob > > board/intel/edison/edison-osip.dat which is an empty stub in the tree, > > so a fresh build emits an all-zero, non-functional header. > > > > Add an 'intel-osip' entry type which builds the header from devicetree > > properties, computing the checksum and taking the load address and entry > > point (both required) plus the logical block address, image size and > > attribute as parameters. The same sector doubles as the eMMC's > > protective MBR, which the boot ROM requires before it loads the OS > > image, so emit a GPT-protective (0xee) partition entry and the 0x55aa > > signature too. Use it for the Edison image in place of that blob, and > > remove the now-unused stub file. > > > > The Edison node derives the load address and entry point from > > CONFIG_TEXT_BASE (entry point) and CONFIG_TEXT_BASE - 0x1000 (load > > address), rather than repeating the magic numbers, since the 0x1000 > > difference is the mask ROM's load/entry gap. > > Reviewed-by: Andy Shevchenko <[email protected]>
While I gave a tag, please check the comment in my reply to patch 5. -- With Best Regards, Andy Shevchenko
