DOS ain't dead

In the past I announced here my utility ACPITOOL which can examine ACPI tables in your computer, can detect the CPU topology, perform a reset or a shutdown of the computer.

Now I created the new version (1.1).
New features/switches:

/WINPK - detect the windows product key if stored in the firmware (in ACPI internals)

/Z and /ZF - solves the problem with some new notebooks which do not use the standard reset mechanism. In such machines the CTRL-ALT-Del performs not the reset but the hanging of the computer.
The /Z or /ZF switches make a ACPI analysis for reboot mechanism and keep in the memory a tiny TSR which patches the BIOS for the proper reboot after CTRL-ALT-Del. (The TSR has only about 340 bytes!)

Download here: http://laaca.borec.cz/soubory/acpitool.zip

---
DOS-u-akbar!

I'd like to try it but I got a new laptop (HP ZBook 15 G8, core 11.gen.) at work a few weeks ago that is unfortunately completly legacy free so I cannot boot DOS there anymore :( There's no legacy boot option, I can boot only from UEFI partitions or directly *.EFI executables but they have to be signed (I guess), e.g. I can boot memtest86.efi but cannot boot UEFI Shell 2.2 from github...

It would be nice to have some UEFI compatible bootloader that could switch CPU back to realmode, load some CSM or other BIOS emulation layer and allow boot DOS. Or need to make some UEFI DOS that would use UEFI services instead of BIOS...

---
DOS gives me freedom to unlimited HW access.

After consultation in the separate thread here I updated the ACPITOOL to 1.1b
This sight update reduces the TSR memory footprint.
ACPITOOL v1.1b

---
DOS-u-akbar!

I just tested on my home PC but as it has only ACPI 1.0 (no reboot supported) neither has windows key there's not much to test. I just found a typo in help, line /I there's "csn" instead of "can" :)

---
DOS gives me freedom to unlimited HW access.

AFAIK boot managers like Grub can boot a SeaBIOS image from a regular storage media. A SeaBIOS image can be a full BIOS implementation or a CSM depending on how it was compiled. So you can theoretically chain-boot to DOS even on an UEFI class 3 machine.

An UEFI DOS is not a good idea (át least not if this DOS does not provide legacy BIOS interface itself for other programs) as user programs would still call BIOS services.

---
DOS isn't about why. It's about why not.

> An UEFI DOS is not a good idea (át least not if this DOS does not provide
> legacy BIOS interface itself for other programs) as user programs would
> still call BIOS services.

at least by current understanding, DOS does everything by calling BIOS for whatever is needed to be done.

so a UEFI BIOS (that is loaded by UEFI, and emulates BIOS) is entirely possible. UEFI 'DOS' might be possible, but is really about as useful as 'CTTY COM1'.

you might prove me wrong, but there is an awful lot of work ahead of you

I can prove you wrong quite easily: UEFI BIOS is not possible. It does exist. What exists is a precedent, not a possibility. What's more, I've even given a practical example of it, not to mention UEFI up to class three that normally comes with a BIOS interface out of the box. Please, next time read what you react to.

Also, as I said, an UEFI DOS is not a good idea as long as it doesn't provide the entire BIOS interface together with the DOS services, because user programs will still rely on standard BIOS calls.

---
DOS isn't about why. It's about why not.

> I can prove you wrong quite easily: UEFI BIOS is not possible. It does
> exist. What exists is a precedent, not a possibility. What's more, I've
> even given a practical example of it, not to mention UEFI up to class three
> that normally comes with a BIOS interface out of the box. Please, next time
> read what you react to.

you wrote before:
"AFAIK boot managers like Grub can boot a SeaBIOS image from a regular storage media. A SeaBIOS image can be a full BIOS implementation or a CSM depending on how it was compiled. So you can theoretically chain-boot to DOS even on an UEFI class 3 machine."

here theoretically is the word to watch. has it been shown in practice?

> Also, as I said, an UEFI DOS is not a good idea as long as it doesn't
> provide the entire BIOS interface

complete nonsense. DOS doesn't provide ANY BIOS interface. DOS entirely relies on BIOS to provide services. BIOS interface would/should be served by SEABIOS. DOS is not involved in BIOS stuff.

whatever combination of bootmanagers, UEFI or SEABIOS is involved: it's fairly well documented what is expected from the environment for 'DOS'

1. SeaBIOS has been shown in practice. AFAIK it can be load from a HDD, but it definitely works if flashed into the motherboard as a firmware. Doesn't matter anyway, because CSM itself is a "UEFI BIOS".

2. "DOS doesn't provide *ANY *BIOS interface blah blah blah blah blah". That's right. But an UEFI DOS should. Otherwise it is entirely useless. As I said, DOS programs rely on BIOS services just as much as they rely on DOS itself. They can wipe their ***es with a DOS running with UEFI directly if they still can't.

---
DOS isn't about why. It's about why not.

> AFAIK boot managers like Grub can boot a SeaBIOS image from a regular
> storage media. A SeaBIOS image can be a full BIOS implementation or a CSM
> depending on how it was compiled. So you can theoretically chain-boot to
> DOS even on an UEFI class 3 machine.

