Floppy drive configuration

[Eduardo Batalha]

Hi all,

I own an ASUS P5Q and had the same problem that Petr Cvek mentioned in his previous emails.
I was configuring the floppy type using the the etc/floppy0 value in cbfs but took me quite a while to figure out that why linux was not showing it.
I haven't tested it myself yet, but I think the solution to the floppy configuration issue may be to continue using etc/floppyX and change these lines in floppy.c from

} else {
        u8 type = romfile_loadint("etc/floppy0", 0);
        if (type)
            addFloppy(0, type);
        type = romfile_loadint("etc/floppy1", 0);
        if (type)
            addFloppy(1, type);
    }

to

} else {
        u8 type0 = romfile_loadint("etc/floppy0", 0);
        if (type0) 
            addFloppy(0, type);
        u8 type1 = romfile_loadint("etc/floppy1", 0);
        if (type1) 
            addFloppy(1, type1);
        if (type0 || type 1)
           rtc_write(CMOS_FLOPPY_DRIVE_TYPE, type0 <<4 | type1);
    }

Quoting from osdev.org :
"The first 14 CMOS registers access and control the Real-Time Clock. In fact, the only truly useful registers remaining in CMOS are the Real-Time Clock registers, and register 0x10. All other registers in CMOS are almost entirely obsolete (or are not standardized), and are therefore useless. "
So, register 0x10, the floppy drive type, is, conversely, pretty much standardised...

Hope this makes sense...

Cheers,
Ed

[Petr Cvek]

And I agree ;-)

it worked on Kontron 986LCD, but I don't have time to play with it (and I upgraded to a ryzen board). But actually I'm planing to use all semi-standard CMOS addresses for legacy/retro boards.

BTW does a boot from SATA CD/DVD works for you with seabios? (native IDE CD/DVD on PATA is in question too)

Petr

Dne 02. 04. 24 v 2:59 Eduardo Batalha via SeaBIOS napsal(a):
> Hi all,
>
> I own an ASUS P5Q and had the same problem that Petr Cvek mentioned in his previous emails.
> I was configuring the floppy type using the the etc/floppy0 value in cbfs but took me quite a while to figure out that why linux was not showing it.
> I haven't tested it myself yet, but I think the solution to the floppy configuration issue may be to continue using etc/floppyX and change these lines in floppy.c from
> } else {
>     u8 type = romfile_loadint("etc/floppy0", 0);
>     if (type)
>         addFloppy(0, type);
>     type = romfile_loadint("etc/floppy1", 0);
>     if (type)
>         addFloppy(1, type);
> }
>
> to
> } else {
>     u8 type0 = romfile_loadint("etc/floppy0", 0);
>     if (type0) 
>         addFloppy(0, type);
>     u8 type1 = romfile_loadint("etc/floppy1", 0);
>     if (type1) 
>         addFloppy(1, type1);
>     if (type0 || type 1)
>        rtc_write(CMOS_FLOPPY_DRIVE_TYPE, type0 <<4 | type1);
> }
>
> Quoting from osdev.org :
> "The first 14 CMOS registers access and control the Real-Time Clock. In fact, the only truly useful registers remaining in CMOS are the Real-Time Clock registers, and register 0x10. All other registers in CMOS are almost entirely obsolete (or are not standardized), and are therefore useless. "
> So, register 0x10, the floppy drive type, is, conversely, pretty much standardised...
>
> Hope this makes sense...
>
> Cheers,
> Ed
> _______________________________________________
> SeaBIOS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Eduardo Batalha]

Hi,

Yes, booting from a SATA DVD drive with the controller configured as AHCI worked fine for me.

Cheers,
Ed

On Tuesday, 2 April 2024 at 02:19:42 BST, Petr Cvek  wrote:

And I agree ;-)

it worked on Kontron 986LCD, but I don't have time to play with it (and I upgraded to a ryzen board). But actually I'm planing to use all semi-standard CMOS addresses for legacy/retro boards.

