In-Band Firmware Update

[Patrick Venture]

On Tue, Aug 7, 2018 at 9:41 AM, Patrick Venture <venture at google.com> wrote:
> On Tue, Aug 7, 2018 at 8:14 AM, Patrick Venture <venture at google.com> wrote:
>> On Mon, Aug 6, 2018 at 4:04 PM, Andrew Jeffery <andrew at aj.id.au> wrote:
>>>> I'd be interested in separating out the "file like" nature from the
>>>> interface, and keep it as just a "block level" update, that may be a
>>>> file, or may be something else.
>>>>
>>>
>>> A slight tangent, but I think it's worth talking about here:
>>>
>>> On OpenPOWER systems we developed a control protocol for the
>>> host to manipulate the LPC FW mapping. v3 of the protocol included
>>> support for mapping "arbitrary" stuff into the FW space with a
>>> command to list what devices were available. It seems very similar to
>>> what Patrick has outlined, though operates at the block level as Ed
>>> mused about above.
>>
>> i'm somewhat familiar with the mailbox daemon and v3 protocols
>> insomuch as we were using them on our openpower system before
>> transitioning to phosphor-ipmi-flash (for consistency across
>> platform).
>>
>>>
>>> Typically this mechanism is used for the host to access its firmware
>>> which - again on OpenPOWER designs - sits on a flash device owned
>>> by the BMC.
>>>
>>> The control protocol was run over the LPC mailbox available on
>>> ASPEED BMCs. However, I am currently developing a PoC IPMI
>>> replacement for the mailbox interface, and intended to use much
>>> the same command-set and argument layout as we have with the
>>> mailbox. As mentioned above it aligns pretty well with what Patrick
>>> is proposing.
>>>
>>> So our use-case has less of an update focus, but at the end of the
>>> day if you can perform arbitrary writes it roughly amounts to the
>>> same thing. Should we expand the scope to cover my use-case here?
>>> I'm fine if the answer is "no", but with the similarities it seemed
>>> necessary to bring up.
>>
>> The explicit out-of-band-data flow-control messages in
>> phosphor-ipmi-flash fit the semantics to an extent.  We actually use
>> one of the packets in the design
>> https://github.com/openbmc/phosphor-ipmi-flash/blob/master/docs/flash_update.md#flashmapregionlpc-13
>> to provide information used for the ioctl:
>>
>> bool LpcMapperAspeed::MapWindow(uint32_t *windowOffset, uint32_t *windowSize,
>>         uint32_t address, uint32_t length)
>> {
>>     static const uint32_t MASK_64K = 0xFFFFU;
>>     const uint32_t offset = address & MASK_64K;
>>     if (offset + length > regionSize)
>>     {
>>         fprintf(stderr, "requested window size %" PRIu32 ", offset %#" PRIx32
>>                 " is too large for mem region at %#" PRIXPTR " of size %zu\n",
>>                 length, offset, physAddr, regionSize);
>>         *windowSize = regionSize - offset;
>>         return false;
>>     }
>>     *windowOffset = offset;
>>     *windowSize = length;
>>     struct aspeed_lpc_ctrl_mapping map =
>>     {
>>         .window_type = ASPEED_LPC_CTRL_WINDOW_MEMORY,
>>         .window_id = 0,
>>         .flags = 0,
>>         .addr = address & ~MASK_64K,
>>         .offset = 0,
>>         .size = __ALIGN_KERNEL_MASK(offset + length, MASK_64K),
>>     };
>>     printf("requesting Aspeed LPC window at %#" PRIx32 " of size %" PRIu32 "\n",
>>            map.addr, map.size);
>>     static const char lpcControlPath[] = "/dev/aspeed-lpc-ctrl";
>>     const auto lpcControlFd = open(lpcControlPath, O_RDWR);
>>     if (FileClosed == lpcControlFd)
>>     {
>>         fprintf(stderr, "cannot open Aspeed LPC kernel control dev \"%s\"\n",
>>                 lpcControlPath);
>>         return false;
>>     }
>>     if (ioctl(lpcControlFd, ASPEED_LPC_CTRL_IOCTL_MAP, &map) == -1)
>>     {
>>         fprintf(stderr, "Failed to ioctl Aspeed LPC map with error %s\n",
>>                 strerror(errno));
>>         return false;
>>     }
>>     return true;
>> }
>>
>> The above code is going into phosphor-ipmi-flash once I finish
>> rewriting the IPMI BT interface support.
>
> So, if there is a desire to see the generic blob ipmi interface up --
> I can start upstreaming that.  I can continue phosphor-ipmi-flash for
> a flash-only approach, or I can move that code into the blobs
> interface.  Matt and Vernon have been reviewing that code, which has
> been great as it has great momentum!  The transition to ipmi-blobs
> will be very similar code as far as the handler is concerned, however,
> the ipmi portion, which is what I've nearly finished for
> phosphor-ipmi-flash will be tossed as the blob has its own IPMI
> command details.  I don't mind reworking things, and wanted to also
> draw attention and thanks to Matt and Vernon for reviewing
> phosphor-ipmi-flash.
>

I'm going to convert the current blobs protocol to markdown and send
it for comment.

>>
>>>
>>> Cheers,
>>>
>>> Andrew
>>>
>>> PS: The bits -
>>> Repository: https://github.com/openbmc/mboxbridge
>>> Protocol documentation: https://github.com/openbmc/mboxbridge/blob/master/Documentation/mbox_protocol.md
>>> Implementation notes: https://github.com/openbmc/mboxbridge/blob/master/Documentation/mboxd.md