OSDev.org

Octocontrabass wrote:

rdos wrote:You mean you don't have the IBM technical reference for personal computers from 1983?

Of course I have those manuals. According to the manuals from 1983, the only way to detect available memory is INT 0x12, which is limited to 640kB. Which manual do I use if I want to access more than 640kB?

But maybe you meant 1984. According to the manuals from 1984, INT 0x15 AH=0x88 can detect up to 64MB of additional memory. Which manual do I use if I want to access more than 64MB?

If you want to boot everything that has a 386+ processor, you will need to cope with those difficulties. I'd even say, scanning for available memory would be a reasonable strategy for the first few generations. Supporting text-mode would be a requirement, and you can optionally check for VGA modes and VBE.

UEFI is just the current stage of PC booting, and it is probably not the last.

rdos wrote:If you want to boot everything that has a 386+ processor, you will need to cope with those difficulties.

That's the problem. UEFI has one specification that covers everything necessary to boot the PC, and BIOS does not.

rdos wrote:I'd even say, scanning for available memory would be a reasonable strategy for the first few generations.

On very old PCs, you can't install more than 64MB of RAM, so INT 0x15 AH=0x88 works perfectly fine. You wouldn't want to try probing on something that old anyway - there's no guarantee you'll be able to bypass the cache.

rdos wrote:UEFI is just the current stage of PC booting, and it is probably not the last.

It doesn't look like it will be replaced any time soon.

Octocontrabass wrote:

rdos wrote:If you want to boot everything that has a 386+ processor, you will need to cope with those difficulties.

That's the problem. UEFI has one specification that covers everything necessary to boot the PC, and BIOS does not.

Maybe that's the way you view it, but for me UEFI just adds to the burden of writing boot loaders because if you want to boot older hardware, or hardware that doesn't work with UEFI, then you still need the BIOS method. So, instead of making things simpler, UEFI just adds another standard you need to adapt to. Essentially, it doubles the amount of work needed to write the bootloader part.

Octocontrabass wrote:

rdos wrote:I'd even say, scanning for available memory would be a reasonable strategy for the first few generations.

On very old PCs, you can't install more than 64MB of RAM, so INT 0x15 AH=0x88 works perfectly fine. You wouldn't want to try probing on something that old anyway - there's no guarantee you'll be able to bypass the cache.

I'm pretty sure this works well on older hardware. I used this for a decade before I started to use the BIOS method.

I don't think the cache was an issue. I probed by first writing one signature on every 4k page. Then I checked (using xchg) all 4k pages for the signature again, writing a second signature. This could handle memory aliasing, which was a problem on some old systems.

rdos wrote:So, instead of making things simpler, UEFI just adds another standard you need to adapt to. Essentially, it doubles the amount of work needed to write the bootloader part.

I'm not sure about that. It's a lot easier to write a UEFI bootloader that works everywhere. With a BIOS bootloader, you have to deal with things that were either never standardized at all or were standardized in a document you don't have and can't find. That sort of thing has definitely increased the amount of work I've had to put into my BIOS bootloader.

rdos wrote:I don't think the cache was an issue. I probed by first writing one signature on every 4k page. Then I checked (using xchg) all 4k pages for the signature again, writing a second signature. This could handle memory aliasing, which was a problem on some old systems.

Sure, that will bypass the cache, but now you're writing into MMIO and reserved RAM. And what happens if only part of the page behaves like RAM?

Octocontrabass wrote:

rdos wrote:So, instead of making things simpler, UEFI just adds another standard you need to adapt to. Essentially, it doubles the amount of work needed to write the bootloader part.

I'm not sure about that. It's a lot easier to write a UEFI bootloader that works everywhere. With a BIOS bootloader, you have to deal with things that were either never standardized at all or were standardized in a document you don't have and can't find. That sort of thing has definitely increased the amount of work I've had to put into my BIOS bootloader.

UEFI has it's own special problems. Some OSes seems to hijack the boot point, and so you cannot add your own boot loader since the standard efi/bootx64.efi will never be loaded. The only way I could find that fixed that was to clear the disc completely so BIOS coluldn't find the Windows loader. At least with BIOS, you know BIOS will always load the master boot record.

I've also had problems with UEFI failing to load my OS kernel, which I had to fix with a strange hack. That's not something you will experience with BIOS since you need to load it with your own code.

The worst problem is that UEFI cannot guarantee that any physical memory area is free for OS usage. That creates a big problem, and I still rely on 0x1000 and a few more 4k pages after it will be usable for the OS. With BIOS, I can always assume that the OS image can be loaded at 0x110000 and that 0x1000 to 0x90000 is free to use for data.

