July 2022 - SeaBIOS - mail.coreboot.org

[PATCH v4 0/4] Make seabios linkable with lld
by Fangrui Song Dec. 7, 2022

Dec. 7, 2022

Another try after https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/thread/KBHQU4… The only change is the removal of `Makefile: Change ET_EXEC to ET_REL so that lld can link bios.bin.elf` since 699a4e5d6919cc8eae5342443025ceb6909dc276 ("ldnoexec: Add script to remove ET_EXEC flag from intermediate build objects") has done the same thing. For your convenience, the patch series is available on https://github.com/MaskRay/seabios/tree/lld Re-sending. I posted this 3 days but got bounced. I have now ensured there is my email address record on (previously not) https://mail.coreboot.org/postorius/lists/seabios.seabios.org/ as well as https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/ Fangrui Song (4): romlayout.S: Add missing SHF_ALLOC flag to .fixedaddr.\addr Make rom16.o linkable with lld romlayout32flag.lds: Use `. +=` instead of `. =` test-build.sh: Delete unneeded LD capability test scripts/layoutrom.py | 8 +++++++- scripts/test-build.sh | 42 +----------------------------------------- src/romlayout.S | 2 +- 3 files changed, 9 insertions(+), 43 deletions(-) -- 2.37.0.144.g8ac04bfd2-goog

3 7

Re: INT 14H
by Paul Edwards Sept. 29, 2022

Sept. 29, 2022

Hi Gerd. Thanks for your reply. Sorry for the delay, was swamped with other things. >> Currently I don't know what to recommend, because I >> don't understand the other side of the INT 13H/14H, >> only the OS side. > Well, the other side talks to the hardware, > and needs drivers to do so. See src/hw > Surely one can write a serial driver which connects to a remote place > using some bluetooth protocol instead of talking to a 16550. That'll > be *alot* of work though, you basically have to implement both > bluetooth stack and hardware driver. I expected to assemble, rather than write, such a thing. If not from the Linux source code, then FreeBSD or ReactOS. If for some reason (what would that be?) no-one has abstracted bluetooth to have a clean interface that I could have trivially reused, then I will put aside my bluetooth dreams and switch to a different technology. How about Wifi? Does that exist in a state usable for my purposes? >> Sure. For now, I want PDOS/386 to remain traditional. >> When I have exhausted everything that is possible >> via the BIOS, I will consider adding UEFI support. > If you want your firmware provide drivers to you for modern hardware you > are in a *much* better position with UEFI. Well, on some/many/most modern machines there is absolutely no other choice - the BIOS doesn't exist, even as CSM. > There is a bluetooth > protocol specification for example, although I'm not sure how common it > is to find an actual uefi driver for bluetooth hardware in the firmware. > Talking to ethernet using the firmware-provided uefi driver shouldn't be > much of a problem though b/c network boot is a rather standard feature. Ok, maybe in the medium term I should use a hardware device, forget the name, that turns ethernet into Wifi. So then the problem is reduced to me needing to provide a BOOTX64.EFI that converts INT 14H into UEFI ethernet calls. >> But I'd like to transport all of that software, designed for >> that environment, and change nothing at all, and have >> it work on a new environment that includes Wifi, bluetooth >> and maybe ethernet, and maybe infrared, and maybe >> other things I don't know about, but make sense (at >> some level) to be accessed via INT 14H. > Well. In the server world it is rather common to provide access to the > serial line over the network for system management purposes. > One approach for that is to have a separate management controller (bmc), > and the serial port of the machine is linked to the management > controller instead of a D9 socket. You can then connect to the bmc to > manage the machine, and one of the options available is to get serial > console access. Ok, this would allow me to have a BBS. But not allow me to have a "virtual modem" so that I can dial out. > Another approach is to have a virtual 16550 provided by the firmware. > Accessing the virtual 16550 will trap into SMM mode where the firmware > emulates a serial device and allows to access the serial port remotely > over the network, roughly comparable to how qemu provides an virtual > 16550 to virtual machines. Ok, but in the case of qemu I have the same issue - at the end of the day I want to drive a modem, so with qemu I can get it to talk to a "virtual modem". If the firmware is providing the serial to network conversion, I also need to stick in a virtual modem there. And that's what I was hoping SeaBIOS would allow me to do. > Note that both approaches work at hardware level not int14h level, > because modern operating systems use int14h services in bootloaders > only if at all. My operating system, PDOS/386, may not be considered "modern", even though it is in active development, but I do wish to use INT 14H, as that was the traditional BIOS service provided, and I wish to maintain contact with the original 80386 machines. I expect a modern environment to have the CPU, memory etc required to support this basic interface. BFN. Paul.

