Read Firmware Versions

[Jayashree D]

Classification: HCL Internal


On Thu, Sep 24, 2020 at 9:40 AM Vijay Khemka <vijaykhemka at fb.com> wrote:
>
>
>
> On 9/23/20, 1:19 PM, "openbmc on behalf of Adriana Kobylak" <openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org on behalf of anoo at linux.ibm.com> wrote:
>
>     On 2020-09-23 10:35, Patrick Williams wrote:
>     > On Tue, Sep 22, 2020 at 01:34:50PM +0000, Jayashree D wrote:
>     >> Classification: HCL Internal
>     >>
>     >> Thanks Patrick for your response.
>     >>
>     >> In phosphor-bmc-code-mgmt, I am seeing the software image is upgraded
>     >> and based on the image update, version is updated.
>     >> But in my platform, I have to read firmware versions using oem
>     >> commands and that version should be displayed under dbus objects.
>     >> Whether phosphor-bmc-code-mgmt repo will be suitable to display the
>     >> firmware version using dbus objects?
>     >
>     > Vijay recently added a simple BIOS flash management to
>     > phosphor-bmc-code-mgmt, but there is also a openpower-pnor-code-mgmt
>     > for
>     > the equivalent of BIOS management on openpower systems.  Since your
>     > code
>     > update scheme is likely to be specific to your IPMB commands, I don't
>     > know if that would be best in a separate repository or an extension
>     > onto
>     > phosphor-bmc-code-mgmt.
>     >
>     > Adriana, any opinions?
>
>     It could fit in phosphor-bmc-code-mgmt, some thoughts:
>
>     The d-bus objects get created at 2 different times:
>
>     1. One scenario is when an image is uploaded to be updated, this is the
>     support that Vijay added which allows a custom script to be run to
>     update the BIOS image. If you're interested in this method for updating
>     your BIOS, you could potentially add your IPMB commands in that service
>     and use the Activation interfaces to drive the update.
>
>     2. The second scenario is when the BMC reboots and it recreates the
>     d-bus objects. For this scenario, there's no currently support for BIOS,
>     so for example the support that Vijay added does not create a d-bus
>     interface if the BMC reboots, which is ok if you only want to use the
>     Activation interface to trigger the update. But sounds like you want to
>     always have the version information as a d-bus object, so support for
>     BIOS could be added. For example, to get the BMC levels, the code looks
>     for version information in the BMC in the media directory. If you get
>     your app to get the version information via the oem commands you
>     mentioned and create a file in the bmc in the media directory we could
>     extend the logic to create the Version d-bus objects for each BIOS
>     version when the BMC reboots. We'd just need to work out the details for
>     the format for the files that would host the version information, and
>     how to identify they're BIOS versions vs BMC.
>
> I already create a file after reading bios version via oem commands,
> Is there a pattern where should we keep this file and what is the name
> of file. Also I thought there is a dbus interface for bios management
> already created by some daemon newly added which can keep bios version.
>

>We plan to do something like this:
>1. The BIOS version is stored in an eeprom; 2. On BMC boot, phosphor-bmc-code-mgmt creates the bios object, and fill the version read >from the eeprom; 3. When the host is started, BIOS sends its version via OEM ipmi command; 4. BMC will update and write the version to >the eeprom if the version is different.

I understand that currently there is no separate repo to deal with all the firmware versions (ME, CPLD, VR, Bridge IC, BIOS). Whether any new repo can be created to place all programmable versions in openbmc.
Or is there any way to read all the firmware versions from any other repo using oem commands
Kindly provide your comments on this.

Regards,
Jayashree
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________