[Skiboot] OpenPower gard tool rework
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:
>> 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!
>> Skiboot mailing list
>> Skiboot at lists.ozlabs.org
More information about the Skiboot