How to use WIC to generate raw flash images

How to use WIC to generate raw flash images

[Rick Altherr]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

For OpenBMC (based on Yocto), the target is an SoC that has an external
boot flash connected via SPI.  Right now, we have a class (
https://github.com/openbmc/openbmc/blob/master/meta-phosphor/classes/image-overlay.bbclass)
used by our top-level image recipe (
https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/images/obmc-phosphor-image.bb)
that manually constructs a flash image from the kernel, rootfs, etc.  I'd
like to move to an upstream-supported approach and I think that is WIC.
What I don't understand is:
- How do I build a raw flash image where it is divided into partitions but
has no partition table?
- How do I set padding to be 0xFF instead of 0x00?
- How do I include u-boot in the image?

Do I need to add a new imager plugin to support writing raw images with
non-zero padding and no partition table?  For U-Boot, do I add a new
bootimg plugin?

Rick

[-- Attachment #2: Type: text/html, Size: 1250 bytes --]

Re: How to use WIC to generate raw flash images

[Ed Bartosh]

On Fri, Jan 20, 2017 at 10:37:15AM -0800, Rick Altherr wrote:
> For OpenBMC (based on Yocto), the target is an SoC that has an external
> boot flash connected via SPI.  Right now, we have a class (
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/classes/image-overlay.bbclass)
> used by our top-level image recipe (
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-phosphor/images/obmc-phosphor-image.bb)
> that manually constructs a flash image from the kernel, rootfs, etc.

This is indeed very interesting work. We definitely need support of flash images in oe-core.

> I'd like to move to an upstream-supported approach and I think that is WIC.

> What I don't understand is:
> - How do I build a raw flash image where it is divided into partitions but
> has no partition table?

Wic doesn't support this type of images, but it shouldn't be hard to add
option to skip partitioning to .wks syntax and wic code.

> - How do I set padding to be 0xFF instead of 0x00?
The same thing here. Currently wic images are sparse files created by
os.ftruncate, but it's not a big deal to fill them with 0xFF

> - How do I include u-boot in the image?

This can be done by using/extending rawcopy plugin or writing similar
one.

> Do I need to add a new imager plugin to support writing raw images with
> non-zero padding and no partition table?  For U-Boot, do I add a new
> bootimg plugin?

This sounds reasonable. Can you create a bug for this in bugzilla to discuss design and implementation details?

--
Regards,
Ed

Re: How to use WIC to generate raw flash images

[Rick Altherr]

[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]

https://bugzilla.yoctoproject.org/show_bug.cgi?id=10957

On Mon, Jan 23, 2017 at 2:34 AM, Ed Bartosh <ed.bartosh@linux.intel.com>
wrote:

> On Fri, Jan 20, 2017 at 10:37:15AM -0800, Rick Altherr wrote:
> > For OpenBMC (based on Yocto), the target is an SoC that has an external
> > boot flash connected via SPI.  Right now, we have a class (
> > https://github.com/openbmc/openbmc/blob/master/meta-
> phosphor/classes/image-overlay.bbclass)
> > used by our top-level image recipe (
> > https://github.com/openbmc/openbmc/blob/master/meta-
> phosphor/common/recipes-phosphor/images/obmc-phosphor-image.bb)
> > that manually constructs a flash image from the kernel, rootfs, etc.
>
> This is indeed very interesting work. We definitely need support of flash
> images in oe-core.
>
> > I'd like to move to an upstream-supported approach and I think that is
> WIC.
>
> > What I don't understand is:
> > - How do I build a raw flash image where it is divided into partitions
> but
> > has no partition table?
>
> Wic doesn't support this type of images, but it shouldn't be hard to add
> option to skip partitioning to .wks syntax and wic code.
>
> > - How do I set padding to be 0xFF instead of 0x00?
> The same thing here. Currently wic images are sparse files created by
> os.ftruncate, but it's not a big deal to fill them with 0xFF
>
> > - How do I include u-boot in the image?
>
> This can be done by using/extending rawcopy plugin or writing similar
> one.
>
> > Do I need to add a new imager plugin to support writing raw images with
> > non-zero padding and no partition table?  For U-Boot, do I add a new
> > bootimg plugin?
>
> This sounds reasonable. Can you create a bug for this in bugzilla to
> discuss design and implementation details?
>
> --
> Regards,
> Ed
>

[-- Attachment #2: Type: text/html, Size: 2765 bytes --]

Re: How to use WIC to generate raw flash images

[Mike Looijmans]

On 23-01-17 11:34, Ed Bartosh wrote:
...
>> - How do I set padding to be 0xFF instead of 0x00?
> The same thing here. Currently wic images are sparse files created by
> os.ftruncate, but it's not a big deal to fill them with 0xFF

Correct me if I'm wrong here...
- All flash media (NOR, NAND) prefers padding with 0xFF because that's equal 
to an erased sector.
- Other media (magnetic disks) don't care about what they're padded with.

So I'd say it makes sense to make 0xFF the default padding for exerything?



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Re: How to use WIC to generate raw flash images

[Ed Bartosh]

On Tue, Jan 24, 2017 at 09:56:17AM +0100, Mike Looijmans wrote:
> On 23-01-17 11:34, Ed Bartosh wrote:
> ...
> >>- How do I set padding to be 0xFF instead of 0x00?
> >The same thing here. Currently wic images are sparse files created by
> >os.ftruncate, but it's not a big deal to fill them with 0xFF
> 
> Correct me if I'm wrong here...
> - All flash media (NOR, NAND) prefers padding with 0xFF because
> that's equal to an erased sector.
> - Other media (magnetic disks) don't care about what they're padded with.
> 
> So I'd say it makes sense to make 0xFF the default padding for exerything?

That would break image sparseness.

--
Regards,
Ed