Trying Lybid

What to expect so far?

First, check for updates (the latest is 11.03.2025, arm64 related), they will bring more each time. As a new update appears, its number and date will be posted in the appropriate paragraph, check the download section. As of now, there isn't much to test yet. The available set will allow you to start the ANT Loader in the UEFI environment on both real hardware and virtual machines for x64, ia32 and arm64 architectures. As of update 3 (06.03.2025), antload will transfer control to ANT, that, in turn, will print a greeting and halt the processor. This is now available for all the 3 architectures. So far, all the set is a few of ANT images and other components. Acpi.sys "driver" isn't what it's called, it's a renamed copy of antload.efi, put there as a payload for having the driver loading loop non empty. Don't remove it though, since the SYSTEM "hive" (a text file actually, so far) is configured to search for this driver. We'll add the real Acpi.sys driver at some point. During its run, antload will load the kernel images, performing all necessary preparations, like applying base relocations and image binding, also loading configuration and resources and doing other loader things and then will jump into ANT. Visually, antload shows Lybid's Boot Screen to the display, if available, and outputs trace print to the serial port. For virtual environments, set appropriate options for having these output devices. For seeing trace print on real hardware, attach your testing machine to the serial terminal. As of update 3, bringing the jump to ANT, the Boot Screen is barely noticeable, since so far, the loader phase (booting) is rapid, and ANT, on getting control, fires the Trace (debug) Screen immediately.

Installation medium

The distribution comes in form of a .zip archive, containing a file system subtree, that constitutes Lybid's pre-installation (live) set. After downloading, you need to unpack the archive the way, so that its content (just 2 directories) goes into the root directory of your FAT formatted installation medium, note, no intermediary directories should appear (some archivers unpack an archive's content into a new directory, with the archive name). You're not required to format the medium or make it empty, its initial content will stay intact. Just take care of not having name conflict with those 2 directories in the root of the medium partition, see below.

.iso image file for flashing CD, DVD or BluRay disks isn't provided, because it would be a massive overkill to waste 700MB, 4GB or even more worth optical disk for a distribution, worth a half of megabyte, especially given, that UEFI allows you to accomplish booting from a USB stick in a so much easier way. So, what the installation medium can be and what would be the best choice, given the said above? Even if it can be anything, accepted by UEFI: a USB stick (pen drive), external USB HDD or external or internal SATA HDD, connected to serve as an "installation" media and even El Torito formatted optical disks with the content of the archive put there, we recommend using a USB stick for real machines and its emulation for virtual ones. In the latter case, depending on the emulator used, you also can use a real USB stick. For example, Virtual Box allows you that. Personally, for VMs, the preferred way was to emulate the medium either as a USB stick or as a "spare" SATA HDD. For both latter cases, a virtual hard drive of some format (.vhd, .vdi, .vmdk, .qcow etc) can be used. Honestly, I used only .vhds. USB or SATA scenarios differ only in the way how you connect VDs to the emulator, what depends on the emulator, of course.

As said, Lybid doesn't require dedicating the whole storage medium for it. You'll need to only let it put 2 directories into the storage's root directory. There's no minimum space size requirements whatsoever, other than the obvious, that the unpacked archive must fit. So far, it's about 500KB, most of what are .bmp goodies for the Boot Screen. The directories are:

• efi — where the loader, its resources and the clo utility reside under Upptech subdirectory.
• Lybid — it's the Lybid "System Root" directory.

The medium must be FAT formatted as per the UEFI specification (so the firmware can access it). Needless to say, that if your storage already has the efi directory in this place, you need to safely merge its contents, in case you want to preserve what was there before updating with the Lybid's content. For the help: everything, Lybid puts into efi directory, goes into its Upptech subdirectory, we don't touch anything else. But there an exception can be. Unfortunately, some implementations, failing to grasp the specification, decide, that the only thing, they could launch from removable storages, is efi\boot\boot<ARCH>.efi, where <ARCH> is one of these: x64, ia32, aa64, aa32, depending on the machine's CPU architecture. For this case, you'll have to copy efi\Upptech\antload.efi to efi\boot\bootx64.efi, for x64, to efi\boot\bootia32.efi, for ia32 or to efi\boot\bootaa64.efi, for arm64, not forgetting about backing the previous files up if needed.

Launching Lybid

