#rustboot — Public Fediverse posts

For my #bootloader in #rust I wanted an different approach than grub; instead of probing at boot-time, a userspace tool creates an load config (or the user specifies one) which is then baked into the bootloader itself when booting from BIOS.

The sysfs has some interesting quirks! Each device has a folder for related devices, both which they are contained in (slaves) and which they contain (holders). Would named them the opposite, but hey; thats just how the linux sysfs works I guess.

Another is that partitions do have a "slaves" folder but dont use them; you're supposed to just use the parent directory. Except if the partition was discovered via disk mappers (kpartx) - then the parent device does show up in the "slaves" folder!

#lowlevel #rustboot #coding #osdev #programming #linux

So im working again on rustboot and now have the "problem" that the bootsector of it dosn't contain an BiosParameterBlock, which should be only needed for DOS but welp aparently there are BIOS'es out there that just write inside it, causing it to screw up the code inside it. -.-

It needs ~51 bytes or so, but my current implementation has only ~20 bytes of wiggleroom, mainly bc rust/llvm use 32bit-in-16bit code, which has the "problem" that an mov of an u16 immediate to a register occupies 6 instead of 3 bytes (2 zero bytes to pad u16 to u32 + the sizeprefix 0x66 to "temporarily" switch to 32bit).

Sooooooo yeah yk what I did. You tought of the sensible way of writing it simply entirely in assembly? Naaaaah; I'm gonna patch LLVM ofc!! :blobcat_coolio: Which works quite okayish currently; I got it to correctly emit 16bit call and ret instructions (another thing that was eating space even before and I had to do some very creative workarounds...); now I only need to somehow compile an own rust toolchain that uses the patched LLVM, but it dosn't get's it right and the extra cpu target (i8086 instead of i386) dosn't get recognized as a valid target when rust tries to ask LLVM for it.... sigh

Maybe I should rather work on the implementation of an realmode interrupt routine that's callable from 32bit so I can implement a basic disk interface.

#rust #osdev #bootloader #rustboot #development #programming #software #floss #oss #opensource

So im working again on rustboot and now have the "problem" that the bootsector of it dosn't contain an BiosParameterBlock, which should be only needed for DOS but welp aparently there are BIOS'es out there that just write inside it, causing it to screw up the code inside it. -.-

It needs ~51 bytes or so, but my current implementation has only ~20 bytes of wiggleroom, mainly bc rust/llvm use 32bit-in-16bit code, which has the "problem" that an mov of an u16 immediate to a register occupies 6 instead of 3 bytes (2 zero bytes to pad u16 to u32 + the sizeprefix 0x66 to "temporarily" switch to 32bit).

Sooooooo yeah yk what I did. You tought of the sensible way of writing it simply entirely in assembly? Naaaaah; I'm gonna patch LLVM ofc!! :blobcat_coolio: Which works quite okayish currently; I got it to correctly emit 16bit call and ret instructions (another thing that was eating space even before and I had to do some very creative workarounds...); now I only need to somehow compile an own rust toolchain that uses the patched LLVM, but it dosn't get's it right and the extra cpu target (i8086 instead of i386) dosn't get recognized as a valid target when rust tries to ask LLVM for it.... sigh

Maybe I should rather work on the implementation of an realmode interrupt routine that's callable from 32bit so I can implement a basic disk interface.

#rust #osdev #bootloader #rustboot #development #programming #software #floss #oss #opensource

Yas! It finally works, #rustboot can load elf objects, resolve symbols and execute the the init method contained! Took me longer than I want to admit, mainly bc there was a 4byte bss segment I forgot to map correctly in the linker script that was messing with symbol locations of rustboot.

https://codearq.net/chalk-os/rustboot

#osdev #bootloader #floss #foss #oss #opensource #rust #development #software #programming

Finished today stage2 of the bios bootprocess in #rustboot , which includes trying to enable the A20 gate so we can actually access RAM above 1MB, and also to switch to 32bit protected mode! Next thing is to finally bootstrap the core of the bootloader that will run in 32bit!

https://codearq.net/chalk-os/rustboot

#rust #osdev #oss #foss #opensource #programming #development #bootloader #grub #technology