[Skiboot] OpenPower gard tool rework

Oliver oohall at gmail.com
Thu Nov 9 10:44:23 AEDT 2017

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?

>>       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. 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. 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.

>>       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!



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

More information about the Skiboot mailing list