Boot into clover from non-standard boot device
tomwimmenhove opened this issue · 4 comments
I'm in the process of developing a expansion/option boot ROM (on a PCIe card) that would allow booting into Clover on PC's without EFI support. This ROM will use regular the BIOS Boot Specification to register a 'hard drive' number and hook into interrupt 0x13 in order to allow the BIOS to boot from it.
Everything seems tow work, except that Clover itself will not use the BIOS's boot device.
Is there any drive/option I can use in order for Clover to load itself from disk using legacy BIOS interrupt 0x13 calls?
This is a business of BIOS to choose what device to start. Then there should be small program like boot0af present in the Clover's project.
See WiKi. https://github.com/CloverHackyColor/CloverBootloader/wiki
@SergeySlice Thank you for your reply!
I think I should've given a little more information and context.
I've written an option ROM and I'm using qemu to test booting from it.
When I use the following:
$ qemu-system-x86_64 -m 6G -net none -drive file=../images/sdc,if=none,id=disk1 -device ide-hd,drive=disk1,bootindex=2 -option-rom rom_code.bin,bootindex=1 -drive file=/mnt/wd500/images/windows.img,if=none,id=nvm -device nvme,serial=deadbeef,drive=nvm,bootindex=3 -enable-kvm -serial tcp::4444,serverThe serial server (last arguments) is being used as a hack in order to read the actual data from my 'virtual hard drive'. The bootROM will communicate over the virtual serial port in order to read sectors from that virtual hard drive.
The other arguments: ../images/sdc is a Clover image, /mnt/wd500/images/windows.img is an actual Windows image and rom_code.bin is the binary of the bootROM I wrote. As you can see, I have attached a bootindex to each of them. The ROM has the first priority.
When the ROM is initialized (which it will be before any other hard drives, due to the boot order), it will register itself as the first, bootable, hard drive (BIOS hard drive ID 0x80). Then the BIOS uses it and reads the boot sector from it.
When I look at the output of the process that communicates through the virtual serial port, I can tell that the Clover boot loader is actually reading data from my virtual hard drive:
$ ./serserv
Connected to server
Read 1 sector(s) from 0
Read 2 sector(s) from 0
Read 3 sector(s) from 2048
...
Read 1 sector(s) from 20195
Read 1 sector(s) from 2196
At some point, it stops, and I'm greeted with the Clover GUI:
But when I boot the exact same way, without the clover image as the second hard drive, Clover, with the following qemu command:
$ qemu-system-x86_64 -m 6G -net none -option-rom rom_code.bin,bootindex=1 -drive file=/mnt/wd500/images/windows.img,if=none,id=nvm -device nvme,serial=deadbeef,drive=nvm,bootindex=2 -enable-kvm -serial tcp::4444,serverI still see the Clover bootloader loading the same sectors from the virtual hard disk, but it doesn't end up showing the Clover GUI. Instead it immediately drops to this:
So, it looks like Clover, at some point during the first and 'successful' boot, actually stops reading from the actual boot device (maybe it doesn't know how to read from a disk using legacy BIOS interrups 0x13 calls?), and switches to using the second hard drive.
Is there a way to make Clover only use legacy BIOS calls for the I/O it needs to load itself?
Second screen shows you GUI from the "boot" file located at the root of a partition.
Second step should be loading file "CloverX64.efi" from the same partition from folder /EFI/CLOVER/
Made the folder and place here the file.
Looks like resolved