In a future post, I’ll detail how to build my ported-to-upstream Blackbird firmware. Here though, we’ll explore booting some firmware temporarily to experiment.
Step 1: Copy your new PNOR image over to the BMC.
Step 2: …
Step 3: Profit!
Okay, not really, once you’ve copied over your image, ensure the computer is off and then you can tell the daemon that provides firmware to the host to use a file backend for it rather than the PNOR chip on the motherboard (i.e. yes, you can boot your system even when the firmware chip isn’t there – although I’ve not literally tried this).
root@blackbird:~# mboxctl --backend file:/tmp/blackbird.pnor
SetBackend: Success
root@blackbird:~# obmcutil poweronIf we look at the serial console (ssh to the BMC port 2200) we’ll see Hostboot start, realise there’s newer SBE code, flash it, and reboot:
--== Welcome to Hostboot hostboot-b284071/hbicore.bin ==--
3.02606|secure|SecureROM valid - enabling functionality
5.14678|Booting from SBE side 0 on master proc=00050000
5.18537|ISTEP 6. 5 - host_init_fsi
5.47985|ISTEP 6. 6 - host_set_ipl_parms
5.54476|ISTEP 6. 7 - host_discover_targets
6.56106|HWAS|PRESENT> DIMM[03]=8080000000000000
6.56108|HWAS|PRESENT> Proc[05]=8000000000000000
6.56109|HWAS|PRESENT> Core[07]=1511540000000000
6.61373|ISTEP 6. 8 - host_update_master_tpm
6.61529|SECURE|Security Access Bit> 0x0000000000000000
6.61530|SECURE|Secure Mode Disable (via Jumper)> 0x8000000000000000
6.61543|ISTEP 6. 9 - host_gard
7.20987|HWAS|FUNCTIONAL> DIMM[03]=8080000000000000
7.20988|HWAS|FUNCTIONAL> Proc[05]=8000000000000000
7.20989|HWAS|FUNCTIONAL> Core[07]=1511540000000000
7.21299|ISTEP 6.11 - host_start_occ_xstop_handler
8.28965|ISTEP 6.12 - host_voltage_config
8.47973|ISTEP 7. 1 - mss_attr_cleanup
9.07674|ISTEP 7. 2 - mss_volt
9.35627|ISTEP 7. 3 - mss_freq
9.63029|ISTEP 7. 4 - mss_eff_config
10.35189|ISTEP 7. 5 - mss_attr_update
10.38489|ISTEP 8. 1 - host_slave_sbe_config
10.45332|ISTEP 8. 2 - host_setup_sbe
10.45450|ISTEP 8. 3 - host_cbs_start
10.45574|ISTEP 8. 4 - proc_check_slave_sbe_seeprom_complete
10.48675|ISTEP 8. 5 - host_attnlisten_proc
10.50338|ISTEP 8. 6 - host_p9_fbc_eff_config
10.50771|ISTEP 8. 7 - host_p9_eff_config_links
10.53338|ISTEP 8. 8 - proc_attr_update
10.53634|ISTEP 8. 9 - proc_chiplet_fabric_scominit
10.55234|ISTEP 8.10 - proc_xbus_scominit
10.56202|ISTEP 8.11 - proc_xbus_enable_ridi
10.57788|ISTEP 8.12 - host_set_voltages
10.59421|ISTEP 9. 1 - fabric_erepair
10.65877|ISTEP 9. 2 - fabric_io_dccal
10.66048|ISTEP 9. 3 - fabric_pre_trainadv
10.66665|ISTEP 9. 4 - fabric_io_run_training
10.66860|ISTEP 9. 5 - fabric_post_trainadv
10.67060|ISTEP 9. 6 - proc_smp_link_layer
10.67503|ISTEP 9. 7 - proc_fab_iovalid
11.10386|ISTEP 9. 8 - host_fbc_eff_config_aggregate
11.15103|ISTEP 10. 1 - proc_build_smp
11.27537|ISTEP 10. 2 - host_slave_sbe_update
11.68581|sbe|System Performing SBE Update for PROC 0, side 0
34.50467|sbe|System Rebooting To Complete SBE Update Process
34.50595|IPMI: Initiate power cycle
34.54671|Stopping istep dispatcher
34.68729|IPMI: shutdown complete
One of the improvements is we now get output from the SBE! This means that when we do things like mess up secure boot and non secure boot firmware (I’ll explain why/how this is a thing later), we’ll actually get something useful out of a serial port:
--== Welcome to SBE - CommitId[0x8b06b5c1] ==--
istep 3.19
istep 3.20
istep 3.21
istep 3.22
istep 4.1
istep 4.2
istep 4.3
istep 4.4
istep 4.5
istep 4.6
istep 4.7
istep 4.8
istep 4.9
istep 4.10
istep 4.11
istep 4.12
istep 4.13
istep 4.14
istep 4.15
istep 4.16
istep 4.17
istep 4.18
istep 4.19
istep 4.20
istep 4.21
istep 4.22
istep 4.23
istep 4.24
istep 4.25
istep 4.26
istep 4.27
istep 4.28
istep 4.29
istep 4.30
istep 4.31
istep 4.32
istep 4.33
istep 4.34
istep 5.1
istep 5.2
SBE starting hostbootAnd then we’re back into normal Hostboot boot (which we’ve all seen before) and end up at a newer petitboot!
One notable absence from that screenshot is my installed Fedora is missing. This is because there appears to be a bug in the 5.3.7 kernel that’s currently upstream, and if we drop to the shell and poke at lspci and dmesg, we can work out what could be the culprit:
Exiting petitboot. Type 'exit' to return.
You may run 'pb-sos' to gather diagnostic data
No password set, running as root. You may set a password in the System Configuration screen.
# lspci
0000:00:00.0 PCI bridge: IBM Device 04c1
0001:00:00.0 PCI bridge: IBM Device 04c1
0001:01:00.0 Non-Volatile memory controller: Intel Corporation Device f1a8 (rev 03)
0002:00:00.0 PCI bridge: IBM Device 04c1
0002:01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller (rev 11)
0003:00:00.0 PCI bridge: IBM Device 04c1
0003:01:00.0 USB controller: Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller (rev 02)
0004:00:00.0 PCI bridge: IBM Device 04c1
0004:01:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)
0004:01:00.1 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)
0004:01:00.2 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)
0005:00:00.0 PCI bridge: IBM Device 04c1
0005:01:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge (rev 04)
0005:02:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 41)
# dmesg|grep -i nvme
[ 2.991038] nvme nvme0: pci function 0001:01:00.0
[ 2.991088] nvme 0001:01:00.0: enabling device (0140 -> 0142)
[ 3.121799] nvme nvme0: Identify Controller failed (19)
[ 3.121802] nvme nvme0: Removing after probe failure status: -5
# uname -a
Linux skiroot 5.3.7-openpower1 #2 SMP Sat Dec 14 09:06:20 PST 2019 ppc64le GNU/Linux
If for some reason the device didn’t show up in lspci, then I’d look at the skiboot firmware log, which is /sys/firmware/opal/msglog.
Looking at upstream stable kernel patches, it seems like 5.3.8 has a interesting looking patch when you realize that ppc64le uses a 64k page size:
commit efac0f186ea654e8389f5017c7f643ef48cb4b93
Author: Kevin Hao <haokexin@gmail.com>
Date: Fri Oct 18 10:53:14 2019 +0800
nvme-pci: Set the prp2 correctly when using more than 4k page
commit a4f40484e7f1dff56bb9f286cc59ffa36e0259eb upstream.
In the current code, the nvme is using a fixed 4k PRP entry size,
but if the kernel use a page size which is more than 4k, we should
consider the situation that the bv_offset may be larger than the
dev->ctrl.page_size. Otherwise we may miss setting the prp2 and then
cause the command can't be executed correctly.
Fixes: dff824b2aadb ("nvme-pci: optimize mapping of small single segment requests")
Cc: stable@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>So, time to go try 5.3.8. My yaks are getting quite smooth.
Oh, and when you’re done with your temporary firmware, either fiddle with mboxctl or restart the systemd service for it, or reboot your BMC or… well, I gotta leave you something to work out on your own :)