By modifying SeaBIOS, you meant the addition of a new Kconfig option I suppose? For the coreboot part I have finished almost all the necessary changes, so it should be fine (I'm already subscribed to both mailing lists).
Thanks for your help.
Petr
Dne 25. 04. 22 v 1:29 Keith Hui napsal(a):
(Looping in the SeaBIOS mailing list again.)
See this: https://www.seabios.org/Runtime_config
It appears CMOS locations are a legacy artifact and files within the cbfs image (eg. etc/floppy0) is the preferred way of passing SeaBIOS settings. If you want a proper fix with the value stored in CMOS (and be configurable via nvramtool), you'll need to modify both SeaBIOS and the coreboot option table layout for your board. If you need help with coreboot and are not subscribed to that mailing list, I can reach out and loop you in.
@Kevin - What are we to do for SeaBIOS settings that the we may want to change at runtime eg. via nvramtool? Are there any such settings?
Keith
On Sun, 24 Apr 2022 at 18:36, Petr Cvek petrcvekcz@gmail.com wrote:
Linux actually reads the floppy type from the exact same CMOS location as QEMU compiled SeaBIOS:
https://elixir.free-electrons.com/linux/v5.12.9/source/arch/x86/include/asm/floppy.h#L257and if I remember correctly I've had to force the type through floppy module parameter, before I modified the coreboot+SeaBIOS source codes.
The other operating systems will probably try to read the CMOS location as well. IMO it is actually a standard bitfield in IBM PC compatible computer. Also all cmos.layout files start the configuration from bit 384 and some of them even have the first 120 bits explicitly defined as "reserved".
Under these constraints I think it should be possible to change the line to something like this:
if (CONFIG_QEMU || CONFIG_USE_CMOS) {With CONFIG_USE_CMOS be "n" by default so non floppy boards will end with the old code path.
Petr
Dne 24. 04. 22 v 21:05 Keith Hui napsal(a):
Hi Petr,
Linux seems to have been able to pick up all the floppy drives on its own.
But if you read a few more lines beyond the snippet you posted, you'll see that it only reads nvram for floppy types when compiled for and run on QEMU because that layout is hard coded and QEMU-specific. To extend it to other coreboot targets that layout will need to be incorporated into the option table of all coreboot mainboards, which isn't trivial and some boards don't even have floppy ports at all. And should those nvram bytes hold value for something else, results can be very unpredictable.
You'll also see another way around it, using files etc/floppy0 and etc/floppy1 added to the coreboot image. Some tracing within this file will tell you what values to use. Downside is changing these values also requires reflashing.
Hope this helps.
Keith
On Sun, 24 Apr 2022 at 07:15, Petr Cvek petrcvekcz@gmail.com wrote:
Hello,
I was playing with coreboot + floppy and it seems the drive type can be read from CMOS only if the machine is QEMU.
payloads/external/SeaBIOS/seabios/src/hw/floppy.c
floppy_setup(void) { ... if (CONFIG_QEMU) { u8 type = rtc_read(CMOS_FLOPPY_DRIVE_TYPE); if (type & 0xf0) addFloppy(0, type >> 4); ... } else { u8 type = romfile_loadint("etc/floppy0", 0); ...
Is it possible enable this function for a real coreboot target? What way is the most acceptable way to do it (something like || CONFIG_USE_CMOS)?
I've forced it with "always true" condition and after adding configurations to cmos table and superio in coreboot, I was able to boot msdos on kontron 986lcd-m board.
P.S. original message got stuck somewhere in the mailserver as I forgot to subscribe to seabios mailing list.
Regards, Petr _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-leave@seabios.org