Hi,

I wrote a boot loader in the spirit of simplicity, following the suckless philosophy.

https://gitlab.com/bztsrc/simpleboot

The toolkit is just a single, dependency-free command (available for Windows and Linux) that generates bootable disk images with this loader. It works on BIOS and UEFI, and can boot the Linux kernel, or lower-half and higher-half (or upper-half) kernels with the Multiboot2 protocol. FreeBSD kernel support in progress (loads and maps it properly, runs for quite a while, but it needs some kind of boot info I do not yet pass so eventually it crashes due to a page fault).

The goal of the project is to throw out everything that's not necessary, and just keep the very essential parts at a bare minimum; without loosing functionality and being capable of booting as much kernels as possible (currently supported Linux, ELF32 (prot mode entry CDECL), ELF64 (long mode entry SysV ABI), COFF/PE (prot mode entry CDECL) and PE32+ (long mode entry, Microsoft fastcall ABI).

Why it is interesting, because to provide a common loader for both BIOS and UEFI, I've used flatassembler to write a master boot record that's capable of loading 64-bit UEFI executables.

It does all the necessary initialization, sets up the environment like an UEFI firmware would, enables paging, long mode, A20 etc., then it loads the very same file that UEFI would boot, parses the COFF/PE headers and relocates the sections accordingly. See the code here: https://gitlab.com/bztsrc/simpleboot/-/blob/main/src/boot.asm#L137

It was quite a challenge to fit all of that into 446 bytes, but I'm reasonably proud of the result. Granted, I had to use some tricks to make it work (for example the file that it loads from the EFI System Partition must be defragmented, and it's size cannot exceed what's a single BIOS call can load, approx. 127 sectors, or 64k.) Hope you like it too!

MIT license, do as you please with the code. Use it to write your own EFI executable loaders in Assembly if you'd like.

Cheers,
bzt

is that possible to use it, to boot a non uefi os, eg, windows 7, on a uefi device that doesn't support non uefi booting ( a tablet ) ?

Lol, I wrote a smaller version of this, and with different requirements.

But I really wanted to run it on real hardware (and not qemu with a uefi bios), then I managed to make work the USB3 hardware debugging facility as a hardware tracer.

https://www.rocketgit.com/user/sylware/nyankernel

