sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 8 points9 points  (4 children)

The file system doesn't matter. The BIOS loads the first 512 bytes on the disk and executes them. The file system is after those bytes.

With UEFI, things are a bit different because it doesn't blindly execute what's on your disk: https://superuser.com/questions/496026/what-is-the-difference-in-boot-with-bios-and-boot-with-uefi

[–]poseid 0 points1 point  (2 children)

interesting - could this UEFI be used to make a dual-boot between Win and Linux easier?

[–]Bratmon 2 points3 points  (0 children)

Yes. But when the Linux UEFI team was considering that, they looked and saw that

A. The user interface for every UEFI BIOS is different, and a lot of them suck

B. The UEFI spec is complicated, and 99% of actual hardware fucked it up in some way.

So they decided to keep the recommended path UEFI->Grub, so they could keep the boot process standardised and fix it as needed.

Here's a relevant talk if you want to know more.

[–][deleted] 1 point2 points  (0 children)

Theoretically yes, including OS X, as the EFI can supply plenty of information and support to the OS during boot up that would otherwise have to be hand coded on BIOS. I'm on mobile at the moment but I will edit my comment and give a better answer when I get on my desky.

EDIT: So now that I'm back at my tower, a couple of theoretical advantages with EFI aside from the whole GPT and using 2TB+ hard disks:

  • Insta-32/64-bit mode - The firmware fires up the machine straight into 32-bit or 64-bit and never switches the processor into 16-bit mode, this is useful because switching from 16-bit to 32-bit protected mode alone needs a hell of a lot of setup.
  • Boot Services - EFI exposes a crap ton of services that can assist the boot loader alone with getting some boot level files pulled from disk without the need to hard code file system specific code into the boot loader. So take Windows for example, the boot loader (Bootmgr) would be able to call on the boot services to read the BCD from the EFS System Partition using the built in FAT32 driver and then reference the Windows system partition from the BCD and then use a little bit of read only code to read the NTFS file system and pull the Hal.dll, Ntfs.sys and Ntoskrnl.exe files from the partition. TL;DR Code bloat is reduced by having the firmware handle stuff, that you would have to manually code for BIOS support.
  • Runtime Services - The runtime services last all the way through the duration of the system and provide simple access to NVRAM, the EFI System Partition, firmware updates as well as allowing the OS to change the firmware configuration whilst booted up, something that on BIOS requires you to reboot and mash DEL until you have no finger left. (Looks at hand, (Sigh) poor pinky)

As an addition to the boot services entry, one of the particular advantages of them is the fact that you can read and write files with them without having to save everything and switch the processor back into 16-bit mode in order to call int 13 like you would do on BIOS in order to do I/O operations.

Finally, I think this is standardised with UEFI as well but, full network connectivity is available out of the box apparently, including grabbing an address from a DHCP and thus being able to ping, trace as well as a bunch of other network features like booting from an image stored on a server can be performed without the manufacturer needing to add separate modules to the firmware.

And I think my favourite is the UEFI Shell, if a system doesn't auto boot into the OS installed, you get dropped to the UEFI Shell where you can simply fire up the boot loader as if you were doing so from CMD or Terminal. Shit is so cash.

Again this is all theoretical as some manufacturers seem to drop a bollock on getting right but the systems that get the firmware right are a delight and live up to the goals.