Unable to update BMC firmware

Hi Nvidia:
We are developing on IGX Orin, porting from IGX OS 0.7 DP to IGX OS 1.0 GA.
The first step is to update BMC firmware, using igx-bmc-apfw-erot.fwpkg from IGX Download center. And yes, we are using board kit, not devkit.

We followed the guide from Here, updated the first IGX Orin successfully.
When it comes to the second IGX Orin, something went wrong. We used the same FW file, the same steps, but the BMC is not updated. We also checked that if the updating task is completed… Yes, the tasks state is complete and Percent Complete is100.
However, the infomation in /etc/os-release remain the same, it’s still old version instead of newer version.

We are very confused since the steps worked before, but not now.
Is there any log can be found to check where the problem is?

Many thanks.

Hi jameskuo,

What’s your current result of /etc/os-release?
Maybe you have updated to the newest one.

How did you know there’s something wrong?

Hi Kevin:
Thanks for the reply.
As mentioned before, I have two igx orins and both of them were running igx 0s 0.7 DP.
The first one , after updating BMC module, the /etc/os-release was changed from GraceBMC-23.05-1-rc1 to IGXOrinBMC-24.04-11-v3.2. Web UI is available, and I can use it to update things like QSPI, etc.

However, the second one, following the same procedure, the /etc/os-realease was not changed. It remains GraceBMC-23.05-1-rc1. That’s why I think something went wrong, and I am trying to figure it out.

Many thanks.

Could you help to share the result of the following command in BMC console of the 2nd board?

$ ls -l /usr/share/mctp
$ i2cdump -f -y 10 0x50

Have you confirmed that both board are exactly the same?

Please also try to run journalctl -f in BMC console when you perform the BMC firmware update and share the log for further check.

Hi Kevin:
Thanks for the support. I tried to catch the log and update the FW again.
However, this time I can update the FW successfully. I tried several times before, non of them succeeded.
I have no idea how/why it did/didn’t work.

BTW, $ i2cdump -f -y 10 0x50 showed QS1, is this a way to check HW version, so we don’t have to scan the sticker on another side of the board?
:

root@mgx-3809:~# i2cdump -f -y 10 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 01 00 00 01 0b 00 00 f3 01 0a 19 04 da dd c6 4e    ?..??..????????N
10: 56 49 44 49 41 c5 50 33 38 30 39 cd 31 36 31 33    VIDIA?P3809?1613
20: 32 32 33 36 32 30 32 34 37 d2 36 39 39 2d 31 33    223620247?699-13
30: 38 30 39 2d 30 31 30 30 2d 51 53 31 c0 01 01 d6    809-0100-QS1????
40: 4d 41 43 3a 20 34 38 3a 42 30 3a 32 44 3a 45 46    MAC: 48:B0:2D:EF
50: 3a 34 43 3a 35 42 c1 44 01 08 19 c6 4e 56 49 44    :4C:5B?D????NVID
60: 49 41 c5 50 33 39 34 30 d2 39 34 30 2d 32 33 39    IA?P3940?940-239
70: 34 30 2d 30 30 30 30 2d 51 53 31 c3 47 2e 31 cd    40-0000-QS1?G.1?
80: 31 36 31 33 32 32 33 36 32 30 32 34 37 c0 c4 76    1613223620247??v
90: 30 2e 32 c1 00 00 00 d3 ff ff ff ff ff ff ff ff    0.2?...?........
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ...............

You can compare the pass/fail log to check the difference.
journalctl -f command could help you to get more logs.

Yes, you can run this command to check the HW version, but please note that the data in EEPROM may be modified by the unexpected writing operation.

1 Like

Hi Kevin,
please allow me to follow-up on / reopen this topic.
I am facing the a very simliar problem as jameskuo, with the difference that it did not resolve after several trials.
We are trying to bring up a IGX Board Kit for the first time and want to upgrade to the latest IGX OS 1.0 GA.

