#15587: Regression finding Haiku partition after GNU-EFI removal
--------------------------------------+----------------------------
Reporter: tqh | Owner: jessicah
Type: bug | Status: assigned
Priority: blocker | Milestone: R1/beta2
Component: System/Boot Loader/EFI | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
--------------------------------------+----------------------------
Comment (by oco):
During the coding sprint, i have spend some time on the UEFI stuff,
mostly to understand things and maybe to help as a side effect.
I have already made some UEFI application with... Freepascal ! But not
much beyond an hello world !
After adding a lot of trace (and thanks to pulkomandy's trace log he fixed
on monday), i was able to somewhat figure how it works.
If i have understood things correctly, we search for the device path of
the partition from where the UEFI bootloader was launched. This device
path is constituted of different nodes identifying the links from the PCI
bus to the partition.
With current source, the found device path end on the EFI partition
(fat32). Haiku use his own partition parsing, so it need to have a BlockIO
over the full disk, not on the partition where is located the UEFI boot
loader.
The removed code in https://git.haiku-os.org/haiku/tag/?h=hrev53645 was
probably hacking the device path to stop it at the drive level (with
special values to end the path node chain).
Maybe, in QEMU, it was done directly on an internal structure, that is no
more accessible ?
I have use an UEFI protocol (efi_device_path_utilities_protocol) that
contains a function to duplicate a full device path (with all it's nodes)
and then editing the last node to end the chain before the partition part.
I finally use this new device path to ask for a BlockIO.
It looks like it work on real hardware and in QEMU.
My patch still need some work (really quick and dirty). It need a more
repeatable algorithm to end the device path at the right place (it is
fixed for my laptop currently).
I have also used the UEFI PathToText service to get more human readable
representations of device patch in my investigations like this :
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0).
We maybe should use them more and get them in our log file. It still need
a function to convert char16_t (native string format in UEFI) to char
ascii though. I end up using UEFI fonction to write them on the UEFI
console (with a wait on keystroke to be able to see them).
--
Ticket URL: <https://dev.haiku-os.org/ticket/15587#comment:44>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
