Charts from OpenBMC MRW Talk
Matt Spinler
mspinler at linux.vnet.ibm.com
Thu Sep 8 06:15:21 AEST 2016
Hi Joel,
On 8/28/2016 11:44 PM, Joel Stanley wrote:
> Hello Matt,
>
> On Fri, Aug 26, 2016 at 1:21 AM, Matt Spinler
> <mspinler at linux.vnet.ibm.com> wrote:
>> Here are the charts from the Machine Readable Workbook talk I gave on 8/25.
> Thanks for sending these along. I was unable to attend you call as it
> was at 1:00am, and I was skiing in the Australian alps. Are there any
> notes from the presentation that you have to share?
>
> I gave the slides a read. Some questions I had:
>
> Serverwiz. I cloned the repository and tried to build with ant. It
> failed due to some hardcoded Windows paths. I opened a ticket here:
> https://github.com/open-power/serverwiz/issues/20
Looks like Norm said he fixed this. Also, in general people should
never need to
build serverwiz themselves. They can just download the jars from the
release page.
> XML Patching. Under what circumstances would you patch the XML when
> you have the entire thing available to edit?
In the past we've seen where the person who own the MRW XML, who is
usually outside
of the firmware group, is slow to bring an XML fix through a pull
request under
github.com/open-power/<system>-xml. With a patch, we can make a fix
within our
own repository without having to check in the full <system>.xml which
otherwise doesn't
exist inside the openbmc repositories. It also allows the fix to remain
across multiple
MRW XML updates if they don't fix the desired thing. Additionally, it
can add an easier
way to phase in new code that uses new XML, first by using the patching
mechanism and
then later updating the real XML.
> Current status. You have some upcoming goals there. I would be
> interested in seeing "generation of device tree" pushed much higher up
> the list. I think device tree is an alternative representation of the
> MRW. Because of that it would be an easy target for your prototyping,
> and would allow us to see how it works in practice for a well
> understood use case.
Sounds reasonable, though I don't personally have any experience with
device trees
so it will be slow going for me.
> Another use case is generating the Python that describes the
> platform's GPIOs (skeleton/configs/*.py). This has been a source of
> recent bugs, so making sure the MRW matches the Python would help
> shake out some more issues.
Sure, I can add that to the list.
> Cheers,
>
> Joel
>
More information about the openbmc
mailing list