BTW does a boot from SATA CD/DVD works for you with seabios? (native IDE CD/DVD on PATA is in question too)

Petr

Dne 02. 04. 24 v 2:59 Eduardo Batalha via SeaBIOS napsal(a):
> Hi all,
>
> I own an ASUS P5Q and had the same problem that Petr Cvek mentioned in his previous emails.
> I was configuring the floppy type using the the etc/floppy0 value in cbfs but took me quite a while to figure out that why linux was not showing it.
> I haven't tested it myself yet, but I think the solution to the floppy configuration issue may be to continue using etc/floppyX and change these lines in floppy.c from
>
> } else {
>         u8 type = romfile_loadint("etc/floppy0", 0);
>         if (type)
>             addFloppy(0, type);
>         type = romfile_loadint("etc/floppy1", 0);
>         if (type)
>             addFloppy(1, type);
>     }
>
> to
>
> } else {
>         u8 type0 = romfile_loadint("etc/floppy0", 0);
>         if (type0) 
>             addFloppy(0, type);
>         u8 type1 = romfile_loadint("etc/floppy1", 0);
>         if (type1) 
>             addFloppy(1, type1);
>         if (type0 || type 1)
>             rtc_write(CMOS_FLOPPY_DRIVE_TYPE, type0 <<4 | type1);
>     }
>
> Quoting from osdev.org :
> "The first 14 CMOS registers access and control the Real-Time Clock. In fact, the only truly useful registers remaining in CMOS are the Real-Time Clock registers, and register 0x10. All other registers in CMOS are almost entirely obsolete (or are not standardized), and are therefore useless. "
> So, register 0x10, the floppy drive type, is, conversely, pretty much standardised...
>
> Hope this makes sense...
>
> Cheers,
> Ed
> _______________________________________________
> SeaBIOS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

_______________________________________________
SeaBIOS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

[Petr Cvek]

Thanks for info,

So I guess yours ICH10 AHCI controller can probably withstand an NULL pointer access in hardware. Unlike my ICH7, which had problems with the same situation, as described here:

https://www.mail-archive.com/[e-mail]/msg12950.html
> >    if (type0 || type 1)
> >        rtc_write(CMOS_FLOPPY_DRIVE_TYPE, type0 <<4 | type1);

Oh BTW I was looking how/if the code meanwhile changed and I think it should be:

if (!type0 || !type 1)
    	rtc_write(CMOS_FLOPPY_DRIVE_TYPE, type0 <<4 | type1);

or something as in "if none romfile_loadint() set type, use CMOS values".

But on the other hand, if CMOS load is allowed even on a real hardware, then the entire "if (CONFIG_QEMU) .. else ..." block can be optimized out.

BTW^2 I completely forgot to ask. What are you trying to use the floppy for, some retro project?

Best regards,
Petr

