OSDev.org

zaval, this is a forum warning. This is inappropriate behavior and won't be tolerated. No opinion on the technical matters discussed here.

Sorry again. Sorry Octacone for calling your rant "butthurting", "bullshit" and "brilliance". It was nothing of that. I should have been discussing only technical matters without using prologs abounding with inappropriate metaphors.

Nobody is forcing you to do anything. But at the same time, you aren't forcing them to keep producing the same broken firmware in their computers for all eternity.

You know, class 3 is already the end game. You have successfully ignored UEFI for 15 years and now it is biting you. You were supposed to use that time to build a boot loader that gets you from the UEFI entry point to the kernel entry point, but no, BIOS fossil it is for you. Well if you're so content to live in the past, why do you want new computers in the first place?



Nobody is stopping you from building a UEFI boot loader that calls ExitBootServices() and drops to 32-bit mode.
Nobody is stopping you from building a UEFI boot loader that emulates BIOS using UEFI, and uses that to run DOS. Except maybe time.
There is nothing good about old BIOS!
You can use whatever FS you want except in the UEFI system partition. Think of the system partition as a modern boot sector and basically nothing changes.
V8086 mode was a hack to support VESA in 32-bit OSes. No need for that when you have UEFI's graphics protocols, which actually tend to work these days. Besides, 32-bit mode is still possible, see above.
As for the RTOS, that one depends on the needs of that OS.


Then make a 64-bit boot loader that drops into 32-bit mode. My god, do I have to think of everything? It isn't hard. If you actually built a bootloader for BIOS, building one for UEFI should be a task you can accomplish in an afternoon. You just call functions instead of interrupts.


Yes, your entire bootloader. Because that's the herculean task, is it? Rewriting the thing that loads a file into memory, maybe fetches some system info, then jumps to the file. It is not insurmountable. You can even do it in C now. Which means you can compile it for 32 and 64 bit, and use it for UEFI on both kinds of machine.

I honestly don't get why you're so freaked out. You were already using code from some BIOS oligopoly (What, we have AMI, Award, and Phoenix? Anyone else?) defined by some other monopoly (namely IBM). So now its another firmware oligopoly (consisting of Phoenix/Intel, AMI, and Insyde) and the specification this time around is open and published instead of reverse engineered. I only see upsides.


Bunk, see above.


You've laid your foundations on BIOS? Then you built on sand, and you knew that for at least 20 years now. I think I can contain my sympathy here. Oh, and 64-bit PCs are a thing for something like 15 years now.

VESA support has been getting spottier every generation of graphics card. It was obvious that it would not be around for much longer, and we'd all have to get used to writing graphics card drivers to even get a framebuffer. Other than VESA I can't think of a single thing I'd ever want BIOS support for in my OS.

Also, there is no behavior to override. In a class 3 machine, the firmware simply does not contain the BIOS code. The only way to get it, therefore, is to get a firmware that reverts the machine to class 2. Good luck with that! Your options are the mainboard vendor, or the coreboot people.

Ciao,
Markus

The "well, actually..." here is that Intel are almost certainly dropping support for both real mode and 32-bit protected mode in the near future.

And why not? There is no good reason for anyone to continue using those (outside of emulation), since most current software isn't 32-bit specific at all - even the majority of Windows software is written in a way that the developers can easily recompile for either 32-bit or 64-bit, or even ignore the issue entirely and not depend on x86 directly at all (which is why MS has pushed .Net so heavily for so long, after all). Hell, the majority if current application software is interpreted - often badly, admittedly as the translators for Javascript and PHP (the real disaster, sorry I meant dominant, languages of the past two decades), are generally implemented in an idiotic fashion - and thus it doesn't matter if it is on x86, x86-64, ARM, a 6502 with tons of bank-switched memory, or even Geri's OISC pipedream. And trust me, more software has been written in the past ten years than in the previous fifty.

It is also against Intel's interests to continue supporting 16 and 32 bit code, because it wastes chip real estate they could be use for more superscalar instruction manipulations (not a lot, admittedly, or they would have been more aggressive about it long before now, but enough to want to eliminate them).

I mean, really, all of the 'x86' and x86-64' code is already basically emulated (via dynamic translation of the same sort QEMU uses, just in firmware) on some internal register-window RISC system rather than run in hardware anyway; there's no point in having that in hardware when software emulation makes for a more flexible method of running that code, and removing it fixes a lot of lingering headaches for them.

Getting rid of x86 entirely would be even better for them, and frankly, I am quite sure they are champing at the bit to do that. But as I have said many times before, that would present its own set of problems, which is why they didn't do it yet.

Of course, that says nothing about systems software, nor about retro fans who want to run older programs with no modern equivalent (though many of those would have had to be emulated even when BIOS was dominant, if only for timing issues and/or because they used privileged operations). Octocone is right, the standards do not take minor, hobbyist OSes into account.

