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
<petrcve...@gmail.com> 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/seabios@seabios.org/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
<petrcve...@gmail.com <mailto:petrcve...@gmail.com>> 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 -- seabios@seabios.org
<mailto:seabios@seabios.org> <mailto:seabios@seabios.org>
>> To unsubscribe send an email to seabios-le...@seabios.org
<mailto:seabios-le...@seabios.org> <mailto:seabios-le...@seabios.org>
>
> _______________________________________________
> SeaBIOS mailing list -- seabios@seabios.org
<mailto:seabios@seabios.org> <mailto:seabios@seabios.org>
> To unsubscribe send an email to seabios-le...@seabios.org
<mailto:seabios-le...@seabios.org> <mailto:seabios-le...@seabios.org>
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org <mailto:seabios@seabios.org>
To unsubscribe send an email to seabios-le...@seabios.org
<mailto:seabios-le...@seabios.org>
_______________________________________________
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
