Test Firmware Inventory

[justin0309]

1. According to my understanding, the image updated for the first time will be the running image, and the image updated for the second time will be the backup image. Is this correct?
2. My situation is that my image version=none. Is it because my image versison is none, so there won’t be anything in the backup image?
3. I would like to ask how to modify the image version? Thanks

[gkeishin]

@susilsi7 can you respond to this. ?

[susilsi7]

1. When user update first firmware , consider A image then Running Image become A. when user update second firmware that is B, then Running Image become B and Backup Image A.
2. Could be image version=none. but needs to be checked and if backup image is not there either it got deleted or never updated. how you got the firmware with version none ?
3. user not allowed to change image version, it comes with the build.

[justin0309]

@susilsi7 Thank you for your reply.

1. I want to confirm first. Do I need two bmc flashes on the machine to update the backup image? Or can we update two firmwares, one is the running image and the backup image? If so, where will they be stored?

This is the problem I'm currently having, what should I try to resolve it?

My thought is, is it because my image IDs are all the same as 039d44e1, so there will be no backup image? Does this ID need to be changed during the build?

This is the status on my machine

2. So where can I change the version when building?
3. So how does openbmc know the bios version? Because I can't find this path on the machine. cat: can't open '/var/lib/phosphor-software-manager/pnor/ro/pnor.toc': No such file or directory

cat /var/lib/

If we don’t have this phosphor-software-manager, is it because we don’t have support ourselves? Or can we add it ourselves? How should we add it?

Our machine is x86 architecture, does it not support pnor?

by the way, I update the image through scp scp ${IMAGE_REPO}${IMAGE_NAME} root@${OPENBMC_HOST}:/run/initramfs/

[gkeishin]

@justin0309 This is good feedback, we don't have x86 arch system to test for PNOR earlier..

I don't think you need to add any of those.. The test Verify BIOS version is checking Redfish vs any other method ( above via phosphor-software-manager ) to validate the version.

If you have info in x86 how can we check any other path since that phosphor-software-manager is not there in x86, we can amend the code to handle it.

[justin0309]

@gkeishin According to our machine bios x86 architecture, bmc arm architecture two bmc flash

I'm glad to get this helpful information. Do you have any other ideas or solutions regarding the first and second points above?

Based on my research and testing these days, my idea is that because the calculated image IDs are all 039d44e1, they are considered to be the same image, so there is no way to update to the backup image. Is this correct?

[gkeishin]

In the current scheme, firmware updates should allow updating with the same ID as well.

as for the question

1. So where can I change the version when building?

2. so there is no way to update to the backup image. Is this correct?  for PNOR

@anoo1 can give input there.

[justin0309]

@gkeishin @anoo1

For these two questions, I want to ask about the BMC part, or whether the bmc backup image part is also related to PNOR, because I don't know much about PNOR.

[anoo1]

The version field shouldn't be null. This value comes from the /etc/os-release file. You can check the contents of this file from your openbmc build directory tmp/work/<machine>-openbmc-linux-gnueabi/obmc-phosphor-image/1.0-r0/rootfs/etc/os-release. The VERSION field is set to the output of git describe, therefore in order to change the version when building, you can create a git tag with the desired string that you want in the version string, then build an image.

The version id is set to be different for the running and alternate images even if they're the same version. In order to have both displayed, make sure that the backup chip has been flashed using a programmer the same way that the primary chip was originally flashed.

Also in order to support code update for dual static images, make sure that the static-dual-image option is specified for your system: https://github.com/openbmc/openbmc/blob/76ee43cd4c1ff7d1435465e164d2e39a2e8a7336/meta-phosphor/recipes-phosphor/flash/phosphor-software-manager_git.bb#L19

PNOR is a Power-specific concept. For x86, the BIOS can be updated by enabling the flash_bios option on the same phosphor-software-manager recipe file above.

[justin0309]

@anoo1

1.I switched to the flash image of the second chip through uboot alone and confirmed that there was no problem with the second chip booting.

Update the latest situation!!!!

version was successfully changed after I re-added the git tag,but the backup image still has no information.

The current thinking is that the backup image here refers to the same flash that can store multiple images or one flash that stores one image.

If it is the first case that one chip can store two images, then our current chip capacity is 32mb, and the built image is also 32mb. Is it because the capacity is insufficient that the image is deleted and there is no backup image?

If so, is there a chance to solve this problem by replacing the chip with a larger capacity?

2.PACKAGECONFIG[static-dual-image] = "-Dbmc-static-dual-image=enabled, -Dbmc-static-dual-image=disabled"

