Thanks Kevin, that makes a lot of sense.
Cheers, Eduardo
On Thursday, 4 April 2024 at 17:21:03 BST, Kevin O'Connor kevin@koconnor.net wrote:
On Thu, Apr 04, 2024 at 04:00:20PM +0000, Eduardo Batalha via SeaBIOS wrote:
Hi,
I had some old files saved in diskettes that I really needed to see, so I bought a floppy drive and installed it in my coreboot based computer, so, no, It's not a retro project. :)
Regarding the AHCI CDROM issues, I really don't know. I did not have problems with it so I did not look at that code at all.
Going back to the floppy configuration issue I think I need to explain my logic a bit better. So... Seabios does not provide us with a fancy interface to configure the floppy drive type. It also does not assume anything. For real hardware, (not qemu,) it is completely dependent on the etc/floppy "file" being present in CBFS. The reason it cannot depend on the cmos value is because when you remove the RTC battery, the CMOS memory gets filled up with random values. coreboot, which runs before seabios has a mechanism to fix this, but ignores the floppy type byte, leaving it with a random value.
My idea below, with my code, is not to use the CMOS value if there are no etc/floppy files but instead to update the cmos value unconditionally whenever etc/floppy files exist. romfile_loadint returns the second argument if the file does not exist, i.e. 0. so the if condition is correct for the logic I explained above.
On a second thought, I now think the condition "if (type0 || type 1)" should not even exist. The best solution is to have the CMOS_FLOPPY_DRIVE_TYPE always updated on every boot. This way, if there are no etc/floppy files in CBFS the value of the byte would be zero, indicating to the operating system that there are no floppy drives installed.
Reading and writing any of the "cmos" settings is problematic. The RTC registers (0x00-0x0f) are a recognized hardware standard, but there isn't a consistent standard for the "nvram" content (nor even how many bytes there are).
As a result, SeaBIOS never accesses any of the "nvram" parts of the "cmos" when in coreboot mode. (It does read some parts when compiled for QEMU, but that was only to support a legacy configuration interface with QEMU which has long been deprecated.)
Writing to the "nvram" is particularly troublesome, as some software requires that any changes to "nvram" content also update a checksum byte (also in "nvram"). There is no consistent standard for the location of that checksum or how it is calculated. So, if one were to change any value in "nvram", it could break any software expecting a particular layout.
As a result, I don't think it would be a good idea for SeaBIOS to start modifying the "nvram" parts of the "cmos". If you have some software that requires it, you might want to consider getting a new battery and programming the nvram with your desired contents. Alternatively, if this is for Linux, I'd guess you could manually instruct Linux to use the floppy (eg, https://docs.kernel.org/admin-guide/blockdev/floppy.html ).
Cheers, -Kevin _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-leave@seabios.org