Thanks Kevin, that makes a lot of sense.
Cheers,
Eduardo
On Thursday, 4 April 2024 at 17:21:03 BST, Kevin O'Connor
<ke...@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-le...@seabios.org
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
