Broken UEFI implementations: Difference between revisions

m
Add links
[unchecked revision][unchecked revision]
m (fix spelling mistake)
m (Add links)
Line 3:
= El Torito boot =
 
UEFI boot from CD is controlled using [[El Torito]] boot records in the CD headers. Some machines get this wrong. In particular, one common set of known issues stem from early CSM packages which don't correctly interpret multiple El Torito boot catalog entries. The most common failure is the CSM's parser not recognizing the 0xEF platform ID, and instead of interpreting "I don't know this platform ID" correctly as "This is not for my platform" when there are multiple boot entries, some versions present you with a menu:<pre>1.
2.
Select CD-ROM boot type:</pre>
Line 9:
 
= BGRT Table =
* BGRT is an [[ACPI]] table to tell us if and where UEFI firmware has drawn its logo on the screen. Technically, the BGRT is an ACPI 5 table, but its use corresponds with UEFI 2.4 deployments, and it goes hand in hand with the EFI Graphics Output Protocol and ESRT + UEFI UpdateCapsule and [[https://msdn.microsoft.com/en-us/library/dn917814%28v=vs.85%29.aspx Microsoft's firmware update graphics capsule]]. In theory, "uint16_t version" (offset 0x24) should always be 1, and "uint8_t status" (offset 0x26) with 0x1 set means "valid data" - that is, if the firmware displayed a splash graphic, it sets the values in the table and sets status to 1; if not, status should be 0.
 
Here are some sample entries. These are from real machines, but the problems are common across lots of hardware from lots of vendors:
Anonymous user