Thanks for all this, Joshua, I really appreciate it. I'll definitely be checking out your links, thank God for FOSS.
I think I'll try tinkering with stage 1 and see if I can skip the file system checks and jump straight to loader (putting loader in memory through int 13h) and see what can happen from there. Thanks for the help. On Fri, Jul 26, 2024, 3:18 PM Joshua M. Clulow via illumos-discuss < discuss@lists.illumos.org> wrote: > On Fri, 26 Jul 2024 at 11:57, Bryce <678...@gmail.com> wrote: > > that makes a lot of sense. I'm trying to build a monolithic illumos > kernel that includes its own root file system. I want to do this because I > see that illumos is really only established on x86 with a weak standing in > SPARC, and I'd like to try and port Illumos to other arch's. I'd like to > get a minimal image working on x86 first though, and troubleshoot my way > from there > > I do think that's a good place to start, to get familiar with building > OS bits and assembling and configuring them, etc. Indeed, most people > are using i86pc (x86) these days, so that's a good place to experiment > and it's easy enough to do in a VM on most systems. > > > so, the bootloader passes a command line string and perhaps an > environment listing (which I assume is also a string?) to the kerbel, does > it pass these as pointers? If so, are they pushed onto the stack? and if > that is so, then does the bootloader load the kernel and set up SS and BP > in the process? > > > > speaking of which, does the loader switch into protected mode before > loading the kerbel (I assume so, as to load a ufs/cpio archive with drivers > I'd assume you'd need more than a meg of memory. > > Our boot loader is actually a Multiboot2 loader: > > https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html > > The specification outlines a partially defined expected machine state, > and the layout of control structures that allow us to pass arguments > and modules to the kernel. On i86pc, we then have "dboot", which is > our Multiboot2 entrypoint and which handles getting the system the > rest of the way up from that predefined state. The dboot object is > built and stuffed into "unix" along with the rest of the core of the > kernel. > > You don't strictly need to use our boot loader, though. Folks in the > SmartOS community make extensive use of iPXE, from their fork: > > https://github.com/tritonDataCenter/ipxe > > At Oxide, we're actually working on a new architecture, "oxide", that > sits as a peer alongside the existing "i86pc". In our world, there is > no BIOS/EFI firmware at all, just a ROM on the motherboard. We put > our kernel and CPIO archive into the ROM, and then the kernel itself > loads the root file system from an NVMe disk once it's running. In > this model, we've had to fold all the things a BIOS would do to get us > to the boot loader, and then what the boot loader would have done, > into our single ROM image. None of that is as yet available in > illumos-gate, but we're building it to be upstream-ready in the long > term. > > https://github.com/oxidecomputer/illumos-gate/tree/stlouis > > > Also, can the loader be configured to load the kernel from a known > address on disk, instead of from a file system? if not that's fine, I could > patch the source to support that. I ask because I used legacy grub a long > time ago, and I'm pretty sure it doesn't have that feature, but idk how > illumos has patched their grub 0.98. > > We actually don't use our legacy GRUB anymore. It hasn't been deleted > from the source tree, but it will eventually be when someone finds > time to do that gracefully. Our current boot loader is in the tree > under "usr/src/boot", and is one we imported from FreeBSD. I don't > believe that loader can read directly from a disk slice, but it does > have support for several file systems including pcfs (aka FAT), hsfs > (aka ISO), UFS, ZFS, etc. > > > I'll definitely refer to omnios to see how the big guys do it, but it's > not quite what I'm looking for. > > > > thank you for offering the templates, but I was looking for a slightly > lower level modification. > > Alright! You're always welcome to assemble the pieces yourself, of > course. The templates are just a sequence of steps for doing that, so > even if you don't use them, it might help from time to time to refer > to what they're doing. The packaging system (which the image builder > will drive) is also responsible for assembling certain data files like > "/etc/driver_aliases" that define which drivers get attached to which > hardware, etc. I expect Peter has reworked at least some of that in > his "minimal viable illumos" project, so that may be work looking at > also to see what's required in place to boot. > > Cheers. > > -- > Joshua M. Clulow > http://blog.sysmgr.org ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/Tc9bfa679c7294ee7-M646c8d910546992dc1461281 Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