Yeah, this sounds interesting! Did you personally tried to boot such chain? What kind of GRUB should I use? I found GRUB4DOS-UEFI a variant of GRUB4DOS by Chenall
https://github.com/chenall/grub4dos/releases/tag/for_UEFI

I also have found useful tools PreLoader and Hashtool
https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/
that can calculate hash of user UEFI image and import the key into NV key storage. PreLoader is signed by some trusted key that is allowed to be executed on my laptop so via PreLoader I can load other UEFI images that I signed personally. I managed to boot successfully UEFI Shell 2.2.
But when I tried to boot GRUB4DOS-UEFI this way I got only a black screen, NumLock LED responds to NumLock key and I can press CTRL+ALT+DEL. I tried to comment out or change videomode in menu.lst (e.g. graphicsmode -1 1024 768) but it didn't help. So as a 1st step I need to make some GRUB working and then try to chainload SeaBIOS with it...

UPDATE
I have found more powerfull UEFI boot package
https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk
with GRUB2 that can load any other unsigned *.EFI modules. It only needs to import certificate at first boot (if SecureBoot enabled) then no more limits.
But I cannot find any compiled SeaBIOS module to load :\

---
DOS gives me freedom to unlimited HW access.

> UPDATE
> I have found more powerfull UEFI boot package
> https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk
> with GRUB2 that can load any other unsigned *.EFI modules. It only needs to
> import certificate at first boot (if SecureBoot enabled) then no more
> limits.
> But I cannot find any compiled SeaBIOS module to load :\

Extraordinary! So, you're 90% of the way of booting DOS on a UEFI-only system, without a CSM BIOS? I looked and could also not find any SeaBIOS modules, either. There is this page: https://mrchromebox.tech/#bootmodes which mentions using SeaBIOS in getting a FullBIOS enabled on UEFI-only Chromebooks, for example, but there are no links to any such SeaBIOS image or utilities, except for the Firmware Script files.

Please keep us updated on your search for a working SeaBIOS image which can be used to boot DOS on a UEFI-only laptop. It will be a holy-grail find.

No, I'm just at the beginning. The ability of loading arbitrary UEFI modules is not related with DOS any way. In the past I played with Coreboot and SeaBIOS a little bit so I could try compile SeaBIOS myself but I'm not sure if the compile process will output some image ready to load with GRUB2 or UEFI module. It seem's it's intended only for VMs like QEMU...

BTW I got a hint - GRUB4DOS-UEFI may not work because still relying on legacy VGA BIOS? I didn't dive into sources. At 99.9% my laptop FW doesn't have any legacy VGA BIOS so this could lead to blackscreen that I got...

---
DOS gives me freedom to unlimited HW access.

> No, I'm just at the beginning. The ability of loading arbitrary UEFI
> modules is not related with DOS any way. In the past I played with Coreboot
> and SeaBIOS a little bit so I could try compile SeaBIOS myself but I'm not
> sure if the compile process will output some image ready to load with GRUB2
> or UEFI module. It seem's it's intended only for VMs like QEMU...
>
> BTW I got a hint - GRUB4DOS-UEFI may not work because still relying on
> legacy VGA BIOS? I didn't dive into sources. At 99.9% my laptop FW doesn't
> have any legacy VGA BIOS so this could lead to blackscreen that I got...

Is it possible to create a UEFI BIOS image with a legacy, generic VGA BIOS embedded inside? I would think not since that VGA BIOS would rely on DOS INT calls and contain legacy 16-bit code which won't run in any UEFI BIOS? Or, to somehow imbed GRUB4DOS-UEFI with a legacy VGABIOS module and link the code to it instead of VGA BIOS calls in the system (CSM) BIOS module?

I think that VGA ROM is linked with CSM that scan and load other ROMs. In theory it may be possible do such mod but as it is some proprietary HP UEFI FW I don't want try to brick it...

In some presentation I have found that seabios can be compiled as csm for ovmf - for virtual machines but most probably not for a real HW...

---
DOS gives me freedom to unlimited HW access.

Minor update:
* added parameter /T (find the port for 3,58MHz ACPI timer)
* parameter /TT (find and test the ACPI timer)

Download here: http://laaca.borec.cz/soubory/acpitool.zip

---
DOS-u-akbar!

Hello Zyzzle,

> Is it possible to create a UEFI BIOS image with a legacy, generic VGA BIOS
> embedded inside? I would think not since that VGA BIOS would rely on DOS
> INT calls and contain legacy 16-bit code which won't run in any UEFI BIOS?

Actually, I would say yes and no. (!)

