{"id":4522,"date":"2019-12-14T10:20:45","date_gmt":"2019-12-14T18:20:45","guid":{"rendered":"https:\/\/www.flamingspork.com\/blog\/?p=4522"},"modified":"2019-12-14T10:21:52","modified_gmt":"2019-12-14T18:21:52","slug":"booting-temporary-firmware-on-the-raptor-blackbird","status":"publish","type":"post","link":"https:\/\/www.flamingspork.com\/blog\/2019\/12\/14\/booting-temporary-firmware-on-the-raptor-blackbird\/","title":{"rendered":"Booting temporary firmware on the Raptor Blackbird"},"content":{"rendered":"\n
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.<\/p>\n\n\n\n
Step 1: Copy your new PNOR image over to the BMC. Step 2: … Step 3: Profit!<\/p>\n\n\n\n
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<\/strong> – although I’ve not literally tried this).<\/p>\n\n\n\n
If 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:<\/p>\n\n\n\n
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:<\/p>\n\n\n\n
And then we’re back into normal Hostboot boot (which we’ve all seen before) and end up at a newer petitboot!<\/p>\n\n\n\nPetitboot 1.11 on a Raptor Blackbird<\/figcaption><\/figure>\n\n\n\n
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:<\/p>\n\n\n\n
Exiting petitboot. Type 'exit' to return.\nYou may run 'pb-sos' to gather diagnostic data\nNo password set, running as root. You may set a password in the System Configuration screen.\n# lspci\n0000:00:00.0 PCI bridge: IBM Device 04c1\n0001:00:00.0 PCI bridge: IBM Device 04c1\n0001:01:00.0 Non-Volatile memory controller: Intel Corporation Device f1a8 (rev 03)\n0002:00:00.0 PCI bridge: IBM Device 04c1\n0002:01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb\/s Controller (rev 11)\n0003:00:00.0 PCI bridge: IBM Device 04c1\n0003:01:00.0 USB controller: Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller (rev 02)\n0004:00:00.0 PCI bridge: IBM Device 04c1\n0004:01:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)\n0004:01:00.1 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)\n0004:01:00.2 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)\n0005:00:00.0 PCI bridge: IBM Device 04c1\n0005:01:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge (rev 04)\n0005:02:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 41)\n# dmesg|grep -i nvme\n[ 2.991038] nvme nvme0: pci function 0001:01:00.0\n[ 2.991088] nvme 0001:01:00.0: enabling device (0140 -> 0142)\n[ 3.121799] nvme nvme0: Identify Controller failed (19)\n[ 3.121802] nvme nvme0: Removing after probe failure status: -5\n# uname -a\nLinux skiroot 5.3.7-openpower1 #2 SMP Sat Dec 14 09:06:20 PST 2019 ppc64le GNU\/Linux\n<\/code><\/pre>\n\n\n\n
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.<\/p>\n\n\n\n
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:<\/p>\n\n\n\n
commit efac0f186ea654e8389f5017c7f643ef48cb4b93\nAuthor: Kevin Hao <haokexin@gmail.com>\nDate: Fri Oct 18 10:53:14 2019 +0800\n\n nvme-pci: Set the prp2 correctly when using more than 4k page\n \n commit a4f40484e7f1dff56bb9f286cc59ffa36e0259eb upstream.\n \n In the current code, the nvme is using a fixed 4k PRP entry size,\n but if the kernel use a page size which is more than 4k, we should\n consider the situation that the bv_offset may be larger than the\n dev->ctrl.page_size. Otherwise we may miss setting the prp2 and then\n cause the command can't be executed correctly.\n \n Fixes: dff824b2aadb (\"nvme-pci: optimize mapping of small single segment requests\")\n Cc: stable@vger.kernel.org\n Reviewed-by: Christoph Hellwig <hch@lst.de>\n Signed-off-by: Kevin Hao <haokexin@gmail.com>\n Signed-off-by: Keith Busch <kbusch@kernel.org>\n Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org><\/code><\/pre>\n\n\n\n
So, time to go try 5.3.8. My yaks are getting quite smooth.<\/p>\n\n\n\n
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 :)<\/p>\n","protected":false},"excerpt":{"rendered":"
![\"\"](\"https:\/\/i0.wp.com\/www.flamingspork.com\/blog\/wp-content\/uploads\/2019\/12\/Screenshot-from-2019-12-14-09-59-38.png?resize=584%2C396&ssl=1\")