Re: [PATCH v2 1/5] binman: Add an entry type for the Intel OSIP header

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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 <andriy.shevchenko@linux.intel.com>

While I gave a tag, please check the comment in my reply to patch 5.

-- 
With Best Regards,
Andy Shevchenko