And you know what? They never did. The fact that we've been able to do this at all, the fact that Linux and FreeBSD and several other non-Microsoft - or rather, non-Digital Research - operating systems are even possible, came out of a mistake IBM made - one I am glad for, one which sent Big Blue's genuine monopoly to the trash bin of history where it belonged, but a mistake nonetheless. Had they been thinking, they would have locked the PC down into using CP/M-86, and none of this would be a question because either there would only be CP/M, or more likely, the PC would have faded into obscurity and some other company - Apple, perhaps - would have the market and have actually locked out alternative OSes.

The point I am making is that there is no incentive, fiscally, for them to cater to us, and every incentive to try and squash up like bugs. I am not talking about Microsoft here; MS is the friend nobody likes, and if Intel could push them off a cliff, they would. But it is against Intel and AMD's's financial interests to support any and all comers - that cannot do anything but make their products ans support services unprofitable, which would end the game outright for the PC market.

Finally: Zaval and DiggDug were talking about different things. What DiggDugg was referring to as 'where UEFI is' would have been more clearly stated as 'where the partition-specific start-up data resides', not 'where the UEFI firmware binary resides'.

Zaval read that far too literally. I suspect this was deliberatel, for the sake of provocation, but I can't be certain if this is the case or not.

So we are talking about the UEFI system partition - that is to say, in the dedicated, single-purpose system partition meant to contain only the \EFI\ directory - a partition that should be used only for that purpose, which is why it is only 100MiB in the first place. My understanding is that the only programs that should ever touch that partition at all are the UEFI firmware itself, and the OS installer and updater tools, and the only things that should be in it are the *.efi definition files, and possibly one or more rump file system drivers (not in the hardware sense, of course, but you get what I mean, I hope) for the UEFI loader to use.

This is important, because both DiggDug and Octocone seem to have missed this, so to reiterate: putting your OS on the UEFI system partition is Doing It Wrong™.

As best as I can determine, DiggDugg and Octocone also missed another important detail about the UEFi system partition - the UEFI docs as quoted earlier state that the system partition is in a unique file format derived from FAT. My impression from that wording is that, while is similar to FAT32, it isn't actually FAT-compatible. This was probably intentional, to discourage people from, you know, using that partition for something other than what it is there for.

It doesn't matter, however, since as I just noted, this partition is only used by UEFI itself (and the OS installer program), and only to hold information about the booting process for the other partitions. The standard says nothing about the other partitions' formats, only that (IIUC) there must be at least one partition other than the system partition (there is also the GPT, but that, like the older MBR, is separate from all of the partitions) I am not sure if it says this outright, but AFAICT, that is the intention.

Oh, and that the x86-64 UEFI firmware must have direct support for FAT, because at the time the standard process began, that was the lowest common denominator. They can add different file-system specific drivers as well, and (again, IIUC) the UEFI firmware can be interrogated by the OS installer to see what drivers it has, so that the installer doesn't need to use their own - but they can always use their own anyway.

I am pretty sure that if MS themselves has chosen things, they would have said NTFS - after all, Windows has defaulted to that since XP... Indeed, my understanding is that most x86-64 UEFI firmware implementations support NTFS and ext4 out of the box. Because as long as they also support FAT, there is nothing to stop them from supporting any others that they find it useful to support, and both Intel and AMD find ext4 and NTFS useful. And all of that is just a sop to the system implementors - it is always possible to write your own drivers for the *.efi file to use.

At least, this is my reading of it. Comments and corrections welcome.

You keep saying that and somehow it still has not happened. Of course, cutting off old hair is a good idea in my book.



Not quite sure what you mean here. The entire aarchitecture or just the 32-bit part? Because the former would obviate Intel's and AMD's raison d'etre, which I don't think they would like very much.



That one I really don't get. Independent OS development can't both be so insignificant as to be unworthy of consideration and so much of a nuissance as to kill AMD and Intel.


As a rule, I don't speculate on people's motives.


Not my understanding at all. To my knowledge, the SP should contain the bootloaders and all the files they need to load the system. It is perfectly valid to, say, install a kernel image and an initrd into the EFI partition. Honestly, what could go wrong?



The first point I totally agree. Though... today's MS does not appear to be the Evil Empire they were back in the 2000s. Maybe they wouldn't have done that, after all.

The second is news to me, but I haven't gone that deep into implementation yet. But I fail to see how the added complexity of such support would benefit anyone. Bootloaders still would have to re-implement file systems, since NTFS and ext2 support is not guaranteed, and also, these reimplementations exist already (in efi-grub). So it would only be of use to the firmware itself, which never has to load anything from disk, except from the system partition, that is likely going to be FAT.

Just to clarify, you misunderstood me. In fact, I said no such thing. No where in the tutorial do I suggest to keep your OS on the 100 Meg Partition. That would make no sense what-so-ever. In fact, I clarify this fact in a later post. I spoke about how you could format another partition for your OS. And just have the EFI file point to the other partition.

Besides, the tutorial was about how to boot off of USB under a UEFI Class 3 computer, not how to load your OS. That is up to the designer.

Ah, OK, I apologize for misreading this, and for the other missteps I made in that post.