Add UEFI loader

[X512]

Some new 32 bit x86 tablets came with UEFI firmware without legacy MBR boot support. UEFI boot loader is required to boot Haiku on that systems.

[X512]

Example tablet ​http://shop.lenovo.com/us/en/tablets/thinkpad/thinkpad-tablet-2/

[tqh]

I'd be interested to know if it is 32 bit or 64 bit UEFI firmware. If someone has one it would probably be doable by examining a EFI app for it, or test a 32 and 64 bit app and see what runs.

See ​https://github.com/tqh/efi-example for EFI info. And ​https://github.com/tqh/haiku/tree/efi Atm working in a local efi_pm branch, if anyone wants to help out let me know.

[X512]

This ticket is about 32 bit systems. I have no working Linux, so please provide binaries to test.

[tqh]

This will have to wait until UEFI bootloader is in working state. Unfortunately that will probably take time.

It would have been good to have an known example where UEFI firmware is 32 bit, but providing a 32 bit version later won't be that complicated.

[waddlesplash]

tqh: any update? I know you've been busy but maybe at least providing a TODO list and a where-to-start if other people want to pick this project up would be a good idea.

[tqh]

I'm not really involved in it at the moment. Jessica and the GSoC wiki should have the latest info. Feel free to ask me though. I have another thing on my todo-list that I'm working on, just don't have enough time.

[pulkomandy]

R1 target is "IBM PC compatible" and that doesn't include UEFI. Feel free to fix it anyway, but removing from #7665.

[modeenf]

Any one tested Lamina T-701? its an Tablet for about $80 (799:- swedish) x86 tablet with 1 GB ram and 16 GB hdd.

Now that one can get it for about $88 it's really interesting to run Haiku on it :)

[richienyhus]

Replying to modeenf:

Any one tested Lamina T-701? its an Tablet for about $80 (799:- swedish) x86 tablet with 1 GB ram and 16 GB hdd.

Now that one can get it for about $88 it's really interesting to run Haiku on it :)

Intresting. It has the same spec as the ​sharkscove development board, only a hell of a lot cheaper.

The ​MinnowBoard Max development board is another alternative for people wanting to work on UEFI.

[modeenf]

I bought on :) could not resist :)

Windows 8.1 are running realy well (only testing the web and Netflix), I also get Office one year. I can get in to BIOS but I can't get it to boot from an USB (Windows or EFI shell). I hope I doing somthing wrong but there are not many out there trying to get windows or FreeBSD on it and thats odd.

Oh and It dropes Wlan from time to time but inactivate wlan and activate it again fixes that.

[tqh]

If it can do UEFI boot you can try to create a EFI/BOOT dir and have any EFI app named bootx64.efi (x64 if it is a 64 bit processor). The filesystem should be one of the FAT types and you may need to mark the partition as bootable.

[modeenf]

Replying to tqh:

If it can do UEFI boot you can try to create a EFI/BOOT dir and have any EFI app named bootx64.efi (x64 if it is a 64 bit processor). The filesystem should be one of the FAT types and you may need to mark the partition as bootable.

Are we talking within Haiku or in general? I will Google this and se how I can make a uefi bootable USB 😃

[kallisti5]

jessicah: Merge your UEFI work! :-)

[wesleym]

Is said work published somewhere?

[pulkomandy]

​https://github.com/jessicah/haiku ​https://github.com/jessicah/haiku-private

[kallisti5]

As of hrev51183, we are really close to having UEFI. UEFI actually already works in anyboot images.

The last big issue is getting our build system to compile BIOS as well as EFI loaders. (which is going to require quite a bit of Jam work) Following the steps below will get you a haiku anyboot iso which will boot:

• Using as a CD MBR : Bootable
• Using as a CD EFI : Not yet (we need the correct El-Torito EFI in our fake iso)
• Using as a HDD/USB Flash MBR : Bootable
• Using as a HDD/USB Flash EFI : Bootable

Creating an UEFI bootable image (we need to automate these in jam)

• HAIKU_BOOT_PLATFORM=efi jam -q haiku_loader.efi
• dd if=/dev/zero of=~/efi.img bs=$((1024*1024)) count=16
• mkfs.msdos ~/efi.img
• mkdir /tmp/efi
• mount ~/efi.img /tmp/efi
• mkdir -p /tmp/efi/EFI/BOOT
• cp haiku_loader.efi /tmp/efi/EFI/BOOT/BOOTX64.EFI
• umount /tmp/efi

