phosphor-ipmi-flash: Next Iteration of Control

Patrick Venture venture at google.com
Sat Jun 29 09:16:10 AEST 2019


On Fri, Jun 28, 2019 at 3:52 PM Milton Miller II <miltonm at us.ibm.com> wrote:
>
> On  06/28/2019 at 05:21PM in some timezone,  Patrick Venture wrote:
> >On Fri, Jun 28, 2019 at 12:56 PM Adriana Kobylak <anoo at linux.ibm.com>
> >wrote:
> >>
> >> On 2019-06-28 13:37, Patrick Venture wrote:
> >> > I was thinking, since I'm going to extend phosphor-ipmi-flash to
> >> > support updating a BIOS -- it might make sense to make it more
> >general
> >> > further.  I was thinking about how right now, there are default
> >> > services you can implement for each thing, prepare, verify,
> >update,
> >> > and currently we don't install them (although I was going to
> >implement
> >> > a default prepare service).
> >> >
> >> > I was thinking that possibly adoption would be easier if they
> >were
> >> > targets instead of service files directly and then we'd always
> >install
> >> > the targets:
> >> >
> >> > - phosphor-ipmi-flash-prepare-update.target (always called when
> >> > starting up a process each time a new process is started)
> >> > - phosphor-ipmi-flash-verify-bmc.target
> >> > - phosphor-ipmi-flash-update-bmc.target
> >> >
> >> > Then a user can just install their services into the targets and
> >not
> >> > have to really worry about doing anything more.  I think it's
> >equally
> >> > as usable as before, but ... I don't know.  This way, it always
> >> > installs the targets.
> >>
> >> Yeah I think it'd make it more obvious to have the targets
> >installed
> >> than
> >> having optional services. Also this could allow services to be
> >started
> >> in parallel, like verifying 2 different images at the same time
> >> triggered
> >> by the target (just thinking out loud).
> >
> >Yeah, someone mentioned needing to run additional services, and
> >although they could chain them from the initial service, might be
> >easier with just having a target.  So, I'm going to roll that patch
> >into review today.  It'll require some recipe changes, but otherwise
> >I
> >don't anticipate any issues.
>
> Unfornately a simple target may be difficult:  Currently
> prepare-for-flash-update may curretnly set a firmware variable that
> requires a BMC reboot to take effect.  In this mode, the initramfs
> copies the file system to RAM during startup so theat the flash is
> available for writing the replacement image.  (Doing this step
> allows the flash to be written while full services are written).
>
> I suppose this could be turned into a target, but it would imply
> a BMC reboot loosing other sessions and may be unexpected.  The
> existing targets would need to be modified to recognise the
> system is in this state and NOP (currently it can not be
> deterimined if you are currently in the state otther than
> unreliably peeking at /proc/mounts).

I'm not entirely sure how this would be different from the case where
a service is executing the things, versus a target.

>
> Not to say having the targets is a bad idea, just that it might
> require a bit more work.
>
> milton
>
> >>>
> >> >
> >> > I was thinking about this further and was thinking about how
> >> > everything is compiled into the application,
> >dynamically/configurable,
> >> > but compiled in.
> >> >
> >> > If it's going to start supporting BIOS, and then later other
> >firmware,
> >> > perhaps the list of Blobs and their associated actions should be
> >> > configured via json.  There is a limitation to this though that
> >if
> >> > that's the case, then the ActionInterface used for different
> >things
> >> > would really just become a SystemdActionInterface and we'd use
> >> > services to control everything.  In theory, the json could
> >specify the
> >> > ActionInterfaceType from a list and the parameters after that
> >point
> >> > would be per type..., but I think that's getting a bit
> >easy-to-break.
> >>
> >> Yeah, maybe we wait to see if anybody would prefer not having to
> >compile
> >> the
> >> tool with the available options.
> >
> >Yeah.  I'll play around with it a bit and submit patches next week.
> >Still need to do more testing, and it's missing some tests :)
> >
> >>
> >> >
> >> > Those are just some thoughts I had today.
> >> >
> >> > Regards,
> >> > Patrick
> >
> >
>


More information about the openbmc mailing list