I have followed the latest guide to upgrade the BMC for a IGX Board Kit:
I am able to transfer the BMC Firmware (igx-bmc-apfw-erot.fwpkg) and can confirm that it completed by checking journalctl -f
Afterwards, I reboot/reset gracefully according to step 7 using the API, with the difference that the Manger Member is called “MGX_BMC_0” not “IGX_BMC_0”.
However the firmware is not updated according to

root@mgx-3809:~# cat /etc/os-release 
ID=openbmc-phosphor
NAME="NVIDIA MGX/IGX BMC (OpenBMC     Project Reference Distro)"
VERSION="GraceBMC-23.05-1-rc1"
VERSION_ID=gracebmc-23.05-1-rc1-24-gb5342ba102-dirty.1683610540.578878
PRETTY_NAME="NVIDIA MGX/IGX BMC (OpenBMC     Project Reference Distro) GraceBMC-23.05-1-rc1"
BUILD_ID="20230509053533"
OPENBMC_TARGET_MACHINE="mgx-3809"
BUILD_DESC="dev-platform"

Please find also the results for the following commands:

root@mgx-3809:~# ls -l /usr/share/mctp
-rw-r--r--    1 root     root           410 Apr  5  2011 mctp
root@mgx-3809:~# i2cdump -f -y 10 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 01 00 00 01 0b 00 00 f3 01 0a 19 7d e2 dd c6 4e    ?..??..????}???N
10: 56 49 44 49 41 c5 50 33 38 30 39 cd 31 36 31 33    VIDIA?P3809?1613
20: 32 32 33 36 32 30 35 30 39 d2 36 39 39 2d 31 33    223620509?699-13
30: 38 30 39 2d 30 31 30 30 2d 51 53 31 c0 01 01 d6    809-0100-QS1????
40: 4d 41 43 3a 20 34 38 3a 42 30 3a 32 44 3a 45 46    MAC: 48:B0:2D:EF
50: 3a 34 45 3a 41 31 c1 c5 01 08 19 c6 4e 56 49 44    :4E:A1??????NVID
60: 49 41 c5 50 33 39 34 30 d2 39 34 30 2d 32 33 39    IA?P3940?940-239
70: 34 30 2d 30 30 30 30 2d 51 53 31 c3 47 2e 31 cd    40-0000-QS1?G.1?
80: 31 36 31 33 32 32 33 36 32 30 35 30 39 c0 c4 76    1613223620509??v
90: 30 2e 32 c1 00 00 00 d2 ff ff ff ff ff ff ff ff    0.2?...?........
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................

I am attaching a excerpt of the journalctl log.
IGX_Boardkit_Update_Log.txt (10.5 KB)

I also tried to erase mtd6 and mtd5 between trials, but it also did not help

$flash_eraseall /dev/mtd6
$flash_eraseall /dev/mtd5
$reboot 

Do you have any suggestions on what to try to resolve this issue.

Many thanks in advance,
Daniel

Hi Daosmi:
Seems like you reboot your BMC too early. Did you use API to check if the updating process is 100% finished?
Though journalctl -f looks like the BMC is updated successfully, there might be some tasks are still running.

