Re: [PATCH v3 1/1] hw/arm/aspeed:Add vpd data for Rainier machine
Hello Cedric, On 5/26/23 1:18 AM, Cédric Le Goater wrote: On 5/25/23 21:57, Ninad Palsule wrote: Hello Cedric, On 5/25/23 1:37 AM, Cédric Le Goater wrote: [ ... ] However, regarding Cédric's log above, a reboot is expected on the first boot of a fresh image when there's valid VPD available. For the first boot of a fresh image we configure the kernel with a minimal devicetree that allows us to read the VPD data. This determines the system we're actually on and configures an appropriate devicetree for subsequent boots. We then reboot to pick up the new devicetree. Yes. Then, the behavior looks correct under QEMU : https://www.kaod.org/qemu/aspeed/rainier/rainer.log Here are the services which still have with some issues : * clear-once.service loaded failed failed Clear one time boot overrides * ncsi-linkspeed@eth0.service loaded failed failed Set eth0 gigabit link speed * ncsi-linkspeed@eth1.service loaded failed failed Set eth1 gigabit link speed * obmc-flash-bios-init.service loaded failed failed Setup Host FW directories * system-vpd.service loaded failed failed System VPD Collection * trace-enable.service loaded failed failed Enable Linux trace events in the boot loader On my system system-vpd.service was active. I couldn't run your build on my development machine. That's how I run it : qemu-system-arm -M rainier-bmc -net user -drive file=./mmc-p10bmc.qcow2,format=qcow2,if=sd,id=sd2,index=2 -nographic -snapshot -serial mon:stdio You will need to use my branch to have emmc support. ok, Thanks you! Thanks, C.
Re: [PATCH v3 1/1] hw/arm/aspeed:Add vpd data for Rainier machine
On 5/25/23 21:57, Ninad Palsule wrote: Hello Cedric, On 5/25/23 1:37 AM, Cédric Le Goater wrote: [ ... ] However, regarding Cédric's log above, a reboot is expected on the first boot of a fresh image when there's valid VPD available. For the first boot of a fresh image we configure the kernel with a minimal devicetree that allows us to read the VPD data. This determines the system we're actually on and configures an appropriate devicetree for subsequent boots. We then reboot to pick up the new devicetree. Yes. Then, the behavior looks correct under QEMU : https://www.kaod.org/qemu/aspeed/rainier/rainer.log Here are the services which still have with some issues : * clear-once.service loaded failed failed Clear one time boot overrides * ncsi-linkspeed@eth0.service loaded failed failed Set eth0 gigabit link speed * ncsi-linkspeed@eth1.service loaded failed failed Set eth1 gigabit link speed * obmc-flash-bios-init.service loaded failed failed Setup Host FW directories * system-vpd.service loaded failed failed System VPD Collection * trace-enable.service loaded failed failed Enable Linux trace events in the boot loader On my system system-vpd.service was active. I couldn't run your build on my development machine. That's how I run it : qemu-system-arm -M rainier-bmc -net user -drive file=./mmc-p10bmc.qcow2,format=qcow2,if=sd,id=sd2,index=2 -nographic -snapshot -serial mon:stdio You will need to use my branch to have emmc support. Thanks, C.
Re: [PATCH v3 1/1] hw/arm/aspeed:Add vpd data for Rainier machine
Hello Cedric, On 5/25/23 1:37 AM, Cédric Le Goater wrote: [ ... ] However, regarding Cédric's log above, a reboot is expected on the first boot of a fresh image when there's valid VPD available. For the first boot of a fresh image we configure the kernel with a minimal devicetree that allows us to read the VPD data. This determines the system we're actually on and configures an appropriate devicetree for subsequent boots. We then reboot to pick up the new devicetree. Yes. Then, the behavior looks correct under QEMU : https://www.kaod.org/qemu/aspeed/rainier/rainer.log Here are the services which still have with some issues : * clear-once.service loaded failed failed Clear one time boot overrides * ncsi-linkspeed@eth0.service loaded failed failed Set eth0 gigabit link speed * ncsi-linkspeed@eth1.service loaded failed failed Set eth1 gigabit link speed * obmc-flash-bios-init.service loaded failed failed Setup Host FW directories * system-vpd.service loaded failed failed System VPD Collection * trace-enable.service loaded failed failed Enable Linux trace events in the boot loader On my system system-vpd.service was active. I couldn't run your build on my development machine. I am still checking it. C.
Re: [PATCH v3 1/1] hw/arm/aspeed:Add vpd data for Rainier machine
[ ... ] However, regarding Cédric's log above, a reboot is expected on the first boot of a fresh image when there's valid VPD available. For the first boot of a fresh image we configure the kernel with a minimal devicetree that allows us to read the VPD data. This determines the system we're actually on and configures an appropriate devicetree for subsequent boots. We then reboot to pick up the new devicetree. Yes. Then, the behavior looks correct under QEMU : https://www.kaod.org/qemu/aspeed/rainier/rainer.log Here are the services which still have with some issues : * clear-once.serviceloaded failed failed Clear one time boot overrides * ncsi-linkspeed@eth0.service loaded failed failed Set eth0 gigabit link speed * ncsi-linkspeed@eth1.service loaded failed failed Set eth1 gigabit link speed * obmc-flash-bios-init.service loaded failed failed Setup Host FW directories * system-vpd.serviceloaded failed failed System VPD Collection * trace-enable.service loaded failed failed Enable Linux trace events in the boot loader C.
Re: [PATCH v3 1/1] hw/arm/aspeed:Add vpd data for Rainier machine
Hello Cedric, On 5/24/23 1:36 AM, Cédric Le Goater wrote: On 5/23/23 23:45, Ninad Palsule wrote: The current modeling of Rainier machine creates zero filled VPDs(EEPROMs). This makes some services and applications unhappy and causing them to fail. Hence this drop adds some fabricated data for system and BMC FRU so that vpd services are happy and active. Tested: - The system-vpd.service is active. - VPD service related to bmc is active. Signed-off-by: Ninad Palsule You can keep the R-b tag when you resend, unless there are a lot of changes. Yes, Sure. Sorry about that. Reviewed-by: Cédric Le Goater Since I am curious, I started a rainier machine under QEMU and ran some commands : root@p10bmc:~# hexdump -C /sys/bus/i2c/devices/i2c-8/8-0050/eeprom 00 00 00 00 00 00 00 00 00 00 00 84 28 00 52 54 |(.RT| 0010 04 56 48 44 52 56 44 02 01 00 50 54 0e 56 54 4f |.VHDRVD...PT.VTO| 0020 43 00 00 37 00 4a 00 00 00 00 00 50 46 08 00 00 |C..7.J.PF...| 0030 00 00 00 00 00 00 00 00 46 00 52 54 04 56 54 4f |F.RT.VTO| 0040 43 50 54 38 56 49 4e 49 00 00 81 00 3a 00 00 00 |CPT8VINI:...| 0050 00 00 56 53 59 53 00 00 bb 00 27 00 00 00 00 00 |..VSYS'.| 0060 56 43 45 4e 00 00 e2 00 27 00 00 00 00 00 56 53 |VCEN'.VS| 0070 42 50 00 00 09 01 19 00 00 00 00 00 50 46 01 00 |BP..PF..| 0080 00 00 36 00 52 54 04 56 49 4e 49 44 52 04 44 45 |..6.RT.VINIDR.DE| 0090 53 43 48 57 02 30 31 43 43 04 33 34 35 36 46 4e |SCHW.01CC.3456FN| 00a0 04 46 52 34 39 53 4e 04 53 52 31 32 50 4e 04 50 |.FR49SN.SR12PN.P| 00b0 52 39 39 50 46 04 00 00 00 00 00 00 23 00 52 54 |R99PF...#.RT| 00c0 04 56 53 59 53 53 45 07 49 42 4d 53 59 53 31 54 |.VSYSSE.IBMSYS1T| 00d0 4d 08 32 32 32 32 2d 32 32 32 50 46 04 00 00 00 |M.-222PF| 00e0 00 00 00 23 00 52 54 04 56 43 45 4e 53 45 07 31 |...#.RT.VCENSE.1| 00f0 32 33 34 35 36 37 46 43 08 31 31 31 31 2d 31 31 |234567FC.-11| 0100 31 50 46 04 00 00 00 00 00 00 15 00 52 54 04 56 |1PF.RT.V| 0110 53 42 50 49 4d 04 50 00 10 01 50 46 04 00 00 00 |SBPIM.P...PF| 0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 2000 root@p10bmc:~# hexdump -C /sys/bus/i2c/devices/i2c-8/8-0051/eeprom 00 00 00 00 00 00 00 00 00 00 00 84 28 00 52 54 |(.RT| 0010 04 56 48 44 52 56 44 02 01 00 50 54 0e 56 54 4f |.VHDRVD...PT.VTO| 0020 43 00 00 37 00 20 00 00 00 00 00 50 46 08 00 00 |C..7. .PF...| 0030 00 00 00 00 00 00 00 00 1c 00 52 54 04 56 54 4f |..RT.VTO| 0040 43 50 54 0e 56 49 4e 49 00 00 57 00 1e 00 00 00 |CPT.VINI..W.| 0050 00 00 50 46 01 00 00 00 1a 00 52 54 04 56 49 4e |..PF..RT.VIN| 0060 49 44 52 04 44 45 53 43 48 57 02 30 31 50 46 04 |IDR.DESCHW.01PF.| 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || and root@p10bmc:~# systemctl status com.ibm.VPD.Manager.service -l * com.ibm.VPD.Manager.service - IBM VPD Manager Loaded: loaded (/lib/systemd/system/com.ibm.VPD.Manager.service; enabled; preset: enabled) Active: active (running) since Wed 2023-05-24 06:26:34 UTC; 1min 28s ago Main PID: 2784 (vpd-manager) CPU: 101ms CGroup: /system.slice/com.ibm.VPD.Manager.service `-2784 /usr/bin/vpd-manager Thank you for checking. But, I also got this : root@p10bmc:~# [ 91.656331] watchdog: watchdog0: watchdog did not stop! [ 91.734858] systemd-shutdown[1]: Using hardware watchdog 'aspeed_wdt', version 0, device /dev/watchdog0 [ 91.735766] systemd-shutdown[1]: Watchdog running with a timeout of 1min. [ 91.987363] systemd-shutdown[1]: Syncing filesystems and block devices. [ 93.471897] systemd-shutdown[1]: Sending SIGTERM to remaining processes... This is a different issue. I am also hitting it without my changes. and the machine rebooted. Joel had the same problem : https://github.com/openbmc/qemu/issues/39 Is it unrelated ? I haven't started a rainier in 2 years at least so I can not tell. Thanks, C. --- hw/arm/aspeed.c | 6 -- hw/arm/aspeed_eeprom.c | 45 +- hw/arm/aspeed_eeprom.h | 5 + 3 files changed, 53 insertions(+), 3 deletions(-) diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c index 0b29028fe1..bfc2070bd2 100644 --- a/hw/arm/aspeed.c +++ b/hw/arm/aspeed.c @@ -788,8 +788,10 @@ static void rainier_bmc_i2c_init(AspeedMachineState *bmc) 0x48); i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 8), TYPE_TMP105, 0x4a); - at24c_eeprom_init(aspeed_i2c_get_bus(>i2c, 8), 0x50, 64 * KiB); - at24c_eeprom_init(aspeed_i2c_get_bus(>i2c, 8), 0x51, 64 * KiB); +
Re: [PATCH v3 1/1] hw/arm/aspeed:Add vpd data for Rainier machine
On Wed, 24 May 2023, at 17:14, Joel Stanley wrote: > On Wed, 24 May 2023 at 06:38, Cédric Le Goater wrote: >> >> But, I also got this : >> >>root@p10bmc:~# [ 91.656331] watchdog: watchdog0: watchdog did not stop! >>[ 91.734858] systemd-shutdown[1]: Using hardware watchdog 'aspeed_wdt', >> version 0, device /dev/watchdog0 >>[ 91.735766] systemd-shutdown[1]: Watchdog running with a timeout of >> 1min. >>[ 91.987363] systemd-shutdown[1]: Syncing filesystems and block devices. >>[ 93.471897] systemd-shutdown[1]: Sending SIGTERM to remaining >> processes... >> >> and the machine rebooted. >> >> Joel had the same problem : >> >>https://github.com/openbmc/qemu/issues/39 >> >> Is it unrelated ? I haven't started a rainier in 2 years at least so I can >> not tell. > > I don't think it's related to Ninad's patches. > > I am able to reproduce the issue on my old Skylake x86 machine, but it > doesn't happen on my M1 mac mini. > > I suspect the emulation is moving too slowly, but the host's wall > clock is still ticking, so all of a sudden the BMC finds out that time > has passed an the watchdog bites. I could be wrong. Yeah, I also suspect this is occurring. In some cases we see output like: ``` [ 295.474921] hrtimer: interrupt took 411679950 ns Watchdog timer 0 expired. ``` This suggests that we've exhausted the three iterations of the hrtimer callback list from the hrtimer interrupt[1]. Too much stuff happening for the time-keeping we have. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/time/hrtimer.c?h=v6.3#n1869 However, regarding Cédric's log above, a reboot is expected on the first boot of a fresh image when there's valid VPD available. For the first boot of a fresh image we configure the kernel with a minimal devicetree that allows us to read the VPD data. This determines the system we're actually on and configures an appropriate devicetree for subsequent boots. We then reboot to pick up the new devicetree. The devicetree to use is stored in the u-boot environment (in `fitconfig`). Andrew
Re: [PATCH v3 1/1] hw/arm/aspeed:Add vpd data for Rainier machine
On 5/24/23 09:44, Joel Stanley wrote:
On Wed, 24 May 2023 at 06:38, Cédric Le Goater wrote:
On 5/23/23 23:45, Ninad Palsule wrote:
The current modeling of Rainier machine creates zero filled VPDs(EEPROMs).
This makes some services and applications unhappy and causing them to fail.
Hence this drop adds some fabricated data for system and BMC FRU so that
vpd services are happy and active.
Tested:
- The system-vpd.service is active.
- VPD service related to bmc is active.
Signed-off-by: Ninad Palsule
You can keep the R-b tag when you resend, unless there are a lot of changes.
Reviewed-by: Cédric Le Goater
Since I am curious, I started a rainier machine under QEMU and ran some
commands :
root@p10bmc:~# hexdump -C /sys/bus/i2c/devices/i2c-8/8-0050/eeprom
00 00 00 00 00 00 00 00 00 00 00 84 28 00 52 54
|(.RT|
0010 04 56 48 44 52 56 44 02 01 00 50 54 0e 56 54 4f
|.VHDRVD...PT.VTO|
0020 43 00 00 37 00 4a 00 00 00 00 00 50 46 08 00 00
|C..7.J.PF...|
0030 00 00 00 00 00 00 00 00 46 00 52 54 04 56 54 4f
|F.RT.VTO|
0040 43 50 54 38 56 49 4e 49 00 00 81 00 3a 00 00 00
|CPT8VINI:...|
0050 00 00 56 53 59 53 00 00 bb 00 27 00 00 00 00 00
|..VSYS'.|
0060 56 43 45 4e 00 00 e2 00 27 00 00 00 00 00 56 53
|VCEN'.VS|
0070 42 50 00 00 09 01 19 00 00 00 00 00 50 46 01 00
|BP..PF..|
0080 00 00 36 00 52 54 04 56 49 4e 49 44 52 04 44 45
|..6.RT.VINIDR.DE|
0090 53 43 48 57 02 30 31 43 43 04 33 34 35 36 46 4e
|SCHW.01CC.3456FN|
00a0 04 46 52 34 39 53 4e 04 53 52 31 32 50 4e 04 50
|.FR49SN.SR12PN.P|
00b0 52 39 39 50 46 04 00 00 00 00 00 00 23 00 52 54
|R99PF...#.RT|
00c0 04 56 53 59 53 53 45 07 49 42 4d 53 59 53 31 54
|.VSYSSE.IBMSYS1T|
00d0 4d 08 32 32 32 32 2d 32 32 32 50 46 04 00 00 00
|M.-222PF|
00e0 00 00 00 23 00 52 54 04 56 43 45 4e 53 45 07 31
|...#.RT.VCENSE.1|
00f0 32 33 34 35 36 37 46 43 08 31 31 31 31 2d 31 31
|234567FC.-11|
0100 31 50 46 04 00 00 00 00 00 00 15 00 52 54 04 56
|1PF.RT.V|
0110 53 42 50 49 4d 04 50 00 10 01 50 46 04 00 00 00
|SBPIM.P...PF|
0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
||
*
2000
root@p10bmc:~# hexdump -C /sys/bus/i2c/devices/i2c-8/8-0051/eeprom
00 00 00 00 00 00 00 00 00 00 00 84 28 00 52 54
|(.RT|
0010 04 56 48 44 52 56 44 02 01 00 50 54 0e 56 54 4f
|.VHDRVD...PT.VTO|
0020 43 00 00 37 00 20 00 00 00 00 00 50 46 08 00 00 |C..7.
.PF...|
0030 00 00 00 00 00 00 00 00 1c 00 52 54 04 56 54 4f
|..RT.VTO|
0040 43 50 54 0e 56 49 4e 49 00 00 57 00 1e 00 00 00
|CPT.VINI..W.|
0050 00 00 50 46 01 00 00 00 1a 00 52 54 04 56 49 4e
|..PF..RT.VIN|
0060 49 44 52 04 44 45 53 43 48 57 02 30 31 50 46 04
|IDR.DESCHW.01PF.|
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
||
and
root@p10bmc:~# systemctl status com.ibm.VPD.Manager.service -l
* com.ibm.VPD.Manager.service - IBM VPD Manager
Loaded: loaded (/lib/systemd/system/com.ibm.VPD.Manager.service;
enabled; preset: enabled)
Active: active (running) since Wed 2023-05-24 06:26:34 UTC; 1min 28s
ago
Main PID: 2784 (vpd-manager)
CPU: 101ms
CGroup: /system.slice/com.ibm.VPD.Manager.service
`-2784 /usr/bin/vpd-manager
When it works we should be able to do things like this, I'm told:
vpd-tool -r -O /system/chassis/motherboard -R VSYS -K TM
{
"/system/chassis/motherboard": {
"TM": "-222"
}
}
But, I also got this :
root@p10bmc:~# [ 91.656331] watchdog: watchdog0: watchdog did not stop!
[ 91.734858] systemd-shutdown[1]: Using hardware watchdog 'aspeed_wdt',
version 0, device /dev/watchdog0
[ 91.735766] systemd-shutdown[1]: Watchdog running with a timeout of 1min.
[ 91.987363] systemd-shutdown[1]: Syncing filesystems and block devices.
[ 93.471897] systemd-shutdown[1]: Sending SIGTERM to remaining
processes...
and the machine rebooted.
Joel had the same problem :
https://github.com/openbmc/qemu/issues/39
Is it unrelated ? I haven't started a rainier in 2 years at least so I can
not tell.
I don't think it's related to Ninad's patches.
I am able to reproduce the issue on my old Skylake x86 machine, but it
doesn't happen on my M1 mac mini.
I saw it on a Ryzen Threadripper PRO 5955WX.
I suspect the emulation is moving too slowly, but the host's wall
clock is still ticking, so all of a sudden the BMC finds out that time
has passed an the watchdog bites. I could be wrong.
The rainier firmware crashes all over the place due to missing
hardware. These crashes cause applications to core dump due to
Re: [PATCH v3 1/1] hw/arm/aspeed:Add vpd data for Rainier machine
On Wed, 24 May 2023 at 06:38, Cédric Le Goater wrote:
>
> On 5/23/23 23:45, Ninad Palsule wrote:
> > The current modeling of Rainier machine creates zero filled VPDs(EEPROMs).
> > This makes some services and applications unhappy and causing them to fail.
> > Hence this drop adds some fabricated data for system and BMC FRU so that
> > vpd services are happy and active.
> >
> > Tested:
> > - The system-vpd.service is active.
> > - VPD service related to bmc is active.
> >
> > Signed-off-by: Ninad Palsule
>
> You can keep the R-b tag when you resend, unless there are a lot of changes.
>
> Reviewed-by: Cédric Le Goater
>
> Since I am curious, I started a rainier machine under QEMU and ran some
> commands :
>
>root@p10bmc:~# hexdump -C /sys/bus/i2c/devices/i2c-8/8-0050/eeprom
> 00 00 00 00 00 00 00 00 00 00 00 84 28 00 52 54
> |(.RT|
>0010 04 56 48 44 52 56 44 02 01 00 50 54 0e 56 54 4f
> |.VHDRVD...PT.VTO|
>0020 43 00 00 37 00 4a 00 00 00 00 00 50 46 08 00 00
> |C..7.J.PF...|
>0030 00 00 00 00 00 00 00 00 46 00 52 54 04 56 54 4f
> |F.RT.VTO|
>0040 43 50 54 38 56 49 4e 49 00 00 81 00 3a 00 00 00
> |CPT8VINI:...|
>0050 00 00 56 53 59 53 00 00 bb 00 27 00 00 00 00 00
> |..VSYS'.|
>0060 56 43 45 4e 00 00 e2 00 27 00 00 00 00 00 56 53
> |VCEN'.VS|
>0070 42 50 00 00 09 01 19 00 00 00 00 00 50 46 01 00
> |BP..PF..|
>0080 00 00 36 00 52 54 04 56 49 4e 49 44 52 04 44 45
> |..6.RT.VINIDR.DE|
>0090 53 43 48 57 02 30 31 43 43 04 33 34 35 36 46 4e
> |SCHW.01CC.3456FN|
>00a0 04 46 52 34 39 53 4e 04 53 52 31 32 50 4e 04 50
> |.FR49SN.SR12PN.P|
>00b0 52 39 39 50 46 04 00 00 00 00 00 00 23 00 52 54
> |R99PF...#.RT|
>00c0 04 56 53 59 53 53 45 07 49 42 4d 53 59 53 31 54
> |.VSYSSE.IBMSYS1T|
>00d0 4d 08 32 32 32 32 2d 32 32 32 50 46 04 00 00 00
> |M.-222PF|
>00e0 00 00 00 23 00 52 54 04 56 43 45 4e 53 45 07 31
> |...#.RT.VCENSE.1|
>00f0 32 33 34 35 36 37 46 43 08 31 31 31 31 2d 31 31
> |234567FC.-11|
>0100 31 50 46 04 00 00 00 00 00 00 15 00 52 54 04 56
> |1PF.RT.V|
>0110 53 42 50 49 4d 04 50 00 10 01 50 46 04 00 00 00
> |SBPIM.P...PF|
>0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ||
>*
>2000
>root@p10bmc:~# hexdump -C /sys/bus/i2c/devices/i2c-8/8-0051/eeprom
> 00 00 00 00 00 00 00 00 00 00 00 84 28 00 52 54
> |(.RT|
>0010 04 56 48 44 52 56 44 02 01 00 50 54 0e 56 54 4f
> |.VHDRVD...PT.VTO|
>0020 43 00 00 37 00 20 00 00 00 00 00 50 46 08 00 00 |C..7.
> .PF...|
>0030 00 00 00 00 00 00 00 00 1c 00 52 54 04 56 54 4f
> |..RT.VTO|
>0040 43 50 54 0e 56 49 4e 49 00 00 57 00 1e 00 00 00
> |CPT.VINI..W.|
>0050 00 00 50 46 01 00 00 00 1a 00 52 54 04 56 49 4e
> |..PF..RT.VIN|
>0060 49 44 52 04 44 45 53 43 48 57 02 30 31 50 46 04
> |IDR.DESCHW.01PF.|
>0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ||
>
> and
>
>root@p10bmc:~# systemctl status com.ibm.VPD.Manager.service -l
>* com.ibm.VPD.Manager.service - IBM VPD Manager
> Loaded: loaded (/lib/systemd/system/com.ibm.VPD.Manager.service;
> enabled; preset: enabled)
> Active: active (running) since Wed 2023-05-24 06:26:34 UTC; 1min 28s
> ago
> Main PID: 2784 (vpd-manager)
>CPU: 101ms
> CGroup: /system.slice/com.ibm.VPD.Manager.service
> `-2784 /usr/bin/vpd-manager
When it works we should be able to do things like this, I'm told:
vpd-tool -r -O /system/chassis/motherboard -R VSYS -K TM
{
"/system/chassis/motherboard": {
"TM": "-222"
}
}
>
> But, I also got this :
>
>root@p10bmc:~# [ 91.656331] watchdog: watchdog0: watchdog did not stop!
>[ 91.734858] systemd-shutdown[1]: Using hardware watchdog 'aspeed_wdt',
> version 0, device /dev/watchdog0
>[ 91.735766] systemd-shutdown[1]: Watchdog running with a timeout of
> 1min.
>[ 91.987363] systemd-shutdown[1]: Syncing filesystems and block devices.
>[ 93.471897] systemd-shutdown[1]: Sending SIGTERM to remaining
> processes...
>
> and the machine rebooted.
>
> Joel had the same problem :
>
>https://github.com/openbmc/qemu/issues/39
>
> Is it unrelated ? I haven't started a rainier in 2 years at least so I can
> not tell.
I don't think it's related to Ninad's patches.
I am able to reproduce the issue on my old Skylake x86 machine, but it
doesn't happen on my M1 mac mini.
I suspect the emulation is moving too slowly, but the host's wall
clock is still ticking, so all of a sudden the BMC finds out that time
has passed an the watchdog bites. I could be wrong.
The rainier firmware crashes all over the place
Re: [PATCH v3 1/1] hw/arm/aspeed:Add vpd data for Rainier machine
On 5/23/23 23:45, Ninad Palsule wrote:
The current modeling of Rainier machine creates zero filled VPDs(EEPROMs).
This makes some services and applications unhappy and causing them to fail.
Hence this drop adds some fabricated data for system and BMC FRU so that
vpd services are happy and active.
Tested:
- The system-vpd.service is active.
- VPD service related to bmc is active.
Signed-off-by: Ninad Palsule
You can keep the R-b tag when you resend, unless there are a lot of changes.
Reviewed-by: Cédric Le Goater
Since I am curious, I started a rainier machine under QEMU and ran some
commands :
root@p10bmc:~# hexdump -C /sys/bus/i2c/devices/i2c-8/8-0050/eeprom
00 00 00 00 00 00 00 00 00 00 00 84 28 00 52 54 |(.RT|
0010 04 56 48 44 52 56 44 02 01 00 50 54 0e 56 54 4f |.VHDRVD...PT.VTO|
0020 43 00 00 37 00 4a 00 00 00 00 00 50 46 08 00 00 |C..7.J.PF...|
0030 00 00 00 00 00 00 00 00 46 00 52 54 04 56 54 4f |F.RT.VTO|
0040 43 50 54 38 56 49 4e 49 00 00 81 00 3a 00 00 00 |CPT8VINI:...|
0050 00 00 56 53 59 53 00 00 bb 00 27 00 00 00 00 00 |..VSYS'.|
0060 56 43 45 4e 00 00 e2 00 27 00 00 00 00 00 56 53 |VCEN'.VS|
0070 42 50 00 00 09 01 19 00 00 00 00 00 50 46 01 00 |BP..PF..|
0080 00 00 36 00 52 54 04 56 49 4e 49 44 52 04 44 45 |..6.RT.VINIDR.DE|
0090 53 43 48 57 02 30 31 43 43 04 33 34 35 36 46 4e |SCHW.01CC.3456FN|
00a0 04 46 52 34 39 53 4e 04 53 52 31 32 50 4e 04 50 |.FR49SN.SR12PN.P|
00b0 52 39 39 50 46 04 00 00 00 00 00 00 23 00 52 54 |R99PF...#.RT|
00c0 04 56 53 59 53 53 45 07 49 42 4d 53 59 53 31 54 |.VSYSSE.IBMSYS1T|
00d0 4d 08 32 32 32 32 2d 32 32 32 50 46 04 00 00 00 |M.-222PF|
00e0 00 00 00 23 00 52 54 04 56 43 45 4e 53 45 07 31 |...#.RT.VCENSE.1|
00f0 32 33 34 35 36 37 46 43 08 31 31 31 31 2d 31 31 |234567FC.-11|
0100 31 50 46 04 00 00 00 00 00 00 15 00 52 54 04 56 |1PF.RT.V|
0110 53 42 50 49 4d 04 50 00 10 01 50 46 04 00 00 00 |SBPIM.P...PF|
0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
2000
root@p10bmc:~# hexdump -C /sys/bus/i2c/devices/i2c-8/8-0051/eeprom
00 00 00 00 00 00 00 00 00 00 00 84 28 00 52 54 |(.RT|
0010 04 56 48 44 52 56 44 02 01 00 50 54 0e 56 54 4f |.VHDRVD...PT.VTO|
0020 43 00 00 37 00 20 00 00 00 00 00 50 46 08 00 00 |C..7. .PF...|
0030 00 00 00 00 00 00 00 00 1c 00 52 54 04 56 54 4f |..RT.VTO|
0040 43 50 54 0e 56 49 4e 49 00 00 57 00 1e 00 00 00 |CPT.VINI..W.|
0050 00 00 50 46 01 00 00 00 1a 00 52 54 04 56 49 4e |..PF..RT.VIN|
0060 49 44 52 04 44 45 53 43 48 57 02 30 31 50 46 04 |IDR.DESCHW.01PF.|
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
and
root@p10bmc:~# systemctl status com.ibm.VPD.Manager.service -l
* com.ibm.VPD.Manager.service - IBM VPD Manager
Loaded: loaded (/lib/systemd/system/com.ibm.VPD.Manager.service;
enabled; preset: enabled)
Active: active (running) since Wed 2023-05-24 06:26:34 UTC; 1min 28s ago
Main PID: 2784 (vpd-manager)
CPU: 101ms
CGroup: /system.slice/com.ibm.VPD.Manager.service
`-2784 /usr/bin/vpd-manager
But, I also got this :
root@p10bmc:~# [ 91.656331] watchdog: watchdog0: watchdog did not stop!
[ 91.734858] systemd-shutdown[1]: Using hardware watchdog 'aspeed_wdt',
version 0, device /dev/watchdog0
[ 91.735766] systemd-shutdown[1]: Watchdog running with a timeout of 1min.
[ 91.987363] systemd-shutdown[1]: Syncing filesystems and block devices.
[ 93.471897] systemd-shutdown[1]: Sending SIGTERM to remaining processes...
and the machine rebooted.
Joel had the same problem :
https://github.com/openbmc/qemu/issues/39
Is it unrelated ? I haven't started a rainier in 2 years at least so I can
not tell.
Thanks,
C.
---
hw/arm/aspeed.c| 6 --
hw/arm/aspeed_eeprom.c | 45 +-
hw/arm/aspeed_eeprom.h | 5 +
3 files changed, 53 insertions(+), 3 deletions(-)
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 0b29028fe1..bfc2070bd2 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -788,8 +788,10 @@ static void rainier_bmc_i2c_init(AspeedMachineState *bmc)
0x48);
i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 8), TYPE_TMP105,
0x4a);
-at24c_eeprom_init(aspeed_i2c_get_bus(>i2c, 8), 0x50, 64 * KiB);
-at24c_eeprom_init(aspeed_i2c_get_bus(>i2c, 8), 0x51, 64 * KiB);
+at24c_eeprom_init_rom(aspeed_i2c_get_bus(>i2c, 8), 0x50,
+ 64 * KiB, rainier_bb_fruid, rainier_bb_fruid_len);
+at24c_eeprom_init_rom(aspeed_i2c_get_bus(>i2c, 8), 0x51,
+ 64 *
[PATCH v3 1/1] hw/arm/aspeed:Add vpd data for Rainier machine
The current modeling of Rainier machine creates zero filled VPDs(EEPROMs).
This makes some services and applications unhappy and causing them to fail.
Hence this drop adds some fabricated data for system and BMC FRU so that
vpd services are happy and active.
Tested:
- The system-vpd.service is active.
- VPD service related to bmc is active.
Signed-off-by: Ninad Palsule
---
hw/arm/aspeed.c| 6 --
hw/arm/aspeed_eeprom.c | 45 +-
hw/arm/aspeed_eeprom.h | 5 +
3 files changed, 53 insertions(+), 3 deletions(-)
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 0b29028fe1..bfc2070bd2 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -788,8 +788,10 @@ static void rainier_bmc_i2c_init(AspeedMachineState *bmc)
0x48);
i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 8), TYPE_TMP105,
0x4a);
-at24c_eeprom_init(aspeed_i2c_get_bus(>i2c, 8), 0x50, 64 * KiB);
-at24c_eeprom_init(aspeed_i2c_get_bus(>i2c, 8), 0x51, 64 * KiB);
+at24c_eeprom_init_rom(aspeed_i2c_get_bus(>i2c, 8), 0x50,
+ 64 * KiB, rainier_bb_fruid, rainier_bb_fruid_len);
+at24c_eeprom_init_rom(aspeed_i2c_get_bus(>i2c, 8), 0x51,
+ 64 * KiB, rainier_bmc_fruid, rainier_bmc_fruid_len);
create_pca9552(soc, 8, 0x60);
create_pca9552(soc, 8, 0x61);
/* Bus 8: ucd90320@11 */
diff --git a/hw/arm/aspeed_eeprom.c b/hw/arm/aspeed_eeprom.c
index dc33a88a54..ace5266cec 100644
--- a/hw/arm/aspeed_eeprom.c
+++ b/hw/arm/aspeed_eeprom.c
@@ -119,9 +119,52 @@ const uint8_t yosemitev2_bmc_fruid[] = {
0x6e, 0x66, 0x69, 0x67, 0x20, 0x41, 0xc1, 0x45,
};
+const uint8_t rainier_bb_fruid[] = {
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x84,
+0x28, 0x00, 0x52, 0x54, 0x04, 0x56, 0x48, 0x44, 0x52, 0x56, 0x44, 0x02,
+0x01, 0x00, 0x50, 0x54, 0x0e, 0x56, 0x54, 0x4f, 0x43, 0x00, 0x00, 0x37,
+0x00, 0x4a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x50, 0x46, 0x08, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46, 0x00, 0x52, 0x54,
+0x04, 0x56, 0x54, 0x4f, 0x43, 0x50, 0x54, 0x38, 0x56, 0x49, 0x4e, 0x49,
+0x00, 0x00, 0x81, 0x00, 0x3a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x56, 0x53,
+0x59, 0x53, 0x00, 0x00, 0xbb, 0x00, 0x27, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x56, 0x43, 0x45, 0x4e, 0x00, 0x00, 0xe2, 0x00, 0x27, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x56, 0x53, 0x42, 0x50, 0x00, 0x00, 0x09, 0x01, 0x19, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x50, 0x46, 0x01, 0x00, 0x00, 0x00, 0x36, 0x00,
+0x52, 0x54, 0x04, 0x56, 0x49, 0x4e, 0x49, 0x44, 0x52, 0x04, 0x44, 0x45,
+0x53, 0x43, 0x48, 0x57, 0x02, 0x30, 0x31, 0x43, 0x43, 0x04, 0x33, 0x34,
+0x35, 0x36, 0x46, 0x4e, 0x04, 0x46, 0x52, 0x34, 0x39, 0x53, 0x4e, 0x04,
+0x53, 0x52, 0x31, 0x32, 0x50, 0x4e, 0x04, 0x50, 0x52, 0x39, 0x39, 0x50,
+0x46, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x23, 0x00, 0x52, 0x54,
+0x04, 0x56, 0x53, 0x59, 0x53, 0x53, 0x45, 0x07, 0x49, 0x42, 0x4d, 0x53,
+0x59, 0x53, 0x31, 0x54, 0x4d, 0x08, 0x32, 0x32, 0x32, 0x32, 0x2d, 0x32,
+0x32, 0x32, 0x50, 0x46, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x23,
+0x00, 0x52, 0x54, 0x04, 0x56, 0x43, 0x45, 0x4e, 0x53, 0x45, 0x07, 0x31,
+0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x46, 0x43, 0x08, 0x31, 0x31, 0x31,
+0x31, 0x2d, 0x31, 0x31, 0x31, 0x50, 0x46, 0x04, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x15, 0x00, 0x52, 0x54, 0x04, 0x56, 0x53, 0x42, 0x50, 0x49,
+0x4d, 0x04, 0x50, 0x00, 0x10, 0x01, 0x50, 0x46, 0x04, 0x00, 0x00, 0x00,
+0x00, 0x00,
+};
+
+/* Rainier BMC FRU */
+const uint8_t rainier_bmc_fruid[] = {
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x84,
+0x28, 0x00, 0x52, 0x54, 0x04, 0x56, 0x48, 0x44, 0x52, 0x56, 0x44, 0x02,
+0x01, 0x00, 0x50, 0x54, 0x0e, 0x56, 0x54, 0x4f, 0x43, 0x00, 0x00, 0x37,
+0x00, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x50, 0x46, 0x08, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1c, 0x00, 0x52, 0x54,
+0x04, 0x56, 0x54, 0x4f, 0x43, 0x50, 0x54, 0x0e, 0x56, 0x49, 0x4e, 0x49,
+0x00, 0x00, 0x57, 0x00, 0x1e, 0x00, 0x00, 0x00, 0x00, 0x00, 0x50, 0x46,
+0x01, 0x00, 0x00, 0x00, 0x1a, 0x00, 0x52, 0x54, 0x04, 0x56, 0x49, 0x4e,
+0x49, 0x44, 0x52, 0x04, 0x44, 0x45, 0x53, 0x43, 0x48, 0x57, 0x02, 0x30,
+0x31, 0x50, 0x46, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00,
+};
+
const size_t tiogapass_bmc_fruid_len = sizeof(tiogapass_bmc_fruid);
const size_t fby35_nic_fruid_len = sizeof(fby35_nic_fruid);
const size_t fby35_bb_fruid_len = sizeof(fby35_bb_fruid);
const size_t fby35_bmc_fruid_len = sizeof(fby35_bmc_fruid);
-
const size_t yosemitev2_bmc_fruid_len = sizeof(yosemitev2_bmc_fruid);
+const size_t rainier_bb_fruid_len = sizeof(rainier_bb_fruid);
+const size_t rainier_bmc_fruid_len = sizeof(rainier_bmc_fruid);
diff --git a/hw/arm/aspeed_eeprom.h b/hw/arm/aspeed_eeprom.h
index 86db6f0479..bbf9e54365 100644
---