I shelved it for now in order to work on the ELF interpreter... because I have the sin of playing video games on native elf/linux (I don't get into the details)... but valve is now (very recently) forcing obscene contraints on distros to run some major games (dota2), breaking my distro. And if you work around their container you get VAC anti-cheat warnings (Will I get a VAC ban?)

All that to say I may have to bid farewell to steam (and probably dota2 and more), and the alternative ELF interpreter would become kind of "un-interesting".

Then I may un-shelve this project, with probably the EDLF64 linker/linux EDLF64 loader in parallel (but I'll code them in plain and simple C first).

Not sure I follow. The firmware (BIOS, OpenFW, Coreboot, UEFI, whatever) is totally independent from the kernel. A kernel might use certain firmware services or it might not. But even if it doesn't, there's no reason why it couldn't be booted (provided it otherwise supports that CPU architecture).

Not sure what you mean by "on a uefi device", but if that supposed to mean the storage has GPT partitioning table with an EFI System Partition formatted as FAT12/16/32 storing the kernel on it, then yes, any non-UEFI loader can interpret those data structures too. Actually that's what Simpleboot does on legacy BIOS machines (when not booted by the UEFI firmware).

Nice! I couldn't find that smaller Assembly version you talk about in your repo. Can you please give a direct link? BTW, I think 446 byte is already pretty small

Cheers,
bzt

@bzt, it is UEFI only (different requirements), namely it creates only a UEFI_COFF executable, a "UEFI OS loader".

It exits the "boot mode" from the UEFI retaining all the needed information to boot a kernel (I intended to target linux with removed gcc extensions and removed ISO C syntax recent tantrums).

I planned to go "2MiB page" super-simplified-linux-based kernel, and I think I did ready a memory page pfn-mapped array (aka the brutal easy way). All the last parts are assembly written. Additionnaly, once the UEFI is exited, you can fully trace the code on real hardware with the USB3 debug facility (I had to workaround a hardware bug of this debug facility on zen2, dunno if it is fixed on zen3/4). Of course, you need a second computer with USB3 to receive the trace, and there is a minimal "handshake" protocol between two computers.

There is a trick though, the assembly syntax is "intel"... but with a C preprocessor used in a very conservative way (I use the tinycc one for the moment, I know a C preprocessor is kind of easy and small to code, far from the scale of a C compiler), and this "intel" syntax does generate proper code for fasmg/[yn]asm/gas to assemble.
The default of make shell scripts (not bash of course) is to assemble using all assemblers (and if I recall properly, the linux modified C parts of the UEFI code with tinycc and cproc), and pick the products from one of them to link. cproc with its QBE backend generates only native gas assembly code (I recall intel syntax).

Namely, if assembler native macros are used, they are just here to support this common "intel" syntax. Of course, "complex assembly" stuff, usually related to data exchange with the linker ("relocations"), are often ugly (but they are rare, so...).

sorry for my english,

the tablet only support UEFI boot, but there is no UEFI version of Windows 7 os,

as you mentioned, UEFI boot means, GPT partition and FAT32 boot partition, but Windows 7 only can do MBR,

so can Simpleboot in UEFI environment boot up Windows 7 located in another partition? the tablet will boot Simpletboot first, then simpleboot boot up Windows 7, possible?

As I've tried to say, boot method is independent of the OS.

Well, Simpleboot does not support booting any kind of Windows kernels. But if I implement that, then sure, this will work.

The problem with booting Windows is that it's not documented. But I can tell that you don't boot the kernel in the first place, you boot something called NTLDR, and in return, that's what boots the Windows. My guess is, one would need an UEFI aware NTLDR to get Win7 booted, and that's all. The problem is, this isn't officially documented, but I'll do some research to see if I can get this going. Hmmm, looks like the source leaked out.

In the meantime, take a look at ntloader. This is a FOSS reimplementation of NTLDR as a grub module, which does have UEFI support.

Cheers,
bzt

ok, i try look at ntloader grub uefi, thanks

Hi!
I dont know if it helps - KolibriOS - have something like mtldr - loader for this system. Its opensource, everyone may take a look:
http://websvn.kolibrios.org/listing.php?repname=Kolibri+OS&path=%2Fprograms%2Fhd_load%2Fmtldr%2F

This is an NTFS boot sector, trying to masquarade as Windows to fool NTLDR. (So this is something that NTLDR loads, and not something that loads NTLDR).

One could implement a loader for this sure (booting from NTFS boot code directly, leaving NTLDR entirely out), but that's a different approach. It's good for someone trying to implement a Windows loader, so thanks for the link, but I don't think this is useful to sleepsleep.

Cheers,
bzt

Thanks for clarification...
Recently I bought an laptop and instaled Linux Mint on it... Perhaps ntloader allows me install Win7 and cooexisting with Mint... Mint pages tell me - "first install Win, second Mint"... It there way to go in opposite direction? I guess sleepsleep searching something similar...
Cheers !!

Little update, Simpleboot now can boot 64-bit ARM kernels on the Raspberry Pi 3/4 too.

There's nothing special with the command line, if the kernel is compiled for AArch64, then automatically it will generate a disk image that can be booted on Raspberry Pi boards. Additionally using the "-b" flag, you can make that image multi-platform bootable if you wish (of course, provide a different kernel filename with "-k" in this case).

Despite the non-native arch, the Multiboot2 protocol left intact; magic is passed in X0, the MBI pointer in X1 (standard arguments on ARM). Framebuffer works as on x86, and even though the RPi firmware doesn't have a memory map API, still a handcrafted Memory Map (type 6) tag is provided for your kernel. The kernel.c example has been modified to work on RPi too. See https://gitlab.com/bztsrc/simpleboot/-/blob/main/docs/ABI.md for details.

As a result of being multi-arch, the flatassembler boot sector code had to be renamed, now it is here: https://gitlab.com/bztsrc/simpleboot/-/blob/main/src/boot_x86.asm#L137

Cheers,
bzt

Ooops, I'm still in debt with these answers, sorry!
Well, I haven't used ntloader myself (actually I don't use GRUB nor any Windows at all), but my understanding is it should allow you to dual boot Linux and a NT6 OS (like Win7) on a UEFI machine.
No, there's no other way. The issue here is that Win installer demolishes everything in its path, so if you install Mint first and Win as second, then Mint will be gone. That's why you first have to install Win and Mint afterwards, because the Mint installer does not destroy already existing OSes.

Hope this helps,
bzt

Thanks for reply,
As far as remember few months ago I tried install Mint on 12 year old i5 machine with installed Windows 7 and several systems ( FatDogs two versions and KolibriOS). All systems uses Win7 bootloader. When I tried install Mint, it doesnt recognise all. So general rule first Windows than Mint doesnt work in this cause.
Finally I gave up - I asked myself If I really need Mint on this perticular piece of hardware. Nowdays I have acces to variety machines park with ZOO of Oses. Sometimes if just bored with work on ASUS with Mint I switch to Win 10 MSI than to Dell than to HP than to vintage P4 (if I want feel smell of old furniture)..
Sorry if I missed general topic of thread...