In Step 6: To check the status of the update run the following command. After the update is done, the task status is completed`, have you confirmed that the update process is running and finished with successful?

Thank you both,

the task completes with 100% “completed” but not “successful

Please find the response for the task:

curl -k      -H "X-Auth-Token:$token"      -X GET https://$bmc/redfish/v1/TaskService/Tasks/0
{
  "@odata.id": "/redfish/v1/TaskService/Tasks/0",
  "@odata.type": "#Task.v1_4_3.Task",
  "EndTime": "1970-01-04T21:38:18+00:00",
  "Id": "0",
  "Messages": [
    {
      "@odata.type": "#Message.v1_0_0.Message",
      "Message": "The task with id 0 has started.",
      "MessageArgs": [
        "0"
      ],
      "MessageId": "TaskEvent.1.0.1.TaskStarted",
      "Resolution": "None.",
      "Severity": "OK"
    },
    {
      "@odata.type": "#MessageRegistry.v1_4_1.MessageRegistry",
      "Message": "Transfer of image '0.0' to '' failed.",
      "MessageArgs": [
        "0.0",
        ""
      ],
      "MessageId": "Update.1.0.TransferFailed",
      "Resolution": "Debug Token Service is not ready, retry the firmware update operation after the management controller is ready. If the issue still persists reset the baseboard.",
      "Severity": "Critical"
    },
    {
      "@odata.type": "#MessageRegistry.v1_4_1.MessageRegistry",
      "Message": "The target device '27' will be updated with image 'GlacierApFwPkg-24042024'.",
      "MessageArgs": [
        "27",
        "GlacierApFwPkg-24042024"
      ],
      "MessageId": "Update.1.0.TargetDetermined",
      "Resolution": "None.",
      "Severity": "OK"
    },
    {
      "@odata.type": "#MessageRegistry.v1_4_1.MessageRegistry",
      "Message": "Image 'GlacierApFwPkg-24042024' is being transferred to '27'.",
      "MessageArgs": [
        "GlacierApFwPkg-24042024",
        "27"
      ],
      "MessageId": "Update.1.0.TransferringToComponent",
      "Resolution": "None.",
      "Severity": "OK"
    },
    {
      "@odata.type": "#Message.v1_0_0.Message",
      "Message": "The task with id 0 has changed to progress 20 percent complete.",
      "MessageArgs": [
        "0",
        "20"
      ],
      "MessageId": "TaskEvent.1.0.1.TaskProgressChanged",
      "Resolution": "None.",
      "Severity": "OK"
    },
    {
      "@odata.type": "#Message.v1_0_0.Message",
      "Message": "The task with id 0 has changed to progress 40 percent complete.",
      "MessageArgs": [
        "0",
        "40"
      ],
      "MessageId": "TaskEvent.1.0.1.TaskProgressChanged",
      "Resolution": "None.",
      "Severity": "OK"
    },
    {
      "@odata.type": "#MessageRegistry.v1_4_1.MessageRegistry",
      "Message": "Device '27' successfully updated with image 'GlacierApFwPkg-24042024'.",
      "MessageArgs": [
        "27",
        "GlacierApFwPkg-24042024"
      ],
      "MessageId": "Update.1.0.UpdateSuccessful",
      "Resolution": "None.",
      "Severity": "OK"
    },
    {
      "@odata.type": "#MessageRegistry.v1_4_1.MessageRegistry",
      "Message": "Awaiting for an action to proceed with activating image 'GlacierApFwPkg-24042024' on '27'.",
      "MessageArgs": [
        "GlacierApFwPkg-24042024",
        "27"
      ],
      "MessageId": "Update.1.0.AwaitToActivate",
      "Resolution": "System reboot or AC power cycle",
      "Severity": "OK"
    },
    {
      "@odata.type": "#Message.v1_0_0.Message",
      "Message": "The task with id 0 has changed to progress 100 percent complete.",
      "MessageArgs": [
        "0",
        "100"
      ],
      "MessageId": "TaskEvent.1.0.1.TaskProgressChanged",
      "Resolution": "None.",
      "Severity": "OK"
    },
    {
      "@odata.type": "#Message.v1_0_0.Message",
      "Message": "The task with id 0 has Completed.",
      "MessageArgs": [
        "0"
      ],
      "MessageId": "TaskEvent.1.0.1.TaskCompletedOK",
      "Resolution": "None.",
      "Severity": "OK"
    }
  ],
  "Name": "Task 0",
  "Payload": {
    "HttpHeaders": [
      "Host: 192.168.1.110",
      "User-Agent: curl/7.81.0",
      "Accept: */*",
      "Content-Length: 67105983"
    ],
    "HttpOperation": "POST",
    "JsonBody": "null",
    "TargetUri": "/redfish/v1/UpdateService"
  },
  "PercentComplete": 100,
  "StartTime": "1970-01-04T21:28:02+00:00",
  "TaskMonitor": "/redfish/v1/TaskService/Tasks/0/Monitor",
  "TaskState": "Completed",
  "TaskStatus": "Critical"

So it states “completed” at the end, but I wonder a bit about the transfer failed message:

 {
      "@odata.type": "#MessageRegistry.v1_4_1.MessageRegistry",
      "Message": "Transfer of image '0.0' to '' failed.",
      "MessageArgs": [
        "0.0",
        ""
      ],
      "MessageId": "Update.1.0.TransferFailed",
      "Resolution": "Debug Token Service is not ready, retry the firmware update operation after the management controller is ready. If the issue still persists reset the baseboard.",
      "Severity": "Critical"
    },

Might this be the source of the problem?

A side note on Step 6 from the BMC-Guide, copy&paste from the command results for me in the following error;

curl -k      -H "X-Auth-Token:$token"      -X GET https://$bmc/redfish/v1/TaskService/Tasks/$task_id
curl: (3) unmatched brace in URL position 52:
https://192.168.1.110/redfish/v1/TaskService/Tasks/{

while the task_id resulted in

$ echo $task_id 
{ "@odata.id": "/redfish/v1/TaskService/Tasks/0", "@odata.type": "#Task.v1_4_3.Task", "Id": "0", "TaskState": "Running", "TaskStatus": "OK" }

hence I queried for Task 0: curl -k -H "X-Auth-Token:$token" -X GET https://$bmc/redfish/v1/TaskService/Tasks/0

Thanks

You can ignore it, No harm to update process.
Could you share the result of the following command in BMC console after you see 100%?

# /usr/bin/mctp-vdm-util $MCTP_RESTART_NOTIFY_OPTS
$ export bmc=<BMC_IP>
$ export token=`curl -k -H "Content-Type: application/json" -X POST https://${bmc}/login -d '{"username" : "root", "password" : "0penBmc"}' | grep token | awk '{print $2;}' | tr -d '"'`
$ curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/octet-stream" -X POST  -T mgx-bmc-apfw.fwpkg https://${bmc}/redfish/v1/UpdateService
$ curl -k -H "X-Auth-Token: $token" -X GET https://${bmc}/redfish/v1/TaskService/Tasks/<TaskID>

