Deacon wrote:I think you meant POST, the power-on self test, which is driven by the CMOS, which is what you're in when you hit Del or F2 or whatever. You don't really interact directly with the BIOS. And if you got to the point where you were messing with the MBR for Windows to boot correctly, you were certainly getting past the POST.

collegestudent22 wrote:I pressed Del to enter the BIOS menu

FirebirdNC wrote:I know this topic was touched on a bit a couple of months ago but I need more detail. I got a new computer, I networked it to my old computer and transferred my files. Unfortunately a portion of my fairly large(800+) music library would not transfer. I kept getting messages saying files were in use or I didn't have admin rights to it. I didn't have the free time to mess with it so I ended up transferring what I could. What I would like to do is transfer what is on my ipod touch back to my new computer. Not only are the lost files an issue but I had finally gotten everything straight on my ipod (correct song name, artist, album cover etc) and I don't want to have to start from scratch. I see a lot of pay software to transfer from ipod to pc. Has anyone used any of them that they would recommend and even better does someone know of a free way to do it?

collegestudent22 wrote:CMOS is the hardware - actually refers to a type of transistor that makes up the chip where the firmware is stored. The BIOS is the software. Although, now it is a UEFI BIOS, but still. There is a reason that the screen displays a command to "Please press DEL to enter the BIOS menu".

UEFI stands for "Unified Extensible Firmware Interface", where "Firmware" is an ancient African word meaning "Why do something right when you can do it so wrong that children will weep and brave adults will cower before you", and "UEI" is Celtic for "We missed DOS so we burned it into your ROMs". The UEFI specification provides for runtime services (ie, another way for the operating system to be forced to depend on the firmware) and we rely on these for certain trivial tasks such as setting up the bootloader. But some hardware fails to work if we attempt to use these runtime services from physical mode, and so we have to switch into virtual mode. So far so dreadful.

The specification makes it clear that the operating system is free to do whatever it wants with boot services code after ExitBootServices() has been called. SetVirtualAddressMap() can't be called until ExitBootServices() has been. So, obviously, a whole bunch of EFI implementations call into boot services code when we do that. Since we've been charmingly naive and trusted that the specification may be somehow relevant to the real world, we've already stuffed a picture of a penguin or something in that address space. And just to make things more entertaining, we've also marked it non-executable.

This patch allocates the boot services regions during EFI init and makes sure that they're executable. Then, after SetVirtualAddressMap(), it discards them and everyone lives happily ever after. Except for the ones who have to work on EFI, who live sad lives haunted by the knowledge that someone's eventually going to write yet another firmware specification.

Martin Blank wrote:Since you're trying to be specific, it's UEFI, not UEFI BIOS. UEFI is a replacement for BIOS.

It's also apparently difficult to work with under the hood.