Octocontrabass wrote:

rdos wrote:I don't think the cache was an issue. I probed by first writing one signature on every 4k page. Then I checked (using xchg) all 4k pages for the signature again, writing a second signature. This could handle memory aliasing, which was a problem on some old systems.

Sure, that will bypass the cache, but now you're writing into MMIO and reserved RAM. And what happens if only part of the page behaves like RAM?

Right. That was the primary reason why I stopped using that method. Although, early PCs usually had MMIO high in memory, and there was always an area with no memory between the highest usable memory and MMIO. Most PCs still appear to be like that, but relying on it is not so good.

rdos wrote:UEFI has it's own special problems. Some OSes seems to hijack the boot point, and so you cannot add your own boot loader since the standard efi/bootx64.efi will never be loaded.

UEFI provides NVRAM variables to select the boot file name. The default "bootx64.efi" name is only supposed to be used either when booting from removable media or when the NVRAM variables are deleted. Your installer should use UEFI runtime services to update the variables.

Unfortunately, some vendors don't follow this part of the spec very well.

rdos wrote:At least with BIOS, you know BIOS will always load the master boot record.

I have encountered at least one BIOS that did not load the master boot record. (But, to be completely fair, it may only do that when booting from USB, and maybe only when the USB drive is formatted in a particular way.)

rdos wrote:I've also had problems with UEFI failing to load my OS kernel, which I had to fix with a strange hack. That's not something you will experience with BIOS since you need to load it with your own code.

I haven't heard of anyone else encountering any problems with loading files into memory. Perhaps your "strange hack" is actually covering up a bug elsewhere in your bootloader.

rdos wrote:The worst problem is that UEFI cannot guarantee that any physical memory area is free for OS usage.

No one needs that, so it's not a problem.

UEFI is great. It's not perfect and many areas could have been better. But it's still a huge improvement over the non-standard that is the BIOS. Things change. Learn how UEFI works and you will never look back. Even if you don't like it, it is the present and the foreseeable future.

Guys, let me try to be fair. I see valid arguments on both the sides. Also, I wrote both a BIOS bootloader and a UEFI one from scratch, so I believe I have enough data, even if I'm definitively not so experienced as Octocontrabass nor rdos.

Octocontrabass wrote:No one needs that, so it's not a problem.

Well, having a fixed range of usable mem is convenient for simple operating systems because it doesn't require relocation nor a special mapping using the virtual memory just for the kernel. But, I recognize that having such fixed ranges would give less flexibility for the hardware and for the firmware. In general, all the new standards like UEFI, ACPI, USB etc. are designed to work well with big & complex mainstream operating systems. For consumers and big companies that's fine, but for "small OS" developers like us, sometimes that makes our life more complicated. It's trade-off that has been made, as it's very hard to optimize for both the use cases. It's a bit a like small-scale vs. large-scale software: the large-scale solutions look insanely bloated and complicated when people try to use them for the small-scale. The small-scale solutions look totally insufficient to solve the "big" problems.

kzinti wrote:UEFI is great.

UEFI does a good job, I totally agree. But I hope you agree that calling it "great" is not objective: it's like for me saying that "Linux is great". Not a very objective statement, even if Linux is used everywhere. It's hard to make everyone agree on what "greatness" really is.

kzinti wrote: But it's still a huge improvement over the non-standard that is the BIOS.

I agree here. Even if it's designed with a very different taste than mine, writing an UEFI bootloader is way simpler than writing a legacy one. Also, UEFI is really powerful. For example, the ability to make a network connection is unimaginable with the old BIOS interface. And of course, I like a lot the standardization. Being able to use the same interface on all the UEFI-compatible machines is a big deal for me.

Finally, the increased difficulty in supporting both a legacy and a UEFI bootloader does not exist in the eyes of the big companies who created UEFI, simply because they don't care (while many of us do) about the older machines. Now they could simplify their code by just dropping the support for the legacy boot. Their world-view is: write code for recent machines and forget about the old legacy stuff. OSdev people with the same mindset could greatly simplify their bootloaders by supporting just UEFI, that is a simple fact.

kzinti wrote: Even if you don't like it, it is the present and the foreseeable future.

Correct.

Wellp, this thread has convinced me to use a bootloader! At least until I reach a stage I'm comfortable loading into ROM. Though I might just go for the ROM load; I'd have to on some systems.