Romulus to use Virtual PNOR

[Lei YU]

On Tue, Feb 12, 2019 at 11:57 AM Joel Stanley <joel at jms.id.au> wrote:
>
> On Fri, 25 Jan 2019 at 18:11, Lei YU <mine260309 at gmail.com> wrote:
> >
> > This email is to notify that Romulus is going to use VirtualPNOR feature, if
> > no objections are received.
> >
> > It **impacts** to existing Romulus systems, that they must do PNOR code update
> > when the feature is enabled.
> >
> > A little background on this topic could be found at:
> > https://lists.ozlabs.org/pipermail/openbmc/2018-May/011822.html
> > https://lists.ozlabs.org/pipermail/openbmc/2018-November/014112.html
> >
> > I did not receive any feedback, so I choose to use VritualPNOR feature,
> > which has below benefits:
> > 1. It requires minor code changes for a system to switch to VirtualPNOR;
> > 2. It gets full features, including PNOR version, code verification, and code
> >    update via new interface;
> > 3. When OpenBMC switches to Redfish, it will get Redfish code update for free,
> >    because IBM will implement Redfish code update based on VirtualPNOR.
> >
> > The related changes are:
> > * OpenBMC: https://gerrit.openbmc-project.xyz/#/q/topic:ubifs-pnor-for-romulus
> > * op-build: https://github.com/open-power/op-build/pull/2578
> >
> > Any objections?
>
> I would prefer this not to happen.
>
> The "virtual pnor" feature is tightly coupled to UBI. The preferred
> filesystem to use on small NOR chips is JFFS2, which suits the
> technology and the size that BMCs ship on.
>
> Moving to vpnor breaks features such as full pnor flashing from the host.

Based on the discussion, let's keep using static flash layout for PNOR on
Romulus.

This brings the questions:
1. Shall we move the legacy code update service
   (org.openbmc.control.Flash.service) to the new one
   (xyz.openbmc_project.Software.xxx.service)?
2. How do we plan to support PNOR version, image verification for static flash
   layout?