Adding your EFI filesystem:

• edit build/jam/images/AnybootImage
  • change:

$(2[1]) -b $(2[2]) $(2[3]) $(2[4]) $(1)

• to:

$(2[1]) -b $(2[2]) -e /home/myuser/efi.img $(2[3]) $(2[4]) $(1)

jam -q @nightly-anyboot

I added a flag to the anyboot generation tool a while ago to also inject an EFI filesystem.

[pulkomandy]

• you can use bs=1M to avoid a bashism here.
• mkfs.msdos may not always be available (is it named like this on Haiku?)
• mounting may not be allowed for regular users on some systems
• so, it may be a better option to use dosfstools (which can manipulate a disk image without mounting it) - aren't the ARM build scripts doing this already?

[kallisti5]

all correct. I was mostly documenting how I create the EFI images currently :-)

A lot of jam work needs to be done around this. You have to make sure you:

• build both EFI and BIOS loaders. (right now it is one or the other via HAIKU_BOOT_PLATFORM)
• create the EFI filesystem after the EFI loader and inject our EFI loader into it.
• create the anyboot image after the process above has been completed.

One reason I haven't worked on any of this yet is that after all these years, Jam still is an enigma to me. (especially complex dependencies)

[pulkomandy]

Not sure what's "complex" about the dependencies here.

To declare a dependency in Jam you just use "Depends" in the rule: ​http://cgit.haiku-os.org/haiku/tree/build/jam/images/AnybootImage#n13

And instead of hardcoding the path to your file in a random command line, you pass it when invoking the action from the rule: ​http://cgit.haiku-os.org/haiku/tree/build/jam/images/AnybootImage#n15

    # Yes, this is totally readable and it's easy to understand what's going on
    $(2[1]) -b $(2[2]) -e $(2[5]) $(2[3]) $(2[4]) $(1)

You then of course adjust the invokation of the rule: ​http://cgit.haiku-os.org/haiku/tree/build/jam/images/AnybootImage#n27

This rule uses "located" targets. Unlike make and most other tools, the "location" of a target does not depend on where the file is actually stored, but you don't have to care about it, just use MakeLocate which sets both the path and the identifier.

We will need a separate rule/action to create the EFI filesystem. Probably we can take some inspiration from the ARM build rules as IIRC they are doing this already: ​http://cgit.haiku-os.org/haiku/tree/src/system/boot/platform/u-boot/Jamfile#n168 (btw, most of this file should be moved to build/jam/image).

Then all what's left is that HAIKU_BOOT_PLATFORM thing. I'm not sure why this is needed, it should be possible to compile the same sources multiple times as long as different grists are used. The MultiArch* rules do that automatically, but it's possible to do it in other ways as well.

[tqh]

Yes, I think it will not be that hard to do. When I created the jam-files for UEFI I actually thought about how it should work. Build the UEFI-bootloader as a secondary boot target. Then add the bootloader to the Haiku image (so you can install the bootloader later). For bootable images also add a EFI system-partition with the bootloader.

We also need an installer that can add it to the EFI system-partition and a driver for EFI-nvram so we can add a boot-option.

[kallisti5]

HAIKU_BOOT_PLATFORM is pretty critical since it is defined per arch and decides what loader is used.

​http://cgit.haiku-os.org/haiku/tree/build/jam/ArchitectureRules#n228

As Fredrik said, introducing a HAIKU_BOOT_PLATFORM_SECONDARY (or making it an array or something) likely makes sense... All well beyond my Jam skill level. That's why I'm documenting how it works here with the hopes someone good at Jam will pick it up and run with it. :-D

As for the EFI installer + nvram... we need our anyboot images to default to BIOS+EFI before we go down that road. nvram access depends on an EFI booted operating system. (at least on linux. I assume it needs a kernel arg or something?

[diver]

Wouldn't it be cool to have UEFI bootloader in beta1?

[kallisti5]

There was some outstanding work on EFI to make it part of the build. We are hacking in a greasy script to generate an EFI anyboot outside of jam in the hrev1 beta1 branch.

[waddlesplash]

EFI loader is now included in beta1 and in nightly images.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone