MichaelPetch wrote:
mikegonta wrote:
This merely suggests that the BIOS examines the boot sector for the purpose of (automatically) "emulating" the USB device.
That may be the case on some BIOSes for some people with regards to their bootloaders, but what is being observed by people is real in a lot of cases now. I should know, I have a Lenovo Laptop that does the exact same thing.
The way this usually plays out now is that someone says their bootloader starts but it prints something out incorrectly or doesn't work as expected (like a disk read fails). In most of these cases now It isn't that their BIOS failed to be recognize it as bootable media, it recognized it as bootable and started running it and basic code failed. What happens is that on an increasing number of machines now the BIOS is BLINDLY writing the drive geometry into memory when booting as USB FDD where it thinks there is a BPB present. The behaviour of what happens because of that is undefined but often overwrites instructions and has the code do something unexpected. That SO answer you pointed to is mine, and if you'll note there is code to dump the bootloader memory out to see if any bytes have changed. In the cases where this issue is a problem the bootloader I wrote will display different values in the bytes that get overwritten.
I'm not saying that the BIOS doesn't sometimes overwrite the in memory BBP, I only said that your references didn't prove it and could be interpreted differently. Now you are providing proof which I can accept. (I didn't read your answer and I was referring to the SO user's remarks).
I do however, have a suitable explanation which should satisfy all concerned.
I agree with you, the BIOS is in some cases, overwriting the BPB, but this only goes to prove that you cannot use the FAT12 geometry in the BPB as parameters to INT 0x13 calls when using a USB device. I guess those BIOS assume that every one is a dummy and will blindly use FAT12 geometry on a non floppy disk. So to help us poor
soles (boot sector people) out, it will quietly update the parameters to the "correct" values.
The correct way to access FAT12 formatted media that is not a real floppy disk (and yes, real floppy disks can still be booted on newer equipment (with a CSM UEFI BIOS using a USB floppy disk drive) is to use INT 0x13, AH=0x48 Get Drive Parameters (which in most cases will be the same as the BPB, or as in these cases - will be what the BIOS wants to use. And yes, you can use the INT 0x13 Extensions with real floppy disks booted from a USB floppy disk drive.
MichaelPetch wrote:
So please don't tell me this isn't a real issue. As I said in my comment just before this, I now have a canned set of questions whenever I see USB boot on real media where a bootloader starts running but doesn't do what is expected. This situation is now the single biggest headache I have to help people on SO for bootloader problems. I don't even write answers, I ask these questions in the comments, tell them to read that answer, they add their BPB and the code now works as expected. I provide an actual BPB, but it appears you just need a SHORT JMP, NOP, minimal sized BPB filled with zeros if you aren't actually using a file system like FAT).
A near jump will also work. This requirement was first documented in the original IBM PC BIOS source code.
To be on the safe side, a BPB filled with zeros should not be used. I have observed that on an older PC (that supported USB booting) the BIOS used the BPB values to calculate (to be used later) LBA info that resulted in the PC quietly hanging after an unhandled divide by zero CPU exception.