OSDev.org

I got a new laptop that had promising hardware, but it won't boot RDOS with EFI. It doesn't even seem to try and displays the texts the EFI image emits but then doesn't run the loader, and the keyboard still is active (caps lock can be toggled). When using legacy boot, it doesn't work either and also stops with keyboard enabled. The same USB stick boots in EFI mode on a Ryzen-based laptop. I also know that RDOS boots on Threadripper.

I wonder what Intel have done on their new CPUs that causes this? Or maybe it's an BIOS issue?

At least I know it still works with AMD....

rdos wrote:It doesn't even seem to try and displays the texts the EFI image emits but then doesn't run the loader

Enter Setup (or boot Linux and dump /sys/firmware/efi/efivars) to see if your loader is added to the boot options. Newer firmware don't include EFI/BOOT/BOOTX86.EFI (the 32 bit version) by default, only EFI/BOOT/BOOTX64.EFI (the 64 bit version). I've once seen a machine which had neither, and there was only BOOTMGR.EFI in the root directory added. Also check if Secure Boot is disabled.

rdos wrote:When using legacy boot, it doesn't work either

Hmmm, that's strange. Are you sure you have installed it correctly? The MBR should be loaded at least.

rdos wrote:I wonder what Intel have done on their new CPUs that causes this? Or maybe it's an BIOS issue?

Probably BIOS/EFI one. I don't think a CPU-specific feature would stop your machine from loading your loader, you'd more likely to have a triple fault or something. Plus it's not loaded neither from UEFI nor from CSM, which suggest you have a disk configuration problem.

Cheers,
bzt

try to launch your OSL through the efi shell or Boot Manager's "load from file" option. that would be the easiest way.

rdos wrote:I wonder what Intel have done on their new CPUs that causes this?

I would suspect a bug in your code before a bug in the CPU, but you could always check the specification update for your CPU.

rdos wrote:Or maybe it's an BIOS issue?

Only if you count SMM as a BIOS issue. Other than that, I can't think of anything in the firmware that would affect both a legacy BIOS bootloader and a UEFI bootloader.

Testing it a bit more it seems that the problems differ between EFI and legacy boot. With legacy boot, I can press CTRL-ALT-ESC to enter the panic handler and it lists the state of four cores. That means that with legacy boot, RDOS is loaded but something hinders it from completing the boot. I suspect it might be the VBE interface that malfunctions. I've seen several Intel BIOSes in the past few years that won't list the correct video modes (only 4:3 modes) and a complete failure of VBE might not be unexpected. Also, the VBE code is run in V86 mode rather than in real mode. With EFI boot, CTRL-ALT-ESC doesn't work and so the EFI environment is still active and for some reason, control is not passed to the boot code. Could be that GOP is non-functional or that some other setting stops booting other OSes than the bundled Windows 10. Actually, in the cases with an Intel BIOS that doesn't support the actual screen resolution, this is echoed in EFI too, and so if VBE doesn't work then GOP might not either.

bzt wrote:

rdos wrote:It doesn't even seem to try and displays the texts the EFI image emits but then doesn't run the loader

Enter Setup (or boot Linux and dump /sys/firmware/efi/efivars) to see if your loader is added to the boot options. Newer firmware don't include EFI/BOOT/BOOTX86.EFI (the 32 bit version) by default, only EFI/BOOT/BOOTX64.EFI (the 64 bit version). I've once seen a machine which had neither, and there was only BOOTMGR.EFI in the root directory added. Also check if Secure Boot is disabled.

I used a BIOS formatted (in the case of legacy boot) and GPT formatted (in the case of EFI boot) USB flash drive to test. I wouldn't mess with the actual boot sequence until I knew it would work, and then a complete reformat of the hard drive would be the best method since it would erase every trace of "fixes" and "lock-downs" attempted by the manufacturer.

The BIOS was unusually friendly in getting into it, and disabling secure boot and enabling legacy boot.

Also, since my EFI loader dumps the size of the files involved, the positions and also allows me to select the boot image, the EFI loader definitely runs but then fails to boot.

rdos wrote:That means that with legacy boot, RDOS is loaded

rdos wrote:the EFI loader definitely runs but then fails to boot.

So it seems your loader gets loaded in both case after all. Then there must be bugs in your loaders, which is the better case because you can fix those easier than to hack the firmware.

Cheers,
bzt

