rdos wrote:
I see no real difference in this area. It's a lot easier to load your OS image from the file system with UEFI than with BIOS.
Only if you want to use FAT. For all the other filesystems (ext2 for example) it is a lot more complicated.
rdos wrote:
You can just let UEFI do it with some simple calls, while with BIOS you need to parse the file system in the boot loader itself to find the OS image.
True, but parsing FAT to load a file is very simple, fits into 512 bytes easily (take a look at
MS-DOS VBR or
BootProg or
Bootf for example). Considering all the other additional complexity, I don't think it's a good trade... (Don't get me wrong, the idea that there's a firmware interface to load directly files from a partition is good, it is the actual implementation I have issues with. Your code using this "simple call" will be compiled unavoidably bigger than the BIOS counterpart, and it now has an additional dependency. It's not the sector read that you have to worry about, but also you can't know for sure if UEFI detects the file system correctly and able to load your file. I had issues with 12/16/32, so I had to waste disk space (several megabytes, about 10 times more than the actual useful data!) just to guarantee minimal number of clusters. This is completely a non-issue with BIOS boot sectors, where you always choose the appropriate code for the fs.)
rdos wrote:
I have tools to create both GPT and MBR partition schemes in the OS itself, and the complexity is not much different. The GPT solution is probably even simpler since I don't need to add specific boot sectors, rather I only need to put the efi-boot files and the OS image on the EFI system partition, which actually is a standard FAT32 partition.
Well, you must write the boot sector anyway (if nothing else for the partition table with 0xEF and the 0xAA55 magic), and manipulating FAT table is an additional complexity (admitted, not that hard, I solved it in
about 200 SLoC). My biggest issue with GPT is that it's full of unused and unnecessary data (seriously, has anyone ever used partition UNICODE16 names instead of drives, well, ever?) and you have to repeat it at the end of the disk, which means you must know the size of the resulting image in advance, or you must keep the entire thing in memory, or you must write in chunks using seeks. Not to mention the minimum size requirements for alignments and FAT32 cluster numbers, and the inconsistencies in the spec that leads to incompatible partitioning tools (seriously, no boot this partition flag? How come?).
These aren't big things, but it adds up, little by little up to the point where a beginner can't create a disk image on its own (not everybody is as experienced as you and me, for us creating GPT and FAT tools is a piece of cake, but that's not common). Now on top of all of that add Secure Boot to the mix, and a hobby OS developer is completely screwed.
rdos wrote:
My problem is more with building the efi boot file itself. It requires a Unix-like environment (I typically use cygwin). Since there are both 32-bit and 64-bit versions, I need to install both 32-bit and 64-bit cygwin. OTOH, I only build them once and then check the binaries into my SVN so it doesn't need to be part of the general build process.
I've never heard of that (UEFI requiring a Unix-like environment), but yeah, creating an efi file is a lot more problematic too, as I've said the interface (which implies MS-ABI capable compiler and PE output) is definitely adds considerable complexity to your toolchain.
sham1 wrote:
since the original question seems to have been handled rather conclusively.
You're absolutely right. We went quite off-topic, I'm sorry.
Cheers,
bzt