For the VM case see below, on real machines, you insert the prepared USB stick into the machine, press the power button and break into firmware. How, depends on the machine, you probably know it, if you're reading this. Once you're in the firmware Boot Manager GUI, you need to figure, where its Load (Boot) Option Menu is, if it is. Unfortunately, the thing that by all means should've been so easy, has been made by vendors often near impossible to figure or, worse, it's just not present. No wonder, you may end up not finding how to launch it thus, but let's hope. Normally, there should be the Load Option Menu and normally, it has an option, called like "Load from file"; it gives you a file navigator functionality to go through the discovered FAT volumes and pick the file of your interest. If you were lucky to find such an option, it's what you need. Your USB stick is probably named somehow, like, say, "Corsair Flash Voyager" or something, it would give you a hint. Once you located the device, you navigate its partition file hierarchy. You should go to efi\Upptech directory and pick antload.efi file in it and hit <Enter> then. That will launch the Lybid loader.

On the example of the author's machines: out of 3 x64 laptops to test on, every single one behaved differently:

And I'm sure, the more test cases to come, the more weird interpretations of what the Boot Manager should be capable of we'll see. Thus testing even this "bare" set isn't without benefits. Your input here would be nice, at least to say, because, as you can see, this "easy to achieve" step, can be not this easy as we all would want.

And as a possible rescue for the case of not being able to locate the file via the firmware's GUI, you might have yet one option, of course, if it's available — UEFI command line interface, CLI or, how they call it, "UEFI shell". Unfortunately, it's not available in most cases out of the box and making its way to the problematic machines is as hard as it is for the loader. After all, this shell is also a UEFI program and needs its Load Option for the ability to start it. But if, somehow, your setup has the shell, you can just break into it and type:

"N" is the number, the firmware assigned to your USB stick, you should be able to check it easily, because when UEFI CLI launches, it prints out info about discovered storage devices. The stick should be easily recognizable by having "USB" device path node in it. You can also try available "fs"s for availability of the efi\Upptech directory, by listing it (dir or ls commands) etc.

And yet. If your machine has Secure Boot turned on, you might need to turn it off for a while. I had this case with Gallium, turned it off and keep using that way. You may consider turning it on back after testing. Lack of machines for testing doesn't allow me to say much on this matter. Of how preventible Secure Boot in reality is for the tests. Your input in this regard would be appreciated too.

arm64 specifics

All the said above in this section, applies to machines with a well developed UEFI implementation (not counting the mentioned alien logic in making the Boot Manager). And for now, this mostly goes to normal x64 PCs. In the arm field, it's still in a quite miserable state. If you happen to have a badass arm64 laptop or development kit like ECS LIVA Mini Box QC710 Desktop with Qualcomm Snapdragon 7c SoC or alike and want to conduct Lybid testing on it, then just follow the above instructions, this case shouldn't differ from its x64 counterparts, thanks to the Microsoft's requirements to support UEFI and ACPI standards, set for IHVs. But if you want to try on one of arm64 SBCs, what's more realistic, then it's either of 2 ways for your machine:

• it has an EDK2 port
• it has only that level of UEFI support as provided by the available for it uboot

For the 1st case, it's all we need, it's a fully compliant, reference implementation from the UEFI Forum. The only issue with this, is that, there are almost no such boards, for which EDK2 has been ported. I heard about a couple of such: for rk3566 by Jared McNeill and for rk3588 by the Renegade Project. If you have such a setup, you'll launch the loader either via the EDK2 Boot Manager's "Boot from file" option or via the UEFI shell, as described above, depending on what's available and your preference. I don't have arm boards now, mine remained forever at home in the ruined by russians hometown Bachmut. Before the war, I'd been testing the real hardware arm64 case on Xenon, Radxa's Rock Pi 4B with rk3399. It had a solid UEFI support on the uboot side (even GOP). And this drives us to this 2nd case. If you have an SBC, with a solid UEFI support in uboot, you might try it, below is specifics of how to accomplish tests on such platforms.

