Page 4 of 5
Re: UEFI Wiki updates
Posted: Sat Sep 26, 2020 5:04 pm
by zaval
You are clearly contradicting yourself here. You said it yourself that GOP might not be present. Therefore GOP is optional. But what a much bigger problem is, there's no guarantee that you'll get EFI_SIMPLE_FILE_PROTOCOL or EFI_BLOCKIO_PROTOCOL. How do you load an OS if LocateProtocol returns NULL for those? (I would say DISKIO_PROTOCOL, but that never even worked for me on a real hw.)
so, you say, you are creating an OS and yet don't understand what a conditional requiement is?
how does it feel to pretend to not understand lines like these:
3. If a platform includes graphical console devices, then the
EFI_GRAPHICS_OUTPUT_PROTOCOL, EFI_EDID_DISCOVERED_PROTOCOL, and
EFI_EDID_ACTIVE_PROTOCOL must be implemented. In order to support the
EFI_GRAPHICS_OUTPUT_PROTOCOL, a platform must contain a driver to consume
EFI_GRAPHICS_OUTPUT_PROTOCOL and produce
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL even if the
EFI_GRAPHICS_OUTPUT_PROTOCOL is produced by an external driver.
4. If a platform includes a pointer device as part of its console support, the
EFI_SIMPLE_POINTER_PROTOCOL must be implemented.
5. If a platform includes the ability to boot from a disk device, then the
EFI_BLOCK_IO_PROTOCOL, the EFI_DISK_IO_PROTOCOL, the
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, and the
EFI_UNICODE_COLLATION_PROTOCOL are required. In addition, partition support for
MBR, GPT, and El Torito must be implemented. For disk devices supporting the security
commands of the SPC-4 or ATA8-ACS command set, the
EFI_STORAGE_SECURITY_COMMAND_PROTOCOL is also required._An external driver may
produce the Block I/O Protocol and the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL.
All other protocols required to boot from a disk device must be carried as part of the platform.
just to look "right" in your own eyes?
Oh, why do I even bother answering you? We all know you're a payed Microsoft troll, you're deaf to reasoning.
I safely can assume, that everyone takes similar to the quoted talks of you with understanding, after your revelations about Terry Davis, or Reiser. At least I do.
I didn't create this thread just to turn into another bzt vs. zaval war. bzt doesn't care for UEFI and Microsoft, zaval loves them both. They really should just add each other to there foes list. Before this gets out of hand, it might be a good idea to lock this thread.
you overestimated my enthusiasm, nexos. see, bzt just wrote another portion of uhm... "incorrect things" about UEFI and all I wanted, was to point out to his errors. Like for example his dreaming about the "ambiguously defined" number of partitions in GPT. after all, bzt is making a UEFI loader, that some poor ones could even use, isn't my desire to correct his numerous misunderstandings a noble goal - those users will pull less hair off their heads, when dealing with bzt "loader" as result.
Re: UEFI Wiki updates
Posted: Sun Sep 27, 2020 9:51 am
by testjz
A little correction from 2 pages before...
bzt wrote:zaval wrote:PI really has a lot of overdesigned stuff, but UEFI is slim. and extensible.
No, it isn't. OVMF.fd is at least a Megabyte (!!!) and in run-time requires several Megabytes of RAM, I wouldn't call that "slim". BIOS, on the other hand, with it's 128K size and minimal (ca. 64k) run-time RAM requirement, now that's what slim is!
The Bochs/QEMU BIOS is 128k. A BIOS for a "real" 2006-class computer is upwards to 2M. For example, if I recall correctly, the Libreboot ROM image for the ThinkPad T60 is 1M or 2M. And it doesn't implement UEFI, nor PC compatibles had UEFI in 2006.
Re: UEFI Wiki updates
Posted: Sun Sep 27, 2020 11:00 am
by bzt
testjz wrote:The Bochs/QEMU BIOS is 128k. A BIOS for a "real" 2006-class computer is upwards to 2M. For example, if I recall correctly, the Libreboot ROM image for the ThinkPad T60 is 1M or 2M. And it doesn't implement UEFI, nor PC compatibles had UEFI in 2006.
BIOS on a real machine is restricted to the memory area 640K - 1024K (0xA0000 - 0xFFFFF). Some of these addresses are MMIO, the actual ROM is even smaller 256k tops (see
here and
here and
here). There's simply not enough ROM in an IBM PC to store 1M of BIOS code. The original IBM PC couldn't handle more than 1M memory altogether! That's why you must enable the A20 line.
If the ThinkPad used more ROM than that, then you cannot call it IBM PC compatible. And indeed, Libreboot says
here: "Libreboot is a coreboot distribution".
Cheers,
bzt
Re: UEFI Wiki updates
Posted: Mon Sep 28, 2020 12:11 am
by Octocontrabass
bzt wrote:BIOS on a real machine is restricted to the memory area 640K - 1024K (0xA0000 - 0xFFFFF). Some of these addresses are MMIO, the actual ROM is even smaller 256k tops (see
here and
here and
here).
Two of those three sources list BIOS a second time, up near the 4GiB mark, where there is plenty of room for more ROM.
bzt wrote:There's simply not enough ROM in an IBM PC to store 1M of BIOS code. The original IBM PC couldn't handle more than 1M memory altogether!
My ASRock M3A770DE has a 1MiB BIOS ROM.
You can download a copy and see for yourself. (In fact, the ROM on the board might be even bigger than 1MiB, but I can't take it apart right now to check.)
Re: UEFI Wiki updates
Posted: Mon Sep 28, 2020 6:22 am
by bzt
Octocontrabass wrote:bzt wrote:There's simply not enough ROM in an IBM PC to store 1M of BIOS code. The original IBM PC couldn't handle more than 1M memory altogether!
My ASRock M3A770DE has a 1MiB BIOS ROM.
You can download a copy and see for yourself. (In fact, the ROM on the board might be even bigger than 1MiB, but I can't take it apart right now to check.)
And? What's your point? I've said BIOS can be small, and that for the original IBM PC BIOS it had to be smaller than 1M (64k to be precise, 256k with Option ROMs). On the other hand no UEFI implementation could ever fit in 256k (let alone 64k).
The point is, it is possible to have a slim BIOS (64k versions definitely exist), but it is not possible to have a slim UEFI (no versions are smaller than 1M). Just because there are some badly written and bloated BIOSes, doesn't change this... We're comparing the minimum sizes of both worlds. And that's 64k versus 1M.
Cheers,
bzt
Re: UEFI Wiki updates
Posted: Mon Sep 28, 2020 9:12 am
by nullplan
Let's read that again, shall we?
bzt wrote:BIOS on a real machine is restricted to the memory area 640K - 1024K (0xA0000 - 0xFFFFF).[...]
Octocontrabass wrote:My ASRock M3A770DE has a 1MiB BIOS ROM.[...]
bzt wrote:And? What's your point? I've said BIOS can be small,[...]
No, you said it
is restricted to those 384kB. Not that it can be, but that it must be. Of course, it isn't. The 640kB boundary itself is an arbitrary decision. Unless you plan to run DOS, nobody cares about that one at all.
BIOS is not limited to any size at all (except, of course, for how much the manufacturer wants to pay for ROM). It could, in theory, be 4GB in size, or even larger (it would then have to switch to 64-bit long mode to access that memory, but it could, in theory, happen). And, as long as some RAM is mapped over the low 1MB area, and some memory is allowed to be mapped over for PCI MMIO below 4GB, you would not even notice.
Re: UEFI Wiki updates
Posted: Mon Sep 28, 2020 9:14 pm
by bzt
nullplan wrote:No, you said it is restricted to those 384kB. Not that it can be, but that it must be.
And that's true. Look it's plain simple: BIOS uses real mode. You simply cannot address more than 1M memory in real mode. 0 to 10FFF0 (1M+64k-16) to be exact. In that address space, there's only that much ROM, no more.
nullplan wrote:BIOS is not limited to any size at all (except, of course, for how much the manufacturer wants to pay for ROM).
So you think that everything that's in ROM is BIOS? You're mistaken. Just because BIOS is also stored in ROM, doesn't mean there can be only BIOS in ROM.
But if you don't believe me, read the docs!
BIOS Technical Reference
BIOS Boot Specification
They are pretty clear that BIOS must use real mode, and in addition BBS allows 16-bit protected mode for Option ROMs, but that's it. No 32 bit protected mode, therefore no addressing above 1M in BIOS. (Of course a ROM code can switch to protected mode and access memory above 1M, but then you
can't call that standard IBM PC BIOS)
Cheers,
bzt
Re: UEFI Wiki updates
Posted: Mon Sep 28, 2020 9:44 pm
by nullplan
bzt wrote:So you think that everything that's in ROM is BIOS? You're mistaken. Just because BIOS is also stored in ROM, doesn't mean there can be only BIOS in ROM.
I get it now, we're talking past each other. I was about to bring up that the reset value for CS.Base is 0xFFFF0000 and that BIOS therefore operates in some unreal mode, and how the first of the documents you provided isn't normative, but then I found the actual problem: We mean different things when we say BIOS. I mean all of the firmware, all the code that runs from Power-On till boot loader, plus the interrupt interface. You apparently just mean the actual boot code and the interrupt interface. Yes, that stuff is limited to the legacy PC memory area. It is also just a small part of the firmware.
Re: UEFI Wiki updates
Posted: Mon Sep 28, 2020 9:51 pm
by kzinti
There is nothing preventing the BIOS from switching to protected mode and do whatever it wants and then go back to real mode (or as nullplan suggests, unreal mode). Pretty sure some video cards used to do that (and might still be) because there simply isn't enough space to map their firmware in low memory. If video cards can do it, so can other pieces of hardware, including the motherboard with the BIOS.
Re: UEFI Wiki updates
Posted: Mon Sep 28, 2020 10:07 pm
by Octocontrabass
How does INT 15h AH=87h work without switching to protected mode?
Re: UEFI Wiki updates
Posted: Tue Sep 29, 2020 8:55 am
by bzt
Now you're just trolling.
Octocontrabass wrote:How does INT 15h AH=87h work without switching to protected mode?
Why is there a need for a real mode service to copy blocks to conventional memory in the first place? Have you thought about that? INT 15h AH=87h works exactly as a secondary storage load/save service. Same as with
EMS and
XMS. Neither can execute code above 1M.
Linus wrote:And don't get me wrong - the problem
with EFI is that it actually superficially looks much better than the
BIOS, but in practice it ends up being one of those things where it has
few real advantages, and often just a lot of extra complexity because of
the "new and improved" interfaces that were largely defined by a
committee.
...
So EFI has this cool shell, a loadable driver framework, and other nice
features. Where "nice" obviously means "much more complex than the simple
things they designed in the late seventies back when people were stupid
and just wanted things to work".
Obviously you are more experienced than Linus, and your hobby OS is more successful than Linux... (sarcasm)
Look, if you are fool enough to think that UEFI is not overcomplicated and it's simpler and slimmer than BIOS, so be it! It's on you.
Cheers,
bzt
Re: UEFI Wiki updates
Posted: Tue Sep 29, 2020 9:17 am
by iansjack
bzt wrote:Look, if you are fool enough to think that UEFI is not overcomplicated and it's simpler and slimmer than BIOS, so be it! It's on you.
bzt
It really doesn't matter what you, or Linus (not always known for making the most coherent argument), think. The reality is that UEFI is here to stay and, increasingly, it's the only option for X86 computers.
Learn to live with it.
Re: UEFI Wiki updates
Posted: Tue Sep 29, 2020 9:22 am
by nexos
BIOS must use unreal mode. My desktop with BIOS has ACPI reclaim memory above 0xC0000000. So, BIOS had to put it there. So it went into unreal mode. I take what Linus said as a grain of salt, as he is, well, pessimistic about Intel and created a bloated kernel, so he is a good one to talk about complexity.
Re: UEFI Wiki updates
Posted: Tue Sep 29, 2020 10:34 am
by bzt
iansjack wrote:Learn to live with it.
You are telling this to the wrong person. My boot loader is not only UEFI capable, but works with Secure Boot too.
However there are FOSS alternatives. Nobody stops you from contributing to coreboot for example. It's lightyears better than any UEFI, only downside is smaller hardware support ATM, but it's constantly developed. I'd dare to say as of 2020 it's already more supported on ARM than UEFI (Apple ARM might change this, but we'll see).
nexos wrote:I take what Linus said as a grain of salt, as he is, well, pessimistic about Intel
He's not wrong about this though.
nexos wrote:created a bloated kernel, so he is a good one to talk about complexity.
Nope, he didn't made it bloated.
Intel and RH did (being the top contribs for more than 10 years in a row now). Linus wrote less than 4% of the commits in 2019. If anything, he was and is
always against bloat.
Full report.
Cheers,
bzt
Re: UEFI Wiki updates
Posted: Tue Sep 29, 2020 12:26 pm
by nexos
Alright, Linus didn't make it bloated. But I still wouldn't take what he says. For example, he stepped down from Linux a while back to cleanup his language, and to improve his leadership style. I would hardly say he has good control over the kernel. He could have helped prevent the bloat Red Hat and Intel caused. Instead, he was to busy ranting about ACPI, EFI, and AVX-512. This thread was intended to talk about updating the wiki for UEFI. And now we are discussing Linus Torvalds? Interesting. I have said it before, and this thread should be locked.