[Skiboot] OpenPower gard tool rework

[Cyril Bur]

On Thu, 2017-11-09 at 10:44 +1100, Oliver wrote:
> On Thu, Nov 9, 2017 at 10:28 AM, Cyril Bur <cyrilbur at gmail.com> wrote:
> > On Wed, 2017-11-08 at 19:59 +1100, Oliver O'Halloran wrote:
> > > Hi,
> > > 
> > > This series contains a substantial rework of the OpenPower gard tool.
> > > The main additions being:
> > > 
> > 
> > Hi Oliver,
> > 
> > Thanks for the series, looks like a sweet cleanup. The tool has been
> > needing some cleanup for some time.
> > 
> > As far as I can tell you haven't changed the fundamental way it
> > reads/writes (in fact you've forced the use of MTD which is a good
> > thing). The reason I ask this is that I'm getting increasingly keen on
> > an OPAL call to get gard records/partitions (details to be worked out),
> > think the way we currently do NVRAM. I can't see any reason why your
> > improvements make a transition to an OPAL call to get data harder but I
> > thought I'd ask.
> 
> What does having a separate OPAL call to retrieve gard records buy us compared
> to reading the flash directly?
> 

Are we reading the flash directly today ;)? Since skiboot is already in
the business of abstracting the flash, perhaps we want to really
commit. Like I said, details haven't been discussed, just making sure
we aren't making life hard for ourselves down the road if we do want to
do it.

> > 
> > >       a) The ability to create GARD records
> > >       b) Support for Power 9
> > 
> > Is there any way we detect a default programatically?
> 
> Sort of, it's a crapshoot a best though. If we're running on the host
> then we can just
> look at the device-tree (or PVR) to figure out the processor
> generation. 

Yeah I think for the host at least a sensible guess might be wise, pdbg
suffers from the "oh that flags to do I need to use here" problem.
I feel like the gard tools main use case is people simply not caring
but noticing that stuff has been garded out. It would be best if
interacting with it remained as easy as possible. (vpnor support++)


> It's a bit harder
> to guess what the host processor is when running on the BMC, but I
> figured that would be
> set something like the openbmc system config, so you could add -DASSUME_P9 to
> CFLAGS to set it at build time.

We used to have a philosophy of "everything on the host" so I would
have said maybe the BMC isn't so important (although I like that CFLAGS
idea). But apparently thats changing, so my argument for making it as
easy to use as possible on the host might be valid for the BMC too.

> If we're running on a x86 system (e.g.
> your laptop) there's
> no real way to tell what if we are looking at P8 or P9 records.
> 

Yeah that's obviously inevitable, but on x86 the problem already exists
in that you have to point it to a file...

> > 
> > >       c) Support for running on ARM (i.e BMCs)
> > >       d) Nicer output for the list subcommand.
> > >       e) A basic understanding of where to find GUARD on OpenBMC
> > >            with vPNOR.
> > > 
> > > This also does substantial (but incomplete) reworks of the internals of the
> > > tool to make it a bit easier to work with.
> > > 
> > > Record creation has only been lightly tested, but it seems to work
> > > provided the user targets a hardware unit that actually exists which
> > > is good enough for me.
> > 
> > As long as you're happy to deal with the fallout when people discover
> > this (record creation) is a thing and start doing dumb things with it
> > then thumbs up!
> 
> *shrug*
> 
> EVOIDWARRANTY
> 

Probably a bit too soon for popcorn, but I'll replenish my stocks.


Cyril

> > 
> > > 
> > > Oliver
> > > 
> > > _______________________________________________
> > > Skiboot mailing list
> > > Skiboot at lists.ozlabs.org
> > > https://lists.ozlabs.org/listinfo/skiboot