My extremely experimental biefircate project (https://github.com/tkchia/biefircate) boots up as a UEFI bootloader. However, it tries to find a VGA option ROM among the PC's "Firmware Volumes", and if it does find such an option ROM, it will switch to 16-bit real mode, and run the option ROM to put the display in a VGA-compatible mode. And yes, this works — on some machines, anyway.

But no, a "generic VGA BIOS" will most probably not work. (In particular, I have tried SeaBIOS's VGA BIOS code, and it is simply not enough.) You need an option ROM that knows about the specific kind of display card you are using, so that it can reconfigure the display to a VGA-compatible mode.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> Hello Zyzzle,
>
> > Is it possible to create a UEFI BIOS image with a legacy, generic VGA
> BIOS
> > embedded inside? I would think not since that VGA BIOS would rely on DOS
> > INT calls and contain legacy 16-bit code which won't run in any UEFI
> BIOS?
>
> Actually, I would say yes and no. (!)
>
> My extremely experimental biefircate project
> (https://github.com/tkchia/biefircate) boots up as a UEFI
> bootloader. However, it tries to find a VGA
> option ROM among the
> PC's "Firmware Volumes", and if it does find such an option ROM, it will
> switch to 16-bit real mode, and run the option ROM to put the display in a
> VGA-compatible mode. And yes, this works — on some machines, anyway.
Thanks for reply, and also for informing of your project. Your inights and tests with using SeaBIOS answer the question; that it is NOT possible for its skeletal VGA BIOS code to be adequate for booting and running DOS applications or games in an UEFI-only, non CSM BIOS system.

I should think the number of UEFI-only systems with any VGA option ROM would be very low, particularly when using onboard video. However, some Chromebooks, older models, probably do have legacy VGA option ROMs. Newer ones, based on upon Intel GeminiLake chipsets, will apparently by design have no legacy option ROMS at all, and crippled by intention. Also, it appears to be true that any systems with onboard Intel Video BIOS have intentionally removed 16-bit option ROM code module support as of 10th or 11th Generation Intel core.

And could you easily load VGA BIOS from an image file instead of embedded UEFI FW? Just for a case I would be able to find and extract some useful VGA BIOS for my 11th gen core to be able to load it without BIOS modding that I cannot do on this machine. But I'm not sure if such VGA BIOS already exist for this HW, I'll have to search...
Anyway, I heard that UEFI FB could be used also after boot exit so it may be usable at least for text mode, just need to make some emulation layer that will expose INT10h services to DOS programs (those don't use VGA directly) emulated via FB...

---
DOS gives me freedom to unlimited HW access.

Hello RayeR,

> And could you easily load VGA BIOS from an image file instead of embedded
> UEFI FW? Just for a case I would be able to find and extract some useful
> VGA BIOS for my 11th gen core to be able to load it without BIOS modding

Yes, that is quite possible — I have not yet implemented it in biefircate, but it should not be too hard. Also, I think more modern PCI-compliant VGA option ROMs can be loaded almost anywhere in base memory (I understand that older VGA ROMs expect to be loaded at 0xc000:0).

> that I cannot do on this machine. But I'm not sure if such VGA BIOS already
> exist for this HW, I'll have to search...

You probably want to check the PCI device id. (e.g. 8086:9bc8) for your particular graphics card. On Linux, lspci -nn should do the job (I am not so sure about other OSes, but there should be a way).

Each PCI-compliant option ROM has a "PCIR" structure that says, among other things, which PCI device id. (or ids.) the option ROM is meant for.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

I have found that UEFIShell can load PCI ROM images. There's a command
LoadPciRom –nc image.bin

I also tested via shell command mm that memory area C0000-FFFFF is writable. My VGA PCI ID is 8086:9A60
TigerLake-H GT1 [UHD Graphics]
https://pci-ids.ucw.cz/read/PC/8086/9a60

---
DOS gives me freedom to unlimited HW access.

ACPI timer detected:

ACPI tools v 1.2 - created by Laaca (laaca@seznam.cz)

ACPI 3.58MHz timer found!
It runs on IO port 0408h and its size is 24 bits.
Test output from this port:
00C3B146
00E4B146
0005B146
0026B146
0047B146
0068B146
0089B146

---
DOS gives me freedom to unlimited HW access.

> Test output from this port:
> 00C3B146
> 00E4B146
> 0005B146
> 0026B146
> 0047B146
> 0068B146
> 0089B146

The constant lower word looks as a bug but I believe that it is not.
The PC has a main oscillator running at 14.318MHz.
14.318 / 4 is 3.5795MHz (aka 3.58MHz). It is the basic frequency for the PC mainboard. The PC BIOS timer (18.2Hz) is also derived from 3.5795MHz
(3.5795 / 65535 = 55ms). The delay routine in the loop in the ACPItools uses the 18.2hz (55ms) BIOS ticks. So it is OK that it is synchonised with the ACPI timer.

---
DOS-u-akbar!

Hello RayeR,

> I have found that UEFIShell can load PCI ROM images. There's a command
> LoadPciRom –nc image.bin
>
> I also tested via shell command mm that memory area C0000-FFFFF is
> writable. My VGA PCI ID is 8086:9A60
> TigerLake-H GT1 [UHD Graphics]
> https://pci-ids.ucw.cz/read/PC/8086/9a60

OK... let us continue the discussion about my biefircate at the appropriate GitHub discussion thread (https://github.com/tkchia/biefircate/discussions/4), to avoid derailing this thread too much.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"