New boot-loader for RDOS that handles USB discs
New boot-loader for RDOS that handles USB discs
I just rewrote one of the ancient parts of RDOS (the custom bootloader). Previously, this loader ignored BIOS and attempted to boot from an IDE-drive with IO-port accesses. This was ok before, but now with USB discs and similar, it's just bad design. The new version uses the BIOS LBA interface to boot. This also means I can now boot from USB-discs, which would be handy for producing production CF discs without using Partition magic or Windows. I could create a special application that is embedded in the OS image that creates a bootable disk on a new CF disc without user intervention.
Re: New boot-loader for RDOS that handles USB discs
I just solved another problem in the custom boot-loader. The custom boot-loader used it's own memory detection, and this does work on the production systems since ACPI is not used, and thus corrupting ACPI-tables doesn't matter. On the new Intel Atom based hardware this no longer works, and RDOS refuses to boot.
I solved the issue by using BIOS for the memory map, and let the boot-loader convert it to a GRUB-compatible map (not a big deal). Thus, now both the GRUB boot-method and the custom boot-loader delivers memory information in the same way.
I also discovered that the GRUB boot method marks the pages in the boot-image as free, potentially allowing them to be allocated (and so does the new custom boot-loader). This is solved early in the kernel by modifying the GRUB-compatible memory information. It seems better to do this in the kernel rather than in the boot-loader. The kernel also gets the base and size of the OS image passed to it, so it can do this quite easily.
I solved the issue by using BIOS for the memory map, and let the boot-loader convert it to a GRUB-compatible map (not a big deal). Thus, now both the GRUB boot-method and the custom boot-loader delivers memory information in the same way.
I also discovered that the GRUB boot method marks the pages in the boot-image as free, potentially allowing them to be allocated (and so does the new custom boot-loader). This is solved early in the kernel by modifying the GRUB-compatible memory information. It seems better to do this in the kernel rather than in the boot-loader. The kernel also gets the base and size of the OS image passed to it, so it can do this quite easily.