This line does exist in openbmc/meta-phosphor/recipes-phosphor/flash/phosphor-software-manager_git.bb

[mdmillerii]

The BMC code manager tries to obtain the version by mounting the alternate image and parsing os-release. There is a helper script to mount and unmount the alternate image that may be missing from your system

[anoo1]

Like Milton mentioned, there's a script the mounts the alternate chip (it's a separate chip, not the same chip with 2 images): https://github.com/openbmc/phosphor-bmc-code-mgmt/blob/master/static/obmc-flash-bmc-static-mount-alt.service.in

In order to make this secondary chip visible to the script, need to specify it in the kernel device tree as alt-bmc, example: https://github.com/openbmc/linux/blob/6f8bb353a755ae9f4985b3c084d4d1be62782baf/arch/arm/boot/dts/aspeed-bmc-bytedance-g220a.dts#L263

[justin0309]

@anoo1 Because our flash 0 uses openbmc-flash-layout.dtsi, I tried to use the examples openbmc-flash-layout-64-alt.dtsi and openbmc-flash-layout-64.dtsi you provided to add modifications to flash 1. Because when I compare these two files, the difference is in label, rwfs@2a00000 and rwfs@6000000. Currently, I don’t know how to fill in this value. . At present, I have tried to include openbmc-flash-layout.dtsi in flash 0 and flash 1, and include openbmc-flash-layout-alt.dtsi in flash 1 (the only difference is that the label is replaced with alt- xxx), because I don’t quite know what should be filled in the rwfs@1c00000 of flash 1.

But currently the backup image still doesn’t work.

[mdmillerii]

As you surmised prefixing partitions with alt- is correct and applies to all partitions including rwfs. Remember that when booting on the alternate image (because the watchdog fired) causes the physical chip to the software labels to be swapped. Unless you plan a special recovery firmware with limited functionality your includes should have identical content except for the alt prefix on label names.

This will need to be considered when actually recovering (where you want to update alt ) vs preserving golden (where you update primary active partitions) but this is a future detail to address.

Please clarify still doesn't work. Have you written an image into the alternate device? Was the alternate image mounted?

[justin0309]

@mdmillerii Because flash 1(backup image) is welded to the machine, it cannot be used through the burner. Currently, the method I know can only be used to burn the backup image through uboot. The current method is to burn the first flash into other versions of bmc (not openbmc version), and force it to boot from the second flash (openbmc version) through the command.Booting from the baukup image is no problem. , or is there another way based on the current situation?

Regarding Was the alternate image mounted? What does this probably mean? I have always wanted to know how to upload multiple files. My current approach is mostly to use scp to put image-bmc under run/initramfs/ for updates. And do the reboot action.

At present, when the burning operation is completed, it will be like the situation in my previous post /xyz/openbmc_project/software/xxxxxxx. There will only be the latest one. My understanding is that under normal conditions, there should be multiple images under the software, right?

---

This is the information on my current machine. It seems that the device tree has indeed detected two flashes and MTD patitions. I don’t know what other information needs to be provided to help with this problem?

[justin0309]

@anoo1

https://github.com/openbmc/openbmc/blob/76ee43cd4c1ff7d1435465e164d2e39a2e8a7336/meta-phosphor/recipes-phosphor/flash/phosphor-software-manager_git.bb#L19

Regarding what you said earlier about confirming whether this function is enabled, what I want to ask is that I only confirmed whether this line exists before, but I don’t know how to enable it. I don’t know if it is because this function is not enabled. problems encountered.

Do you mean to pass in parameters when bitbake?

I tried adding /flash/phosphor-software-manager_%.bbappend to our own recipes-phosphor Currently there is only one line EXTRA_OEMESON:append = "-Dbmc-static-dual-image=enabled" But when building, didn't find service unit 'xyz.openbmc_project.Software.Version.service', specified in SYSTEMD_SERVICE:phosphor-software-manager-version will appear.

Another situation would be

Does this have something to do with me working in docker?

[anoo1]

Currently there is only one line EXTRA_OEMESON:append = "-Dbmc-static-dual-image=enabled"

Hi, Try adding the packageconfig to your phosphor-software-manager_%.bbappend file: PACKAGECONFIG:append = " static-dual-image"

[justin0309]

@anoo1 @mdmillerii @gkeishin @susilsi7

It worked, thank you all so much for your help, I hope this information helps others too.

[gkeishin]

Sure thing.. Thanks for the feedback @justin0309

Closing this ticket. Thanks @anoo1 @susilsi7