Please refer to the above steps to update your board kit.
In your case, <TaskID> is 0.

I tried this command after 100% complete FW transfer - but it does not work/is unknown:

root@mgx-3809:~# /usr/bin/mctp-vdm-util $MCTP_RESTART_NOTIFY_OPTS
Unknown test cmd

Just to double check and confirm that I am using the right FW: In your command,

you are transfering the MGX-bmc-apfw Firmware, however from the IGX-SW1.0 GA, I am using this one: https://developer.nvidia.com/downloads/igx/v1.0.0/bmc_fw_r36.3.1_aarch64.tbz2
which only contains a igx-bmc-apfw-erot.fwpkg ; But I assume according to the latest guide, that this is correct.
Thanks for your support.

Please also try the following commands.

# /usr/bin/mctp-vdm-util -c restart_notification -t 0
# journalctl -u mctp-spi-demux
# journalctl -u mctp-spi-ctrl

Please find the response of the commands below. Note: I have not restarted the BMC since the last update trial i.e. since it showed 100% complete.

root@mgx-3809:~# /usr/bin/mctp-vdm-util -c restart_notification -t 0
Test command = restart_notification
teid = 0
TX: 00 00 16 47 80 01 0A 01 
RX: 00 00 16 47 00 01 0A 01 00 
root@mgx-3809:~# journalctl -u mctp-spi-demux
Jan 06 22:48:55 mgx-3809 systemd[1]: Starting MCTP SPI demultiplexer daemon...
Jan 06 22:49:00 mgx-3809 systemd[1]: Started MCTP SPI demultiplexer daemon.
Jan 06 22:49:21 mgx-3809 mctp-spi-demux[248]: 514161-616 spb-ap: "at spb_ap_recv:547 " "wait_for_length failed."
Jan 06 22:49:21 mgx-3809 mctp-spi-demux[248]: 514161-616 spi: at mctp_spi_rx:426 spb_ap_recv failed:         Timeout