2 4

[BUG] Could not read from CDROM (code 0003)
by Petr Cvek Sept. 1, 2022

Sept. 1, 2022

Hello, I've tried to boot a coreboot supported machine (Kontron 986lcd-m) from CD and it hangs. The drive is correctly identified (AHCI ATAPI). Petr Log follows: Booting from DVD/CD... scsi_is_ready (drive=0x000f5820) disk_op d=0x000f5820 lba=0 buf=0x00000000 count=0 cmd=32 AHCI/2: send cmd ... AHCI/2: ... intbits 0x1, status 0x50 ... AHCI/2: ... finished, status 0x50, OK disk_op d=0x000f5820 lba=17 buf=0x000067a8 count=1 cmd=2 AHCI/2: send cmd ... handle_08 handle_hwpic1 irq=1 ... repeats ... handle_08 handle_hwpic1 irq=1 WARNING - Timeout at ahci_command:153! Boot failed: Could nothandle_08 handle_hwpic1 irq=1 read from CDROM (code 0003) enter handle_18: NULL Booting from Hard Disk... enter handle_13: a=00000201 b=00000000 c=00000001 d=00000080 ds=0000 es=07c0 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=f000 ip=ca99 f=0202 disk_op d=0x000f5870 lba=0 buf=0x00007c00 count=1 cmd=2 AHCI/1: send cmd ... AHCI/1: ... intbits 0x1, status 0x50 ... AHCI/1: ... finished, status 0x50, OK ahci disk read, lba 0, count 1, buf 0x00007c00, rc 0 Booting from 0000:7c00 ... continues with sata hdd ...

1 1

[PATCH] floppy: Support CMOS setting outside QEMU
by Petr Cvek Aug. 12, 2022

Aug. 12, 2022

