Bottom Line: The Original ZimaBoard May Need Its PCIe Root Port Tuned Before an LSI HBA Appears
The useful result from the real hardware test is specific: an LSI SAS2008-class HBA was not recognized and its option ROM did not load until PCIe settings were changed in the original ZimaBoard BIOS. After adjusting the root port used by the slot, both the HBA firmware and attached disks became visible. Treat those settings as a compatibility workaround for the original board, not a universal recipe for ZimaBoard 2 or every HBA.
Start by Separating Three Different Failure Levels
An HBA can fail at three places: firmware never enumerates the card, Linux sees the PCIe device but the driver does not bind, or the driver loads but no attached disks appear. Check them in that order.
lspci -nn
dmesg | grep -i -E 'mpt|sas|scsi|pcie'
lsblk -o NAME,SIZE,MODEL,TRANThe Linux SCSI subsystem describes the storage-driver layer, while PCI device inspection is the quickest way to prove whether the card exists on PCIe at all.
Apply the Historical BIOS Workaround Only When the Card Is Missing at PCIe Level
On the original ZimaBoard, the tested path was BIOS → Chipset → South Cluster Configuration → PCI Express Configuration. The successful case enabled the relevant PCIe options, then changed PCI Express Root Port 3 to ASPM Auto, PCIe Speed Gen 2 and Transmit Half Swing Enabled. A second owner later confirmed that the same Port 3 changes made an LSI SAS2008 HBA appear.
Record every original value before changing firmware settings. If Port 3 is not the physical path used by your board revision or adapter, blindly changing Ports 4–6 adds variables without proving anything.
HBA Option ROM Is Not Required Just to Use Data Disks
The source case also celebrated that the HBA BIOS finally loaded and could expose attached disks as boot options. That is useful if you want to boot through the HBA, but a storage-only HBA does not necessarily need its option ROM to run. If Linux sees the HBA driver and attached disks, you can use those disks even when you never enter an HBA configuration screen.
This distinction prevents a common dead end: spending hours enabling boot ROM features when the real goal is only to present disks to ZimaOS.
Use HBA or IT Mode When ZimaOS Should See Individual Drives
For software-managed RAID, ZFS or direct disk health monitoring, the operating system should normally see each physical drive. Hardware RAID firmware that hides many disks behind one virtual volume changes SMART visibility and the recovery model. On LSI/Broadcom cards, confirm whether the firmware is operating in a pass-through/HBA-oriented mode appropriate for your storage design before building the array.
Do not flash HBA firmware just because another SAS2008 owner did. Exact controller model, OEM firmware and board revision matter.
Verify Every Disk Before Creating RAID
lsblk -o NAME,SIZE,MODEL,SERIAL
smartctl -a /dev/sdX
cat /proc/mdstatMake sure every attached disk has the expected model and capacity. A missing member, wrong sector size or unstable SAS cable is a separate problem from PCIe enumeration. Never create a new RAID just to test whether the HBA is working if those disks contain data.
Do Not Apply Original ZimaBoard BIOS Values to ZimaBoard 2
ZimaBoard 2 is a different hardware generation. Use its own firmware and PCIe behavior rather than copying South Cluster menu values from a 2024 original-board post. The ZimaBoard 2 hardware is the relevant platform reference. If the real requirement is simply more SATA data ports rather than SAS/HBA features, the PCIe SATA expansion may reduce complexity.
When the HBA Still Does Not Appear
Test the card in another known-good computer, remove unnecessary PCIe devices, update only the correct board/HBA firmware, and capture lspci -nn plus kernel messages. If Linux never sees the PCI function, stay at the firmware/PCIe layer. If PCI sees it but no disks appear, move to driver, HBA firmware, cabling and disk power.
FAQ
Why is my LSI SAS2008 invisible on ZimaBoard?
On some original ZimaBoard systems the PCIe root-port firmware settings prevented the HBA from enumerating correctly. Prove the failure with lspci before changing BIOS values.
Do I need the HBA BIOS screen?
Not for ordinary data-disk use if Linux already detects the controller and disks. The option ROM mainly matters for HBA-side configuration or booting through the controller.
Should an HBA use IT mode?
Pass-through/HBA-oriented firmware is generally easier when ZimaOS, mdadm or ZFS should manage individual disks directly.
Can I use the same BIOS settings on ZimaBoard 2?
Do not assume so. ZimaBoard 2 is different hardware and should use its own firmware behavior and current support information.
Why does lspci see the HBA but lsblk shows no disks?
That moves the problem below PCIe enumeration: check driver binding, HBA firmware mode, SAS/SATA cables, expanders, drive power and attached-disk compatibility.
