<html><head></head><body dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="ApplePlainTextBody"><br><blockquote type="cite">On Jul 11, 2017, at 4:47 PM, Stewart Smith <stewart@linux.vnet.ibm.com> wrote:<br><br>Adriana Kobylak <anoo@linux.vnet.ibm.com> writes:<br><blockquote type="cite"><blockquote type="cite">On Jun 21, 2017, at 12:42 AM, Stewart Smith <stewart@linux.vnet.ibm.com> wrote:<br><br>Adriana Kobylak <anoo@linux.vnet.ibm.com <mailto:anoo@linux.vnet.ibm.com>> writes:<br><blockquote type="cite"><blockquote type="cite">On Jun 19, 2017, at 12:44 AM, Stewart Smith <stewart@linux.vnet.ibm.com> wrote:<br><br>Adriana Kobylak <anoo@linux.vnet.ibm.com> writes:<br><blockquote type="cite"><blockquote type="cite">Why is there mboxbridge separate from phosphor-mboxd?<br></blockquote><br>Because the mboxbridge is being used by other companies as a reference<br>to be able to implement the mailbox daemon in their own BMC firmware<br>stack for other openpower systems, we didn’t want to “pollute” the<br>repository with openbmc-specific and c++ implementation that could<br>confuse them.<br></blockquote><br>Why are there OpenBMC specific things in mboxd?<br><br>Why can't the reference implementation be used? What's deficient in it?<br></blockquote><br>For OpenBMC, we’re having the PNOR chip with a filesystem, so mboxd<br>would read/write files instead of looking for the data at an offset in<br>the chip. Nothing deficient with it, just a different implementation<br>that needs to be handled.<br></blockquote><br>Why not have an MBOX protocol that supports partitions/files natively<br>then? Why not develop this upstream? Surely this is something others<br>could be interested in.<br><br></blockquote>It’d be available in the openbmc/phosphor-mboxd repo for anybody that<br>wants to use it. Or what do you mean by develop it upstream?<br></blockquote><br>I mean in https://github.com/openbmc/mboxbridge - the reference<br>implementation.<br></blockquote>It was decided with AndrewJ’s feedback to not have the reference implementation handle multiple formats, and just leave it for ffs.<br><blockquote type="cite"><br><blockquote type="cite"><blockquote type="cite">It seems really backwards having a bunch of things convert to/from FFS<br>for no reason.<br></blockquote><br>We’re not converting back and forth, if the pnor is blank, we’ll<br>attach ubi to it, and if the pnor is formatted as ffs it’ll be<br>reformatted once to ubi.<br></blockquote><br>I mean that I don't see any patches changing how we build things in<br>op-build, so there has to be some unpacking of the content going on<br>there.<br></blockquote>There are no changes needed in op-build since this is an openbmc implementation, there’s a script in openbmc that unpacks the pnor file from op-build into partition files, I’ll send the link to the documentation details for it.<br><blockquote type="cite"><br>-- <br>Stewart Smith<br>OPAL Architect, IBM.<br></blockquote><br></div></body></html>