SeaBIOS can be used for booting legacy OS and also Linux is still using CMOS address 0x10 to configure floppy controller. Under these assumptions it makes sense to allow boot from CMOS defined floppy drives. Signed-off-by: Petr Cvek <petrcvekcz(a)gmail.com> --- src/Kconfig | 7 +++++++ src/hw/floppy.c | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/src/Kconfig b/src/Kconfig index 3a8ffa1..42b9614 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -227,6 +227,13 @@ menu "Hardware support" default y help Support floppy drive access. + config LEGACY_FLOPPY + depends on FLOPPY && COREBOOT + bool "Get floppy type from CMOS" + default n + help + Support boot from CMOS defined floppy. Used by legacy OSes + on IBM PC compatible machine under coreboot. config FLASH_FLOPPY depends on DRIVES bool "Floppy images from CBFS or fw_cfg" diff --git a/src/hw/floppy.c b/src/hw/floppy.c index 9e6647d..40af360 100644 --- a/src/hw/floppy.c +++ b/src/hw/floppy.c @@ -155,7 +155,7 @@ floppy_setup(void) return; dprintf(3, "init floppy drives\n"); - if (CONFIG_QEMU) { + if (CONFIG_QEMU || CONFIG_LEGACY_FLOPPY) { u8 type = rtc_read(CMOS_FLOPPY_DRIVE_TYPE); if (type & 0xf0) addFloppy(0, type >> 4); -- 2.37.0

3 3

[PATCH] timer: Configure timer1 to a standard settings
by Petr Cvek Aug. 12, 2022

Aug. 12, 2022

ASPI2DOS.SYS and KEYB.COM from Win 98 SE installation CD (and most likely other DOS versions too) depend on I/O port 0x61 bit 4 to be toggled. This requires timer 1 (I/O 0x41, legacy DRAM refresh) to be correctly set. Also Intel ICH7 Family Datasheet, chapter 5.8 states: Programming the counter to anything other than Mode 2 will result in undefined behavior for the REF_TOGGLE bit. Failing to have the timer 1 configured indeed causes affected OSes to freeze during the boot. Signed-off-by: Petr Cvek <petrcvekcz(a)gmail.com> --- src/hw/timer.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/hw/timer.c b/src/hw/timer.c index b6f102e..b272f44 100644 --- a/src/hw/timer.c +++ b/src/hw/timer.c @@ -280,4 +280,10 @@ pit_setup(void) // maximum count of 0000H = 18.2Hz outb(0x0, PORT_PIT_COUNTER0); outb(0x0, PORT_PIT_COUNTER0); + + // timer1: binary count, 16bit count, mode 2 + outb(PM_SEL_TIMER1|PM_ACCESS_WORD|PM_MODE2|PM_CNT_BINARY, PORT_PIT_MODE); + // maximum count of 0012H = 66.3kHz + outb(0x12, PORT_PIT_COUNTER1); + outb(0x0, PORT_PIT_COUNTER1); } -- 2.37.0

3 3

[PATCH] virtio-blk: use larger default request size
by Gerd Hoffmann July 19, 2022

July 19, 2022

Bump default from 8 to 64 blocks. Using 8 by default leads to requests being splitted on qemu, which slows down boot. Some (temporary) debug logging added showed that almost all requests on a standard fedora install are less than 64 blocks, so that should bring us back to 1.15 performance levels. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/hw/virtio-blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hw/virtio-blk.c b/src/hw/virtio-blk.c index 929ba8873dc0..9b4a05a4c424 100644 --- a/src/hw/virtio-blk.c +++ b/src/hw/virtio-blk.c @@ -95,7 +95,7 @@ virtio_blk_op(struct disk_op_s *op, int write) blk_num_max = (u16)max_io_size / vdrive->drive.blksize; else /* default blk_num_max if hardware doesnot advise a proper value */ - blk_num_max = 8; + blk_num_max = 64; if (op->count <= blk_num_max) { virtio_blk_op_one_segment(vdrive, write, sg); -- 2.36.1

2 2

[PATCH v3] Replace $(OBJDUMP) -thr with $(READELF) -WSrs
by Fangrui Song July 14, 2022

July 14, 2022

objdump -h relies heavily on BFD internals and the BFD flags. The output is difficult to emulate in llvm-objdump. (llvm-objdump -h has a different output https://reviews.llvm.org/D57146) Switch to READELF, so that llvm-readelf can be used as an alternative. readelf is generally better than objdump when dumping ELF section/symbol information. Signed-off-by: Fangrui Song <maskray(a)google.com> --- Changes from v2 (https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/message/4AZCP…) * Change an objdump comment to mention readelf * For your convenience, this patch is available on https://github.com/MaskRay/seabios/tree/readelf --- Makefile | 18 +++--- scripts/checkrom.py | 2 +- scripts/layoutrom.py | 145 ++++++++++++++++++++----------------------- 3 files changed, 79 insertions(+), 86 deletions(-) diff --git a/Makefile b/Makefile index c108f87..5c6a838 100644 --- a/Makefile +++ b/Makefile @@ -20,7 +20,7 @@ endif AS=$(CROSS_PREFIX)as LD=$(CROSS_PREFIX)ld OBJCOPY=$(CROSS_PREFIX)objcopy -OBJDUMP=$(CROSS_PREFIX)objdump +READELF=$(CROSS_PREFIX)readelf STRIP=$(CROSS_PREFIX)strip PYTHON=python CPP=cpp @@ -165,14 +165,14 @@ $(OUT)romlayout.o: src/romlayout.S $(OUT)autoconf.h $(OUT)asm-offsets.h $(OUT)romlayout16.lds: $(OUT)ccode32flat.o $(OUT)code32seg.o $(OUT)ccode16.o $(OUT)romlayout.o src/version.c scripts/layoutrom.py scripts/buildversion.py @echo " Building ld scripts" - $(Q)$(PYTHON) ./scripts/buildversion.py -e "$(EXTRAVERSION)" -t "$(CC);$(AS);$(LD);$(OBJCOPY);$(OBJDUMP);$(STRIP)" $(OUT)autoversion.h + $(Q)$(PYTHON) ./scripts/buildversion.py -e "$(EXTRAVERSION)" -t "$(CC);$(AS);$(LD);$(OBJCOPY);$(READELF);$(STRIP)" $(OUT)autoversion.h $(Q)$(CC) $(CFLAGS32FLAT) -c src/version.c -o $(OUT)version.o $(Q)$(LD) $(LD32BIT_FLAG) -r $(OUT)ccode32flat.o $(OUT)version.o -o $(OUT)code32flat.o $(Q)$(LD) $(LD32BIT_FLAG) -r $(OUT)ccode16.o $(OUT)romlayout.o -o $(OUT)code16.o - $(Q)$(OBJDUMP) -thr $(OUT)code32flat.o > $(OUT)code32flat.o.objdump - $(Q)$(OBJDUMP) -thr $(OUT)code32seg.o > $(OUT)code32seg.o.objdump - $(Q)$(OBJDUMP) -thr $(OUT)code16.o > $(OUT)code16.o.objdump - $(Q)$(PYTHON) ./scripts/layoutrom.py $(OUT)code16.o.objdump $(OUT)code32seg.o.objdump $(OUT)code32flat.o.objdump $(OUT)$(KCONFIG_AUTOHEADER) $(OUT)romlayout16.lds $(OUT)romlayout32seg.lds $(OUT)romlayout32flat.lds + $(Q)$(READELF) -WSrs $(OUT)code32flat.o > $(OUT)code32flat.o.readelf + $(Q)$(READELF) -WSrs $(OUT)code32seg.o > $(OUT)code32seg.o.readelf + $(Q)$(READELF) -WSrs $(OUT)code16.o > $(OUT)code16.o.readelf + $(Q)$(PYTHON) ./scripts/layoutrom.py $(OUT)code16.o.readelf $(OUT)code32seg.o.readelf $(OUT)code32flat.o.readelf $(OUT)$(KCONFIG_AUTOHEADER) $(OUT)romlayout16.lds $(OUT)romlayout32seg.lds $(OUT)romlayout32flat.lds # These are actually built by scripts/layoutrom.py above, but by pulling them # into an extra rule we prevent make -j from spawning layoutrom.py 4 times. @@ -193,9 +193,9 @@ $(OUT)rom.o: $(OUT)rom16.noexec.o $(OUT)rom32seg.noexec.o $(OUT)code32flat.o $(O $(OUT)bios.bin.prep: $(OUT)rom.o scripts/checkrom.py @echo " Prepping $@" $(Q)rm -f $(OUT)bios.bin $(OUT)Csm16.bin $(OUT)bios.bin.elf - $(Q)$(OBJDUMP) -thr $< > $<.objdump + $(Q)$(READELF) -WSrs $< > $<.readelf $(Q)$(OBJCOPY) -O binary $< $(OUT)bios.bin.raw - $(Q)$(PYTHON) ./scripts/checkrom.py $<.objdump $(CONFIG_ROM_SIZE) $(OUT)bios.bin.raw $(OUT)bios.bin.prep + $(Q)$(PYTHON) ./scripts/checkrom.py $<.readelf $(CONFIG_ROM_SIZE) $(OUT)bios.bin.raw $(OUT)bios.bin.prep $(OUT)bios.bin: $(OUT)bios.bin.prep @echo " Creating $@" @@ -237,7 +237,7 @@ $(OUT)vgaentry.o: vgasrc/vgaentry.S $(OUT)autoconf.h $(OUT)asm-offsets.h $(OUT)vgarom.o: $(OUT)vgaccode16.o $(OUT)vgaentry.o $(OUT)vgasrc/vgalayout.lds vgasrc/vgaversion.c scripts/buildversion.py @echo " Linking $@" - $(Q)$(PYTHON) ./scripts/buildversion.py -e "$(EXTRAVERSION)" -t "$(CC);$(AS);$(LD);$(OBJCOPY);$(OBJDUMP);$(STRIP)" $(OUT)autovgaversion.h + $(Q)$(PYTHON) ./scripts/buildversion.py -e "$(EXTRAVERSION)" -t "$(CC);$(AS);$(LD);$(OBJCOPY);$(READELF);$(STRIP)" $(OUT)autovgaversion.h $(Q)$(CC) $(CFLAGS16) -c vgasrc/vgaversion.c -o $(OUT)vgaversion.o $(Q)$(LD) --gc-sections -T $(OUT)vgasrc/vgalayout.lds $(OUT)vgaccode16.o $(OUT)vgaentry.o $(OUT)vgaversion.o -o $@ diff --git a/scripts/checkrom.py b/scripts/checkrom.py index a5b15a4..4a23f0a 100755 --- a/scripts/checkrom.py +++ b/scripts/checkrom.py @@ -21,7 +21,7 @@ def main(): # Read in symbols objinfofile = open(objinfo, 'r') - symbols = layoutrom.parseObjDump(objinfofile, 'in')[1] + symbols = layoutrom.parseReadElf(objinfofile, 'in')[1] # Read in raw file f = open(rawfile, 'rb') diff --git a/scripts/layoutrom.py b/scripts/layoutrom.py index 7bc4a57..f4b94ea 100755 --- a/scripts/layoutrom.py +++ b/scripts/layoutrom.py @@ -541,87 +541,80 @@ class Reloc: class Symbol: name = offset = section = None -# Read in output from objdump -def parseObjDump(file, fileid): +def parseReadElf(file, fileid): # sections = [section, ...] sections = [] sectionmap = {} # symbols[symbolname] = symbol symbols = {} + lines = file.readlines() - state = None - for line in file.readlines(): - line = line.rstrip() - if line == 'Sections:': - state = 'section' - continue - if line == 'SYMBOL TABLE:': - state = 'symbol' - continue - if line.startswith('RELOCATION RECORDS FOR ['): - sectionname = line[24:-2] - if sectionname.startswith('.debug_'): - # Skip debugging sections (to reduce parsing time) - state = None - continue - state = 'reloc' - relocsection = sectionmap[sectionname] - continue + i = 0 + while not lines[i].startswith('Section Headers'): + i += 1 + i += 3 # Skip [Nr] and [ 0] + while ']' in lines[i]: + parts = lines[i][lines[i].find(']')+1:].split() + if len(parts) == 10: + name, _, _, _, size, _, _, _, _, align = parts + else: # not SHF_ALLOC + name, _, _, _, size, _, _, _, align = parts + section = Section() + section.name = name + section.size = int(size, 16) + section.align = int(align) + section.fileid = fileid + section.relocs = [] + sections.append(section) + sectionmap[name] = section + i += 1 - if state == 'section': - try: - idx, name, size, vma, lma, fileoff, align = line.split() - if align[:3] != '2**': - continue - section = Section() - section.name = name - section.size = int(size, 16) - section.align = 2**int(align[3:]) - section.fileid = fileid - section.relocs = [] - sections.append(section) - sectionmap[name] = section - except ValueError: - pass + while not lines[i].startswith('Symbol table '): + i += 1 + i += 3 # Skip Num: and 0: + while i < len(lines) and ':' in lines[i]: + colon = lines[i].find(':') + parts = lines[i].split() + try: + ndx = int(parts[6]) + name = sections[ndx-1].name + except ValueError: # ABS or UND + ndx = 0 + name = '' + if parts[3] != 'SECTION': + name = parts[7] + symbol = Symbol() + symbol.size = int(parts[2]) + symbol.offset = int(parts[1], 16) + symbol.name = name + symbol.section = sections[ndx-1] if ndx > 0 else None + symbols[name] = symbol + i += 1 + + i = 0 + while i < len(lines): + if not lines[i].startswith('Relocation section'): + i += 1 continue - if state == 'symbol': - try: - parts = line[17:].split() - if len(parts) == 3: - sectionname, size, name = parts - elif len(parts) == 4 and parts[2] == '.hidden': - sectionname, size, hidden, name = parts - else: - continue - symbol = Symbol() - symbol.size = int(size, 16) - symbol.offset = int(line[:8], 16) - symbol.name = name - symbol.section = sectionmap.get(sectionname) - symbols[name] = symbol - except ValueError: - pass + rel_name = lines[i][20:lines[i].index("'", 20)] + i += 2 + if rel_name.startswith('.rel.debug_'): + # Skip debugging sections (to reduce parsing time) continue - if state == 'reloc': - try: - off, type, symbolname = line.split() - reloc = Reloc() - reloc.offset = int(off, 16) - reloc.type = type - reloc.symbolname = symbolname - reloc.symbol = symbols.get(symbolname) - if reloc.symbol is None: - # Some binutils (2.20.1) give section name instead - # of a symbol - create a dummy symbol. - reloc.symbol = symbol = Symbol() - symbol.size = 0 - symbol.offset = 0 - symbol.name = symbolname - symbol.section = sectionmap.get(symbolname) - symbols[symbolname] = symbol - relocsection.relocs.append(reloc) - except ValueError: - pass + assert rel_name.startswith('.rel') + relocated = sectionmap[rel_name[4:]] + while lines[i][0].isalnum(): + line = lines[i] + off, _, typ, _, symbolname = line.split() + reloc = Reloc() + reloc.offset = int(off, 16) + reloc.type = typ + reloc.symbolname = symbolname + reloc.symbol = symbols.get(symbolname) + assert reloc.symbol is not None + relocated.relocs.append(reloc) + i += 1 + return sections, symbols # Parser for constants in simple C header files. @@ -644,15 +637,15 @@ def main(): # Get output name in16, in32seg, in32flat, cfgfile, out16, out32seg, out32flat = sys.argv[1:] - # Read in the objdump information + # Read in the readelf information infile16 = open(in16, 'r') infile32seg = open(in32seg, 'r') infile32flat = open(in32flat, 'r') # infoX = (sections, symbols) - info16 = parseObjDump(infile16, '16') - info32seg = parseObjDump(infile32seg, '32seg') - info32flat = parseObjDump(infile32flat, '32flat') + info16 = parseReadElf(infile16, '16') + info32seg = parseReadElf(infile32seg, '32seg') + info32flat = parseReadElf(infile32flat, '32flat') # Read kconfig config file config = scanconfig(cfgfile) -- 2.37.0.144.g8ac04bfd2-goog

2 2

Force 1024x768 resolution on SeaBIOS with coreboot native graphics
by Felix Freeman July 1, 2022

July 1, 2022

Hello, I have noticed several problems when using coreboot native graphics ("high resolution" linear framebuffer) with a resolution of 1024x768, on SeaBIOS + SeaVGABIOS: - Boot menus (GRUB, Syslinux) look at a resolution of 640x480. - I get a warning in Debian "graphical" installer "Undefined video mode number: 314", asking me to select a mode, if I select a resolution of 1024x768 it boots fine, if I don't, after 30 seconds, it crashes. - When I use iPXE with SeaBIOS I can't get video on "text based installers" (which use ncurses, for example Debian text based installers). However: - In iPXE I get video on other "graphical" installers (e.g. Debian graphical installer). - I have noticed that in "video mode" it is able to change resolution to show a bootsplash (mode 0x144 on vgasrc/svgamodes.c) and then goes back to 640x480 on "text console". - In iPXE the text display resolution is 1024x7480, however the menus are 640x480. I don't know if its implementation is incomplete, or because of technical reasons SeaVGABIOS is unable to behave correctly without a proprietary VGA BIOS. I think a first step might be to be able to force a minimum resolution in text and video modes. So, my first question is: what is needed to force SeaBIOS/SeaVGABIOS to display a resolution of 1024x768 instead of 640x480 when in "text mode" and "video mode"? And my second question is whether with some work the coreboot native graphics implementation could behave as good as (or close to) a proprietary VGA BIOS. Best regards, Felix

2 3