First, for now, probably better go with an SD card instead of a USB stick (this may apply to the above paragraph too if the EDK2 port doesn't yet support USB). That's because SD interface will certainly be supported by uboot, given its special role in SBCs as one of the main booting sources. But if you're 100% certain, uboot does support USB on your board and does it reliably, you can go with it as well. Note, even though uboot brings ext4 FS support to its UEFI, don't use it for the tests. Use media, formatted with FAT. There are at least 2 reasons why: later, when Lybid takes control over from antload, it will need to access its Boot Volume on its own, and it doesn't support ext4 and, if that wasn't enough, SD Association requires, that for SD cards to work correctly, they must be formatted in a specified way, in which having ext4 isn't an option.

In any case, you unpack the archive the same way and insert the medium to the board. Also, you attach a monitor to its HDMI port and connect USB-TTL adapter to its UART pins and to your working machine, that will serve here as a terminal. You launch your terminal program, like Putty, that will communicate with the testing machine, power up the board and break into uboot's CLI, by hitting a key, from the terminal, most often, it's <Space> or "q", they used to change it for some reasons. Attaching a keyboard to the testing machine isn't yet necessary. After breaking into the uboot's CLI, you type this command:

where X:Y is uboot's numbering for devices on their buses. X is the number of the SD card cage on the SD-MMC interface and Y is the number for our partition on the specified storage device. I believe. So, most probably, it'll be either 0:1 or 1:1. It'll let you know, if it found what you asked anyway, so you could retry in case of unsuccess. <address> is an address, where to load the loader into. It depends on the SoC family, for example for Rockchip chips, 0x02080000 is what I used, because I saw, inspecting uboot's environment variables, that it loads there its default payload (Armbian). It's basically some hundreds of KBs from the available physical start. For Rockchip, the start is 0x02000000, for Allwinner, it's 0x40000000, if I remember correctly. So, we step forward 512KB from it and ask uboot to load us there. Again, if this address can't be used, uboot will tell you. Also, use slashes since uboot doesn't quite understand backslashes as a path separator. And don't forget the .efi extension, it's not UEFI shell, that lets you do so. After having loaded your loader, you finally type this command, that will launch the loader:

<address> is the same as in the 1st command. Visit this page, under the "Xenon runs our Boot Screen demo" button, you can watch a demo, I made at yet not destroyed home, on an exactly arm64 SBC case, the Xenon's one.

Virtual environments

Firmware

For these, we use OVMF, an EDK2 provided firmware for VMs. Its "look and feel" and setup/usage experiences are mostly the same for x64 and arm64. Used emulators were Qemu and Virtual Box. The latter is available for x64 only. Other emulators, that provide UEFI, might also be used, although you need to know how. Both emulators have OVMF files as part of their distribution, but VBox creates per machine writable firmware data copies, whenever a VM is created, on its own, whereas for Qemu, you should take care of this. Basically, you'll need to copy writable firmware files for the Lybid in some directory and point at them in the VM settings. The examples will follow.

Installation medium

As said above, a recommended way is creating a virtual harddrive in a format of your choice and then attaching it to the VM as either a USB mass storage device or SATA SSD/HDD. You create a virtual harddrive, let it be .vhd, convenient, recognizable by all emulators. For saving host storage space, don't preallocate full size. As for the disk size, for the live disk, 32 MB would be enough, for the installed case, you might pick a bigger size. Partitioning scheme can be either MBR or GPT. Create a partition on it. No need to mark it as "ESP" (EFI System Partition), UEFI works with ordinarily typed FAT partitions just fine. Format the partition as FAT16 or FAT32, doesn't matter which one and unpack there the archive content, the same way as described before. The hardrive is ready for use. How exactly to do these steps, heavily depends on the utilities of your choice. I made .vhds with VBox and formatted and mounted them with diskpart. I'm sure, you know how to do it with your preferrable utilities. Read here for an example sequence for doing it with diskpart.

Configuring Virtual Box virtual machine

You are free to play with what Virtual Box provides, creating a VM of your liking. Lybid is expected to run on any 64 bit x86 platform with UEFI. Below are some main configuration options, I've set up for my VBox VM for Lybid:

A note about serial port configuration. In order to see trace print from antload, the above serial port configuration was deployed. We work on Windows, so we directed VBox to use a named pipe (called antvboxuart) as the target. VBox will create this pipe on the VM launch and then you can connect to it, say, via Putty and see what antload outputs during its operation. If you use another OS, you use the OS's means for providing a serial port target for VBox and your preferred program to access that port.

You attach the virtual disk of your installation medium under the "Storage" tab either to the AHCI controller or to USB, depending on how you wish (was discussed already).

Configuring Qemu virtual machine

For Qemu, the easiest way of describing what's needed, is to write out the VM creation options. You may want to create a handy script for launching this setup easier in your favorite CLI.

Where to get the firmware files, both code and data? At least, under the Qemu installation's share subdirectory. .fd file for read only x64 code is called edk2-x86_64-code.fd, for ia32, it's edk2-i386-code.fd. Writable storage, same for 32 and 64 bits, is edk2-i386-vars.fd. In case of trying ia32 as well, don't forget, that both bitnesses would require their own copy of the latter, the copy must be per every VM in fact. For arm64, it's correspondingly edk2-aarch64-code.fd and edk2-arm-vars.fd. You are free to copy them to wherever you want and name as you wish, then point to these files as in the examples above.

Launching Lybid

Is the same as with any EDK2 implementation: either via the GUI's "Load from file" Boot Manager menu or via the UEFI shell, described above. Once you fire your VM up, it will run some default load option. It may be the UEFI shell or may be not. If it is, you just go with it. From here, you can either launch antload the command line way or, typing exit, go to the Boot Manager GUI and launch the loader the GUI way. EDK2 Boot Manager's "Load from file" is a normal file navigator, allowing you to pick up the loader file and run it.

Sometimes, as with newer VBox versions, on the first VM launch, you may experience a nasty hang, which is in fact waiting, because by default network load options were put atop of the UEFI shell's one and if you haven't removed network from the boot device order, it might get this bit annoying. The overcome would be either removing network from the VM configuration's boot device order or hitting the <F2> key, during the next VM startup, so it breaks into its Boot Manager. There, you go in the "Boot Maintenance Manager" and change Load Option order, to put UEFI shell the first. Don't forget to save this. Then just go to "Load from file" straight, or pick "UEFI shell" in the Load Option Menu, for your preference.

Additional testings

Being able to launch Lybid from its load option is a must for the development and it might be interesting to the early testers as well. Since normally, creating a load option happens in the setup program during the installation process and since Lybid doesn't have such yet, a temporary solution for this was made — the clo utility. Explaining the background and how to use it has grown enough for being placed in its own page. Read here for detail and for figuring if you are up to such a testing, but if you are, again, please consider reporting your experience, it's important. You may send your input to vlrzprgts at google mail or to upptech at outlook.

Downloads

Update 3 brings the historical transferring control to ANT. As result, you'll see the Trace Screen from the newly born OS environment. So far, this screen only shows the greeting from ANT and some memory info. Then ANT halts the processor. The environment is yet very bare, — no exception handling, no keyboard press processing. So, don't change any contents behind Lybid directory. Apart from kernel images, it's font resources, configuration; changing them might cause exceptions. For shutting down the machine, turn it off via the emulator provisioning. If you are brave enough to test this update on real hardware, shut the machine down by the hardware button. Testing it on real hardware is not dangerous, but it may result in an unhandled exception. If you still are up to such a testing, consider photographing results and sending to any of the emails, mentioned in this page.

x64, update 3, 06.03.2025

As of update 06.03.2025, antload checks for the NX feature support and sets all non code entities as non executable. Now, this feature is required. Loader will fail, if it's not supported (agree, it's a really needed feature, that cuts off the infamous stack buffer overflow exploiting). ANT is configured to use 4 level translation allowing thus up to 256TB process address space.