bzt wrote:

rdos wrote:That means that with legacy boot, RDOS is loaded

rdos wrote:the EFI loader definitely runs but then fails to boot.

So it seems your loader gets loaded in both case after all. Then there must be bugs in your loaders, which is the better case because you can fix those easier than to hack the firmware.

Cheers,
bzt

It's only the loader in the EFI case. I suppose that if I check more error codes from EFI services, I would know what part of it that doesn't work. Might be GOP that cannot be opened, no supported video modes, or something else that normally shouldn't fail.

In the legacy case, it's driver initialization that fails. The keyboard driver works, but the command shell never loads, possibly because the video driver never completes the initialization. Something that could be caused by VBE. I think I can place a panic in the VBE initialization and then single step it to figure out what goes wrong.

rdos wrote:something else that normally shouldn't fail.

One thing that I've learned from developing for UEFI is that everything can fail, and all protocols might be missing (even the ones that are mandatory according to the UEFI spec). Be paranoid, always assume the worst, because there'll be always at least one buggy firmware implementation that will fail... Maybe 10 or 20 years later, when UEFI implementations gets bugfixed enough you could assume it's going to work out-of-the-box, but not before

Cheers,
bzt

bzt wrote:Maybe 10 or 20 years later, when UEFI implementations gets bugfixed enough you could assume it's going to work out-of-the-box,

I wouldn't assume firmware authors to be caring about anything except Windows. So, basically, you will be in hot water as soon as you do anything different from Windows. Which isn't different from old BIOS, come to think of it. So I guess that the only bugs that will get fixed are the ones found by Microsoft. What might get better in future is that best practices might be developed that allow you to detect and work around common bugs. But manufacturers working to spec will only happen under pressure, and basically only MS has enough clout. Maybe Linux, but that's it.

nullplan wrote: I wouldn't assume firmware authors to be caring about anything except Windows. So, basically, you will be in hot water as soon as you do anything different from Windows.

It might be a little bit off-topic, but I think you are absolutely right. Just yesterday I was doing BIOS upgrade on my MSI motherboard. It decided not only to delete all non-Windows boot entries, but actively and completely wipe ESP partition on my Linux drive.

nullplan wrote:I wouldn't assume firmware authors to be caring about anything except Windows.

Yeah, I agree too, there might be some truth in your words...

nullplan wrote:What might get better in future is that best practices might be developed that allow you to detect and work around common bugs.

Yes, plus I also try to minimize the interaction with the firmware as much as possible. This way there's no need to workaround something that's not being used

nullplan wrote:But manufacturers working to spec will only happen under pressure, and basically only MS has enough clout. Maybe Linux, but that's it.

I think the lack of Linux certificates showed that no Linux company has that kind of power. So we're left with MS hoping for the best.

Cheers,
bzt

I've debugged both now.

EFI doesn't work because GetMemoryMap returns 0 for descriptor size, which causes division by zero when calculating number of entries. When the descriptor size is set to sizeof(EFI_MEMORY_DESCRIPTOR) instead a completely bogus memory map is decoded. When RDOS boots with it everything locks up. So, the problem with EFI boot is that GetMemoryMap doesn't work. GOP does report the correct resolution (1920x1020), but it uses BGR which I don't support. Still, it never comes to that point because of the faulty memory map.

Legacy boot doesn't work since the real-mode interrupt vector for int 10h points to segment E9xx which I assume is not the BIOS and so accessing this area results in a pagefault which halts the video startup. I think this might be possible to fix, although not simple since I use the Exxx segment for stacks in the DOS emulator.

what's your sizeof(EFI_MEMORY_DESCRIPTOR)?

rdos wrote:EFI doesn't work because GetMemoryMap returns 0 for descriptor size,

No OS can boot if GetMemoryMap() returns garbage. Are you able to boot any other OS on this laptop? (Be sure to choose an OS with a 32-bit bootloader if your bootloader is 32-bit.)

rdos wrote:Legacy boot doesn't work since the real-mode interrupt vector for int 10h points to segment E9xx which I assume is not the BIOS

Why do you assume that? All the BIOS ROMs I've looked at map 128kB of runtime code and data in the 0xE0000-0xFFFFF range (aside from ancient ROMs that are smaller than 128kB). I agree that it's a strange address, though; VGA-compatible option ROMs are usually mapped in the 0xC0000-0xC7FFF range.