Dne 03. 04. 24 v 0:45 Eduardo Batalha napsal(a):
> Hi,
>
> Yes, booting from a SATA DVD drive with the controller configured as AHCI worked fine for me.
>
> Cheers,
> Ed
>
> On Tuesday, 2 April 2024 at 02:19:42 BST, Petr Cvek  wrote:
>
> And I agree ;-)
>
> it worked on Kontron 986LCD, but I don't have time to play with it (and I upgraded to a ryzen board). But actually I'm planing to use all semi-standard CMOS addresses for legacy/retro boards.
>
> BTW does a boot from SATA CD/DVD works for you with seabios? (native IDE CD/DVD on PATA is in question too)
>
> Petr
>
> Dne 02. 04. 24 v 2:59 Eduardo Batalha via SeaBIOS napsal(a):
> > Hi all,
> >
> > I own an ASUS P5Q and had the same problem that Petr Cvek mentioned in his previous emails.
> > I was configuring the floppy type using the the etc/floppy0 value in cbfs but took me quite a while to figure out that why linux was not showing it.
> > I haven't tested it myself yet, but I think the solution to the floppy configuration issue may be to continue using etc/floppyX and change these lines in floppy.c from
> >
> > } else {
> >         u8 type = romfile_loadint("etc/floppy0", 0);
> >         if (type)
> >             addFloppy(0, type);
> >         type = romfile_loadint("etc/floppy1", 0);
> >         if (type)
> >             addFloppy(1, type);
> >     }
> >
> > to
> >
> > } else {
> >         u8 type0 = romfile_loadint("etc/floppy0", 0);
> >         if (type0)
> >             addFloppy(0, type);
> >         u8 type1 = romfile_loadint("etc/floppy1", 0);
> >         if (type1)
> >             addFloppy(1, type1);
> >         if (type0 || type 1)
> >             rtc_write(CMOS_FLOPPY_DRIVE_TYPE, type0 <<4 | type1);
> >     }
> >
> > Quoting from osdev.org :
> > "The first 14 CMOS registers access and control the Real-Time Clock. In fact, the only truly useful registers remaining in CMOS are the Real-Time Clock registers, and register 0x10. All other registers in CMOS are almost entirely obsolete (or are not standardized), and are therefore useless. "
> > So, register 0x10, the floppy drive type, is, conversely, pretty much standardised...
> >
> > Hope this makes sense...
> >
> > Cheers,
> > Ed
> > _______________________________________________
> > SeaBIOS mailing list -- [e-mail] 
> > To unsubscribe send an email to [e-mail]
>
> SeaBIOS mailing list -- [e-mail] 
> To unsubscribe send an email to [e-mail]

[Eduardo Batalha]

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.

Cheers,
Ed

On Wednesday, 3 April 2024 at 03:58:40 BST, Petr Cvek  wrote:

Thanks for info,

So I guess yours ICH10 AHCI controller can probably withstand an NULL pointer access in hardware. Unlike my ICH7, which had problems with the same situation, as described here:

https://www.mail-archive.com/[e-mail]/msg12950.html
> > if (type0 || type 1)
> >             rtc_write(CMOS_FLOPPY_DRIVE_TYPE, type0 <<4 | type1);

Oh BTW I was looking how/if the code meanwhile changed and I think it should be:

if (!type0 || !type 1)
        rtc_write(CMOS_FLOPPY_DRIVE_TYPE, type0 <<4 | type1);

or something as in "if none romfile_loadint() set type, use CMOS values".

But on the other hand, if CMOS load is allowed even on a real hardware, then the entire "if (CONFIG_QEMU) .. else ..." block can be optimized out.

BTW^2 I completely forgot to ask. What are you trying to use the floppy for, some retro project?

Best regards,
Petr

Dne 03. 04. 24 v 0:45 Eduardo Batalha napsal(a):
> Hi,
>
> Yes, booting from a SATA DVD drive with the controller configured as AHCI worked fine for me.
>
> Cheers,
> Ed
>
> On Tuesday, 2 April 2024 at 02:19:42 BST, Petr Cvek  wrote:
>
> And I agree ;-)
>
> it worked on Kontron 986LCD, but I don't have time to play with it (and I upgraded to a ryzen board). But actually I'm planing to use all semi-standard CMOS addresses for legacy/retro boards.
>
> BTW does a boot from SATA CD/DVD works for you with seabios? (native IDE CD/DVD on PATA is in question too)
>
> Petr
>
> Dne 02. 04. 24 v 2:59 Eduardo Batalha via SeaBIOS napsal(a):
> > Hi all,
> >
> > I own an ASUS P5Q and had the same problem that Petr Cvek mentioned in his previous emails.
> > I was configuring the floppy type using the the etc/floppy0 value in cbfs but took me quite a while to figure out that why linux was not showing it.
> > I haven't tested it myself yet, but I think the solution to the floppy configuration issue may be to continue using etc/floppyX and change these lines in floppy.c from
> >
> > } else {
> >         u8 type = romfile_loadint("etc/floppy0", 0);
> >         if (type)
> >             addFloppy(0, type);
> >         type = romfile_loadint("etc/floppy1", 0);
> >         if (type)
> >             addFloppy(1, type);
> >     }
> >
> > to
> >
> > } else {
> >         u8 type0 = romfile_loadint("etc/floppy0", 0);
> >         if (type0)
> >             addFloppy(0, type);
> >         u8 type1 = romfile_loadint("etc/floppy1", 0);
> >         if (type1)
> >             addFloppy(1, type1);
> >         if (type0 || type 1)
> >             rtc_write(CMOS_FLOPPY_DRIVE_TYPE, type0 <<4 | type1);
> >     }
> >
> > Quoting from osdev.org :
> > "The first 14 CMOS registers access and control the Real-Time Clock. In fact, the only truly useful registers remaining in CMOS are the Real-Time Clock registers, and register 0x10. All other registers in CMOS are almost entirely obsolete (or are not standardized), and are therefore useless. "
> > So, register 0x10, the floppy drive type, is, conversely, pretty much standardised...
> >
> > Hope this makes sense...
> >
> > Cheers,
> > Ed
> > _______________________________________________
> > SeaBIOS mailing list -- [e-mail] 
> > To unsubscribe send an email to [e-mail]
>
> SeaBIOS mailing list -- [e-mail] 
> To unsubscribe send an email to [e-mail]

_______________________________________________
SeaBIOS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

[Kevin O'Connor]

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

[Eduardo Batalha]

Thanks Kevin, that makes a lot of sense.

Cheers,
Eduardo

On Thursday, 4 April 2024 at 17:21:03 BST, Kevin O'Connor  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 -- [e-mail]
To unsubscribe send an email to [e-mail]

[Eduardo Batalha]

Hi Petr,

Given the comments from Kevin, I have reverted my seabios floppy.c file 
to what it was before my changes.
Seabios is not the right place to configure the CMOS_FLOPPY_DRIVE_TYPE 
in the rtc, I think that role is probably better for coreboot itself.
So, just for completeness sake, even if it's a bit out of scope for this 
mailing list, here is what I did:
I changed the coreboot cmos.layout and cmos.default files for my Asus 
P5Q board like this
cmos.layout -
"
.
.
.
entries

# -----------------------------------------------------------------
0    120    r    0    reserved_memory

# -----------------------------------------------------------------
# FLOPPY
132    4    e    3    floppyA
128    4    e    3    floppyB

# -----------------------------------------------------------------
# RTC_BOOT_BYTE (coreboot hardcoded)
384    1    e    4    boot_option
388    4    h    0    reboot_counter
.
.
.
.

enumerations

#ID    value    text
1    0    Disable
1    1    Enable
2    0    Enable
2    1    Disable
3    0    None
3    1    360KB
3    2    1.2MB
3    3    720KB
3    4    1.44MB
3    5    2.88MB
3    6    160KB
3    7    180KB
3    8    320KB
4    0    Fallback
4    1    Normal
6    0    Emergency
6    1    Alert
.
.
.
"

cmos.default -
"
boot_option=Fallback
floppyA=None
floppyB=None
debug_level=Debug
power_on_after_fail=Disable
nmi=Enable
sata_mode=AHCI
"

This way, the floppy type for both Drives A and B can be configured in 
the secondary payload nvramcui.

The cbmem log shows
"[WARN ]  RTC: Checksum invalid"
but that does not seem to cause any problems in the few tests I did so far.

This is a hack that works for my specific case and may work on other 
boards with a floppy interface. It needs a lot more testing...

Regards,
Ed

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.
>
> Cheers,
> Ed
>
> On Wednesday, 3 April 2024 at 03:58:40 BST, Petr Cvek 
>  wrote:
>
> Thanks for info,
>
> So I guess yours ICH10 AHCI controller can probably withstand an NULL 
> pointer access in hardware. Unlike my ICH7, which had problems with 
> the same situation, as described here:
>
> https://www.mail-archive.com/[e-mail]/msg12950.html
> > > if (type0 || type 1)
> > >             rtc_write(CMOS_FLOPPY_DRIVE_TYPE, type0 <<4 | type1);
>
> Oh BTW I was looking how/if the code meanwhile changed and I think it 
> should be:
>
> if (!type0 || !type 1)
>         rtc_write(CMOS_FLOPPY_DRIVE_TYPE, type0 <<4 | type1);
>
> or something as in "if none romfile_loadint() set type, use CMOS values".
>
> But on the other hand, if CMOS load is allowed even on a real 
> hardware, then the entire "if (CONFIG_QEMU) .. else ..." block can be 
> optimized out.
>
> BTW^2 I completely forgot to ask. What are you trying to use the 
> floppy for, some retro project?
>
> Best regards,
> Petr
>
> Dne 03. 04. 24 v 0:45 Eduardo Batalha napsal(a):
> > Hi,
> >
> > Yes, booting from a SATA DVD drive with the controller configured as
>
> AHCI worked fine for me.
> > Cheers,
> > Ed
> >
> > On Tuesday, 2 April 2024 at 02:19:42 BST, Petr Cvek
>
> <[e-mail] > wrote:
> > And I agree ;-)
> >
> > it worked on Kontron 986LCD, but I don't have time to play with it
>
> (and I upgraded to a ryzen board). But actually I'm planing to use all 
> semi-standard CMOS addresses for legacy/retro boards.
> > BTW does a boot from SATA CD/DVD works for you with seabios? (native
>
> IDE CD/DVD on PATA is in question too)
> > Petr
> >
> > Dne 02. 04. 24 v 2:59 Eduardo Batalha via SeaBIOS napsal(a):
> > > Hi all,
> > >
> > > I own an ASUS P5Q and had the same problem that Petr Cvek mentioned
>
> in his previous emails.
> > > I was configuring the floppy type using the the etc/floppy0 value
>
> in cbfs but took me quite a while to figure out that why linux was not 
> showing it.
> > > I haven't tested it myself yet, but I think the solution to the
>
> floppy configuration issue may be to continue using etc/floppyX and 
> change these lines in floppy.c from
> > > } else {
> > >         u8 type = romfile_loadint("etc/floppy0", 0);
> > >         if (type)
> > >             addFloppy(0, type);
> > >         type = romfile_loadint("etc/floppy1", 0);
> > >         if (type)
> > >             addFloppy(1, type);
> > >     }
> > >
> > > to
> > >
> > > } else {
> > >         u8 type0 = romfile_loadint("etc/floppy0", 0);
> > >         if (type0)
> > >             addFloppy(0, type);
> > >         u8 type1 = romfile_loadint("etc/floppy1", 0);
> > >         if (type1)
> > >             addFloppy(1, type1);
> > >         if (type0 || type 1)
> > >             rtc_write(CMOS_FLOPPY_DRIVE_TYPE, type0 <<4 | type1);
> > >     }
> > >
> > > Quoting from osdev.org :
> > > "The first 14 CMOS registers access and control the Real-Time
>
> Clock. In fact, the only truly useful registers remaining in CMOS are 
> the Real-Time Clock registers, and register 0x10. All other registers 
> in CMOS are almost entirely obsolete (or are not standardized), and 
> are therefore useless. "
> > > So, register 0x10, the floppy drive type, is, conversely, pretty
>
> much standardised...
> > > Hope this makes sense...
> > >
> > > Cheers,
> > > Ed
> > > _______________________________________________
> > > SeaBIOS mailing list -- [e-mail]
>
> > > To unsubscribe send an email to [e-mail]
>
> > SeaBIOS mailing list -- [e-mail]
>
> > To unsubscribe send an email to [e-mail]
>
>  
> _______________________________________________
> SeaBIOS mailing list -- [e-mail] 
> To unsubscribe send an email to [e-mail] 
>
> SeaBIOS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Rudolf Marek]

Dne 02. 04. 24 v 3:19 Petr Cvek napsal(a):
> BTW does a boot from SATA CD/DVD works for you with seabios? (native IDE CD/DVD on PATA is in question too)

Try with latest 1.16.3 I think it got some fixes with AHCI wrt atapi devices.

Thanks,
Rudolf