arm64, update 3, 11.03.2025

Finally, after week of struggling with own silly mistakes and the huge, overthought arm manual, arm64 has reached the update 3, where it also jumps into ANT, just like its x86 peers, where the jump was so much easier. The behavior of ANT is the same: greeting, printing some memory info and halting. On arm64, ANT uses 3 level mapping for both TTBR0 and TTBR1 regions, resulting in a total 1TB of the process address space. This was considered a good balance between the space size and translation speed. "Execute never" feature, an NX analog is also used. As with x86, we use page clusters (big pages) on big entities to speed up the translation.

Your participation in testing on real hardware for arm64 is especially desirable, since, as said, I don't have, so far, such hardware. As of the update 3 (11.03.2025), antload has implemented the transfer from EL2, so if the firmware of your platform runs in EL2, as is the case for uboot on rk3399 for example, then antload will work too, at least it worked in Qemu, now we need testing on real hardware with this configuration. Good candidates, along with already mentioned rk3399, are rk3566, rk3568, rk3588 boards, with uboot, supporting UEFI and maybe even newer Raspberry Pis, so if you have such, please, consider testing and reporting.

ia32, update 3, 06.03.2025

Same as for x64, but with a bit more mistakes made and thus longer time to make it work, still can't even be compared with the struggle on arm64. :D x64 and ia32 went as a light breeze during the trampoline phase.

PAE is not used, but PSE is on, which means 4MB "big" pages (clusters) available and up to 1TB of physical memory addressable (40 bit). Too bad, apart from emulators, there is almost no targets for this variant. Nearly all 32 bit only x86 machines are BIOS. And none of them would have more, than 4GB of RAM, that's why PAE is not turned. PSE on the other hand is used for clustered mapping kernel images, for example, and other big entities, so that page translation gets optimized. NX feature, in the legacy paging mode, obviously, isn't available.

Fonts

To personalize Trace Screen look, you can pick the font and color scheme, you like the most from what is available. Visit this page to have a look at the available font schemes from which you can pick your favorite to use instead of the preinstalled ones.