I tried to Google for this, but apparently it’s a bit too basic.
I know that the firmware is responsible for how the card works (e.g., whether it’s in IT mode or IR mode, seeing connected drives, etc.).
What exactly does the BIOS do? Is it just for the integrated on-boot setup utility (that doesn’t seem to work with UEFI motherboards) and listing of drives? Does it do something else?
I’ve seen that some people delete the BIOS to speed up boot times, but i’m not clear what I’d be losing.
lol no.
I’ll start by saying BIOS is an acronym for basic in out software. BIOS IS firmware. Some of it is just semantics of verbage. You can disable LEGACY BIOS feature in UEFI (UEFI is just newer BIOS/firmware).
The hi light of the vid I posted, is if you clear the bios, you can’t boot from a device connected to it, and drives won’t show up in UEFI/BIOS screen as connected.
Once the OS loads, it will have the drivers for the card, and populate the device tree with drives and stuff.
Yeah, some guides suggest clearing all from the card, then putting the IT mode bin on, and re-labelling with the SAS address.
I am pretty sure I cleard them and just left the SAS off, but I don’t need to boot from the card, so don’t need the bios file, and I don’t need to address by link or whatever, so don’t need the SAS address. I am not sure if some servers require the SAS address for their management to work. #WorksOnMyMachine
@Trooper_ish Thanks for the info and the video link. Very helpful. I’m not planning on booting from the SAS array (it’s going to be TrueNAS storage), but I’ll make sure I leave it set up so I can someday if I need to.
@MarcWWolfe Unfortunately, that BIOS vs Firmware thing appears to be LSI’s actual nomenclature. I’m old enough to remember screwing with BIOS settings on 486/Pentium I machines trying to get Windows 3.1 and 95 working, so yes, I agree that it’s a rather … historically inaccurate.
LSI does actually call it a “BIOS ROM,” so I guess that’s a bit closer to correct. (I think they call it that because if you’re on a system set up in legacy BIOS mode, you can use a key combo to drop into the pre-boot card setup utility. It doesn’t work in UEFI mode, because of course it doesn’t. It’s almost like these cards are old or something.)
At the very least, I need to get both the BIOS and the Firmware on both cards updated to the same version. One of the cards is a bit outdated. I don’t know what the implications of that are, but I’m chasing some odd behavior on boot, so hopefully that might fix it.
I will double check the video later when I have more time, but this sounds like you are actually asking about the card’s PCIe Option ROM, which is separate from the cards firmware.
An Option ROM contains code which is to be executed on the CPU by the BIOS or UEFI (which can be called firmware, but it is the motherboard’s firmware, not the card’s firmware).
A card’s firmware is the code that runs on the computing cores of the card itself.
In most (maybe all) cases, the Option ROM is not necessary if your OS has drivers for the card. This is safer, and is the only way non-x86 architectures like Power (or ARM?) can use PCIe cards primarily marketed for x86 computers, since the Option ROM code would be written for x86. I think this is why IEEE 1275 (OpenFirmware) tried to have device drivers in Forth.
It is the card’s ROM but intended for the server’s BIOS to execute.
Like targeting a different architecture, Option ROM made for BIOS will not be execute on EFI—as far as I know.
Depends. I have an HD6770, requires legacy support; Tesla M40 requires UEFI. My X470 board didn’t let the 2 work simultaneously, until a UEFI update. Like many things, it depends.
And before that update I got lucky with timing of plugging M40’s power in and it worked like it should. Only got that right once before the update.
Hmm, only the HD6770 has display output, so maybe your motherboard UEFI firmware is booting in BIOS-emulation mode (CSM?), and the motherboard update just tells it to ignore other devices completely, so that the OS does the first initialisation?
The alternative is that you are booting in UEFI mode and there is some way to run BIOS device drivers in some form of emulation—I did not think that was feasible; if you learn more, please reply or make a thread and share such knowledge.
I can’t imagine it’s unfeasible to abstract legacy BIOS devices in UEFI. UEFI is basically it’s own opperating system that can be “infinitely” expanded. As far as I understand, it can keep things abstracted, or pass total device control to Windows/Linux etc., or a combination of both… even per device. Like the memory map address can be effectively whatever, but windows gets all the memory to use as it pleases.
I have a server board that has a setting to dictate memory mapped IO limit; goes all the way to 1024 GBs. The address for the actual CPU’s RAM comes after that. Does Windows know if I change the limit between 1GB and 1TB? Not as far as I can tell.
Also should be able to run something in UEFI to ignore the devices self reporting and replace that, without the OS knowing a damn thing… until total control is passed and it requests eeprom data directly, that’s basically why that’s a thing windows does instead of blindly believing what the motherboard/UEFI tells it.
Speaking of, might be how I sort out my new Thunderbolt card. Crowd source from somebody with the same card “properly” setup, who knows enough about UEFI shell to copy what I need, then throw that on a USB drive, and hopefully not have to boot into UEFI shell on every boot to make it work (likely need to change something about PCIe root port or something). Though I remember somebody (probably Wendell) mentioning putting a card in a supported board, changing a setting, and it sticking when swapped to an unsupported board… that might vary by specific card.