root@mgx-3809:~# journalctl -u mctp-spi-ctrl
Jan 06 22:49:01 mgx-3809 systemd[1]: Started MCTP SPI control daemon                                                                                                                                                      │.
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: main: Run mode: Daemon mode
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: exec_daemon_mode: Binding type: SPI
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: exec_daemon_mode: Start MCTP-over-SPI Discovery
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: -----------------------------------------------
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:    MCTP_GET_EP_UUID_REQUEST
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: -----------------------------------------------
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: MCTP-REQ-HDR >>
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         msg_type         : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         rq_dgram_inst         : 0x80
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         command_code         : 0x3
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: MCTP-REQ-DATA >>
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         --------------<empty>-------------
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: -----------------------------------------------
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_bind_id  >> : 0x6
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_pvt_data >> : 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_req_hdr  >> : 0x0 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_req_msg  >> : 0x0 0x80 0x3
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_prefix_msg: 0x0 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_resp_msg: 0x0 0x0 0x3 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_recv: resp_msg_len: 20, mctp_len: 20
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: -----------------------------------------------
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:    MCTP_GET_EP_UUID_RESPONSE
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: -----------------------------------------------
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: MCTP-RESP-HDR >>
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         msg_type         : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         rq_dgram_inst         : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         command_code         : 0x3
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         comp_code         : 0x0 (SUCCESS)
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: MCTP-RESP-DATA >>
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[0]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[1]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[2]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[3]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[4]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[5]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[6]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[7]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[8]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[9]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[10]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[11]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[12]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[13]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[14]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[15]                 : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: -----------------------------------------------
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_decode_resp_get_uuid: sizeof uuid: 16
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_spi_discover_endpoint: Send Get Msg type Request for EID: 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: -----------------------------------------------
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:    MCTP_GET_MSG_TYPE_REQUEST
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: -----------------------------------------------
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: MCTP-REQ-HDR >>
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         msg_type         : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         rq_dgram_inst         : 0x80
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         command_code         : 0x5
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: MCTP-REQ-DATA >>
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         --------------<empty>-------------
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: -----------------------------------------------
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_get_msg_type_request: Sending EP request
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_bind_id  >> : 0x6
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_pvt_data >> : 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_req_hdr  >> : 0x0 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_req_msg  >> : 0x0 0x80 0x5
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_prefix_msg: 0x0 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_resp_msg: 0x0 0x0 0x5 0x0 0x3 0x1 0x5 0x7f
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_recv: resp_msg_len: 8, mctp_len: 8
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: -----------------------------------------------
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:    MCTP_GET_MSG_TYPE_RESPONSE
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: -----------------------------------------------
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: MCTP-RESP-HDR >>
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         msg_type         : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         rq_dgram_inst         : 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         command_code         : 0x5
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         comp_code         : 0x0 (SUCCESS)
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: MCTP-RESP-DATA >>
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[0]                 : 0x3
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[1]                 : 0x1
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[2]                 : 0x5
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]:         DATA[3]                 : 0x7f
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: -----------------------------------------------
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_get_msg_type_response: EID: 0, Number of supported message types 3
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_spi_discover_endpoint: Completed discovery process..
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: [mctp_spi_keepalive_event] Send 'Boot complete v2' message
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_req_msg >> : 0x0 0x0 0x16 0x47 0x80 0x1 0x2 0x2 0x0 0x0 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_prefix_msg: 0x2 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_resp_msg: 0x7f 0x0 0x0 0x16 0x47 0x0 0x1 0x2 0x2 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_recv: resp_msg_len: 10, mctp_len: 10
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: [mctp_spi_keepalive_event] Send 'Boot complete v2' message
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: main: Initiate dbus
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: Requesting D-Bus name: xyz.openbmc_project.MCTP.Control.SPI
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: Registering object '/xyz/openbmc_project/mctp/0/0' for Endpoint: 0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: Registering object '/xyz/openbmc_project/mctp/0/0' for UUID: 0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: Registering object '/xyz/openbmc_project/mctp/0/0' for UnixSocket: 0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: Registering object '/xyz/openbmc_project/mctp/0/0' for Binding: 0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: Getting D-Bus file descriptors
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_ctrl_sdbus_init: Entering polling loop
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: [mctp_spi_keepalive_event] Send 'Enable Heartbeat' message
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_req_msg >> : 0x0 0x0 0x16 0x47 0x80 0x1 0x4 0x1 0x1
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_prefix_msg: 0x2 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_resp_msg: 0x7f 0x0 0x0 0x16 0x47 0x0 0x1 0x4 0x1 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_recv: resp_msg_len: 10, mctp_len: 10
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: [mctp_spi_keepalive_event] Send 'Heartbeat' message
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_req_msg >> : 0x0 0x0 0x16 0x47 0x80 0x1 0x3 0x1
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_prefix_msg: 0x2 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_resp_msg: 0x7f 0x0 0x0 0x16 0x47 0x0 0x1 0x3 0x1 0x0
Jan 06 22:49:21 mgx-3809 mctp-spi-ctrl[385]: mctp_recv: resp_msg_len: 10, mctp_len: 10
Jan 06 22:49:51 mgx-3809 mctp-spi-ctrl[385]: [mctp_spi_keepalive_event] Send 'Heartbeat' message
Jan 06 22:49:51 mgx-3809 mctp-spi-ctrl[385]: mctp_req_msg >> : 0x0 0x0 0x16 0x47 0x80 0x1 0x3 0x1
Jan 06 22:49:51 mgx-3809 mctp-spi-ctrl[385]: mctp_prefix_msg: 0x2 0x0
Jan 06 22:49:51 mgx-3809 mctp-spi-ctrl[385]: mctp_resp_msg: 0x7f 0x0 0x0 0x16 0x47 0x0 0x1 0x3 0x1 0x0
Jan 06 22:49:51 mgx-3809 mctp-spi-ctrl[385]: mctp_recv: resp_msg_len: 10, mctp_len: 10
Jan 06 22:50:21 mgx-3809 mctp-spi-ctrl[385]: [mctp_spi_keepalive_event] Send 'Heartbeat' message
Jan 06 22:50:21 mgx-3809 mctp-spi-ctrl[385]: mctp_req_msg >> : 0x0 0x0 0x16 0x47 0x80 0x1 0x3 0x1
Jan 06 22:50:21 mgx-3809 mctp-spi-ctrl[385]: mctp_prefix_msg: 0x2 0x0
Jan 06 22:50:21 mgx-3809 mctp-spi-ctrl[385]: mctp_resp_msg: 0x7f 0x0 0x0 0x16 0x47 0x0 0x1 0x3 0x1 0x0
Jan 06 22:50:21 mgx-3809 mctp-spi-ctrl[385]: mctp_recv: resp_msg_len: 10, mctp_len: 10

Could you try to reboot the board manually to check if the firmware has been updated?

Please also refer to the following instruction to update BMC Frimware (igx-bmc-apfw-erot.fwpkg) first and then update IGX BMC ERoT firmware (cec1736-ecfw-rel-prod.fwpkg).
Update your BMC firmware

Since I am working today remotely I was using
ipmitool -C 17 -I lanplus -U <BMC user> -P <BMC Password> -H 192.168.1.110 chassis power off
to power the chassi of; rebooted from the BMC console, and then powered the chassis on again via lanplus; and now I can confirm that it worked!
I am finally on BMC Verison *IGXOrinBMC-24.04-11-v3.2"
I will now continue to update the ERoT firmware, QSPI etc…

Thank you very much, @KevinFFF, for your support.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.