#[1]Feed - OSDev.org [2]Feed - News [3]Feed - All forums [4]Feed - New
   Topics [5]Feed - Active Topics [6]Feed - Forum - Announcements, Test
   Requests, & Job openings [7]Feed - Topic - BOOTBOOT Multi-platform
   Micro-kernel Loader

OSDev.org

   The Place to Start for Operating System Developers
   [8]* Login   [9] * Register [10]The OSDev.org Wiki - Got a question?
   Search this first! [11]* FAQ    [12] * Search
   It is currently Sat Jan 13, 2024 5:46 pm

   [13]View unanswered posts | [14]View active topics

   [15]Board index » [16]Operating System Development » [17]Announcements,
   Test Requests, & Job openings

   All times are UTC - 6 hours

[18]BOOTBOOT Multi-platform Micro-kernel Loader

   Moderators: [19]AJ, [20]01000101, [21]carbonBased, [22]Candy,
   [23]pcmattman, [24]JAAman, [25]Octocontrabass, [26]klange, [27]sortie,
   [28]kmcguire, [29]thepowersgang, [30]chase, [31]Combuster, [32]Owen
[33]Post new topic  [34] Reply to topic  Page 1 of 3
 [ 39 posts ]                           [35]Go to page 1, [36]2, [37]3  [38]Next
     [39]Print view [40]Previous topic | [41]Next topic
   Author Message
   bzt
    Post subject: BOOTBOOT Multi-platform Micro-kernel Loader
   [42]Post Posted: Fri Dec 07, 2018 7:34 pm

                                   Offline
                                    Member
                                   Member
                                 User avatar

   Joined: Thu Oct 13, 2016 4:55 pm
   Posts: 1584
   [43]BOOTBOOT Protocol
   Unlike any existing boot loaders, this loader is not one big bloated
   system. Quite the contrary, it's a set of several independent, very
   thin implementations, all providing the same C/C++ compatible,
   higher-half 64 bit environment on their corresponding platforms. By
   very thin I mean really lightweight, no more than a few kilobytes each:
   boot.bin (512 bytes), bootboot.bin (11k), bootboot.img (30k),
   bootboot.efi (93k)
   It is ideal for hobby OS developers, as it's easy to use and it's very
   flexible. It's much easier to dealt with than GRUB, and also unlike
   with Multiboot you won't need any long mode Assembly trampoline code
   with dirty GDT and paging tricks in your kernel.
   BOOTBOOT can load your higher half, 64 bit-only C/C++ kernel just as-is
   without any hacks. The repository also contains full documentation in
   MD and PDF formats, as well as small ANSI C mkboot utilities to help
   you with the installation. It's a Free and Open Source Sotfware,
   licensed under the terms of MIT license. If you want to use it as a
   reference for your own boot loader, the PDF documentation has a
   detailed description on which firmware interfaces have been used, and
   also the sources are well commented.
   The BOOTBOOT Protocol is very easy to integrate, as it has a totally
   architecture agnostic interface. You just specify some object addresses
   in your [44]linker script, and you're done. The information structure
   is defined in a [45]C/C++ header file and can be used on all platforms.
   It contains information such as boot date and time, timezone, frame
   buffer dimension, platform independent memory map, initrd size,
   pointers to detected system tables (efi, acpi, mp, smbios etc.). Unlike
   other protocols, BOOTBOOT was written with forward-compatibility in
   mind. That is, current implementations support static addresses for
   those variables (Protocol Level 1), but it states that future versions
   (Level 2) should read the symbol table of the kernel to find those
   addresses. Kernels written for the Level 1 loaders will be able to boot
   with the upcoming Level 2 loaders just out-of-the-box.
   The loader is capable of loading monolithic kernels, but mainly focuses
   on micro-kernels with an initrd. It can load the OS from several
   different sources: from ROM, over serial line, from a GPT partition, or
   from a file on a FAT16/32 GPT partition (usually ESP. To avoid
   licensing issues with M$, it's limited to upper case 8+3 filenames).
   The protocol also allows booting over network with TFTP, although the
   reference implementations do not use that (not yet :-) ).
   Current implementations support kernels in ELF64 and PE32+ formats for
   the AArch64 and x86_64 architectures. As for the initrd, they support
   - statically linked executables (for monolithic kernels and statically
   linked micro-kernels like Minix)
   - cpio (all variants: old hp, newc, and crc too. The latter is used by
   the Linux kernel btw.)
   - tar (POSIX ustar, a very beginner friendly format)
   - SFS (both Brendan's and BenLunt's versions)
   - James Molloy's initrd (I assume you're already familiar with his
   tutorial)
   - FS/Z (my operating system's native file system format)
   - any archive or file system format, provided your kernel file is
   contiguous and is the first executable in the initrd.
   The initrd can be gzip compressed, or optionally encrypted (FS/Z only
   feature).
   The repository contains an example [46]hello world kernel that
   demonstrates how to write strings and boxes on the frame buffer in an
   architecture independent way using PSF2 fonts. You are free to use that
   example kernel as a skeleton for starting your own kernel. Kernels
   written in C++ are also supported, but you have to provide a small code
   block at _start that calls your constructors (easiest way is to use a
   linker script to create .text.init or .text.ctors sections or
   .init_array table).
   How to install
   Please note BOOTBOOT is very flexible. What I describe here is just one
   way, which I believe to be the most common use case for hobby OS
   developers.
   1. create a disk image with GPT partitioning table ("dd if=/dev/zero
   of=myimage.dd bs=1M count=256" and "fdisk myimage.dd")
   2. set the first partition's type to ESP, and format it with FAT16 or
   FAT32 (fdisk's type 1, and use "mkfs.vfat -F x")
   3. mount that partition with a loop device ("sudo mount -o loop,user
   myimage.dd somedir" or use "losetup"+"mount /dev/loop0")
   4. create a BOOTBOOT directory there ("mkdir somedir/BOOTBOOT")
   5. create an INITRD with your kernel in it (for example use "find . |
   cpio -H hpodc -o | gzip >somedir/BOOTBOOT/INITRD", for monolithic
   kernels, simply copy your kernel executable as INITRD).
   6. optionally create a text file named BOOTBOOT/CONFIG (will be parsed
   by your kernel)
   7. copy bootboot.bin into that directory as BOOTBOOT/LOADER (I strongly
   suggest to set the SYSTEM attribute for this file)
   8. unmount the disk image
   9. use the x86_64-bios/mkboot.c utility to install a (P)MBR sector on
   your disk image ("./mkboot myimage.dd")
   If you want more control, do the steps 1-6, and choose a loader
   implementation for your platform and desired configuration (you can
   also use multiple loaders in the same image to create multiplatform
   bootable images). The documentation has detailed description of all of
   these scenarios:
   - Raspberry Pi 3 (AArch64)
   - UEFI (x86_64)
   - UEFI for embedded systems (x86_64, in ROM)
   - GRUB Multiboot (x86_64)
   - ISOLINUX / LILO / BOOTLIN / etc. (x86_64)
   - Legacy BIOS boot with any arbitrary boot manager (x86_64, chainloaded
   from VBR)
   - Legacy BIOS boot with a single OS on a forward-compatible GPT disk
   (x86_64, booted from MBR)
   - Legacy BIOS for embedded systems (x86_64, in ROM)
   - CDROM, in El Torito "no emulation" mode (x86_64, hybrid GPT/ISO9660
   image)
   For more information, read the documentation. Before you comment any
   critism about this loader, please read the documentation. It's very
   likely it can do what you think it can't do, as most features and
   options are not mentioned in this brief introductory post.
   Cheers,
   bzt
   [47]Top
    [48] Profile

   mihe
    Post subject: Re: BOOTBOOT Multi-platform Micro-kernel Loader
   [49]Post Posted: Sat Dec 15, 2018 3:33 am

                                   Offline
                                    Member
                                   Member

   Joined: Sun Oct 21, 2018 1:37 pm
   Posts: 38
   It looks very interesting, especially because I think I can find some
   guidance for my project in some points where I a a bit stuck, or not
   skilled enough to move forward comfortably, and you seem to cover.
   Thanks for sharing this !
   [50]Top
    [51] Profile

   bzt
    Post subject: Re: BOOTBOOT Multi-platform Micro-kernel Loader
   [52]Post Posted: Thu Feb 07, 2019 6:24 pm

                                   Offline
                                    Member
                                   Member
                                 User avatar

   Joined: Thu Oct 13, 2016 4:55 pm
   Posts: 1584
   Hi All,
   I proudly present to you the final release of BOOTBOOT Protocol.
   I've finished co-processor (SSE, Neon) initialization and SMP support
   on all platforms. With those the feature set is now complete, meaning
   from now on I'll only commit bugfixes (if any) and ports for new
   platforms. Specification is now frozen, no further modification on the
   specification will take place.
   Multi Processing was tricky to achive without an interface, but finally
   I have decided to use the simplest method: the same kernel is started
   on all cores, only with different stacks. BIOS platform uses LAPIC IPI
   + SIPI (up to 256 cores) and PIT for sleeping. UEFI utilizes the newer
   PI EFI_MP_SERVICES_PROTOCOL (up to 1024 cores). If there's a need, I
   was thinking about implementing a fallback to the older
   FirmwareMPService Protocol (but I couldn't test it, so I skipped). And
   last but not least, on RPi, well SMP is just working out-of-the-box
   (with fixed 4 cores) :-)
   The bootboot structure had to be changed a bit, few fields were
   rearranged and bootboot.numcores came in (up to 65535 cores). Otherwise
   the structure is the same, 64 bytes architecture independent info, 64
   bytes platform specific pointers (which already included ACPI and MP
   pointers), and the rest is the platform independent memory map.
   Naturally I have updated the PDF documentation as well, and I've
   created an OSDev wiki page for [53]BOOTBOOT. Happy OS development and I
   hope my loader will be useful to you too!
   Cheers,
   bzt
   [54]Top
    [55] Profile

   bzt
    Post subject: Re: BOOTBOOT Multi-platform Micro-kernel Loader
   [56]Post Posted: Thu Apr 09, 2020 5:02 am

                                   Offline
                                    Member
                                   Member
                                 User avatar

   Joined: Thu Oct 13, 2016 4:55 pm
   Posts: 1584
   Hi All,
   Lots and lots (and lots) of testing on real hardware. I'd like to say
   thanks to all the testers! Testing the multicore support under UEFI was
   extremely helpful.
   Some minor modifications had to be made: instead of PIT, the BIOS
   version now uses the PS/2 port oscillator for delays. Also minor fixes
   in Multiboot and Linux boot protocol support, they both work perfectly
   now.
   On Raspberry Pi, model 3 was working already, but now model 4 support
   has been added too. Since the firmware code changed, multicore support
   had to be changed a bit too, but now SMP works with the latest firmware
   as well.
   Furthermore, I've added [57]sample bootable images and a very simple
   image creator tool, that can generate hybrid GPT/ISO9660 images with
   your inird. I've also provided a Makefile with several rules for
   testing (booting the images from ROM, via BIOS, via GRUB, from UEFI
   CDROM etc. etc. etc.)
   Cheers,
   bzt
   [58]Top
    [59] Profile

   bzt
    Post subject: Re: BOOTBOOT Multi-platform Micro-kernel Loader
   [60]Post Posted: Mon Jun 15, 2020 8:48 pm

                                   Offline
                                    Member
                                   Member
                                 User avatar

   Joined: Thu Oct 13, 2016 4:55 pm
   Posts: 1584
   Hi All,
   New features (sort of). Protocol level 2 is now implemented in the
   reference implementations (UEFI and Raspberry Pi, BIOS remained at
   level 1). This means you are no longer tied to static link addresses,
   you are free to move them around (in the higher half -1G to 0 range).
   The loader will parse your ELF or PE kernel's symbols to find the
   addresses where to map the data. The affected labels:
     * mmio - virtual address of the MMIO area (on platforms that supports
       that),
     * fb - virtual address of the linear framebuffer,
     * bootboot - the main information structure,
     * environment - the arguments to your kernel in an UTF-8 string
     * your kernel's segment (using Elf_Phdr->p_vaddr and
       PE_hdr->code_base).

   There can be one loadable segment (concatenated code, data and bss
   sections) in the kernel. With level 2, the size limit for this is
   raised to 16M (in comparition level 1 has a limit of 2M for info,
   environment, code, data, bss and stack). That must be enough for
   monolithic kernels too. You must be careful where you put these,
   because these might overlap, and there's absolutely no checks (it is
   perfectly valid for a kernel to request mapping of bootboot struct and
   the environment string into the middle of its bss section for example.)
   The repo contains a simple, dependency-free image creator tool, mkimg.
   With that now you can create ESP FAT partition images and hybrid,
   bootable GPT disk / CDROM / DVD images. This means all disk generation
   related issues can be solved using this single file utility, no third
   party tools needed. Just like the loaders, you are free to use this
   tool with your project.
   And last but not least, besides of the C example kernel, now there's a
   Rust example kernel that you can use as a skeleton for your own kernel.
   Cheers,
   bzt
   [61]Top
    [62] Profile

   bzt
    Post subject: Re: BOOTBOOT Multi-platform Micro-kernel Loader
   [63]Post Posted: Thu Jun 18, 2020 4:06 am

                                   Offline
                                    Member
                                   Member
                                 User avatar

   Joined: Thu Oct 13, 2016 4:55 pm
   Posts: 1584
   Hi All,
   I've replaced the quick and dirty mkimg tool with a proper, fully
   featured mkbootimg. This one is also dependency-free, with precompiled
   single portable executables available for Windows, MacOSX and Linux.
   It receives a JSON configuration file as input, describing the disk you
   wish to create, and then it saves the resulting disk image. For
   example:
   Code:
   {
       "diskguid": "00000000-0000-0000-0000-000000000000",
       "disksize": 128,
       "align": 1024,
       "config": "initrd.dir/sys/config",
       "initrd": { "type": "tar", "gzip": true, "directory": "initrd.dir"
   },
       "iso9660": 1,
       "partitions": [
           { "type": "boot", "size": 16 },
           { "type": "ntfs", "size": 16, "name": "Win Exchange" },
           { "type": "ext4", "size": 16, "name": "Linux Exchange" },
           { "type": "00000000-0000-0000-0000-000000000000", "size": 32,
   "name": "MyOS usr", "file": "usrpart.bin" },
           { "type": "00000000-0000-0000-0000-000000000000", "size": 32,
   "name": "MyOS var", "file": "varpart.bin" }
       ]
   }
   Numbers are in Megabytes, except "align", which is in Kilobytes (align
   0 means sector alignment for partitions). This tool can create:
     * A compressed initrd image from a directory (currently supports cpio
       and tar, but easily expandable)
     * An ESP FAT boot partition with all the necessary files (including
       the newly created initrd) and boot code in VBR
     * An MBR / GPT / ISO9660 hybrid partitioning table with the boot
       partition on it
     * When creating a hybrid image, it also ensures that the root
       directory, the fat table, and the clusters on the boot partition
       are all 2048 bytes aligned
     * Optionally it can add any number of partitions (well, up to 248),
       and it can fill them up using partition images

   As a bonus, it also checks your kernel for BOOTBOOT compatibility,
   gives detailed error messages, and determines the architecture from
   your executable. It has all the binaries included, so no additional
   files needed (this includes the Raspberry Pi firmware files too, along
   with the Broadcom licence).
   Creating multiarch images also possible simply by using an array:
   Code:
       "initrd": { "type": "tar", "gzip": true, "directory": [
   "initrd.x86", "initrd.arm" ] },
   This will create two initrds, one for each arch and it will put both
   loaders for them into the boot partition (the code is written in a way
   that it can support many architectures, however there's only loader for
   x86_64 and AArch64, so right now it is limited to two).
   The generated images were tested with: FAT16/32: fsck.vfat, TianoCore
   UEFI; GPT: fdisk and gdisk's verify function. All green. :-)
   Hope this will be useful to some of you,
   bzt
   [64]Top
    [65] Profile

   Korona
    Post subject: Re: BOOTBOOT Multi-platform Micro-kernel Loader
   [66]Post Posted: Thu Jun 18, 2020 8:28 am

                                   Offline
                                    Member
                                   Member

   Joined: Thu May 17, 2007 1:27 pm
   Posts: 999
   bzt wrote:
   There can be one loadable segment (concatenated code, data and bss
   sections) in the kernel. With level 2, the size limit for this is
   raised to 16M (in comparition level 1 has a limit of 2M for info,
   environment, code, data, bss and stack). That must be enough for
   monolithic kernels too. You must be careful where you put these,
   because these might overlap, and there's absolutely no checks (it is
   perfectly valid for a kernel to request mapping of bootboot struct and
   the environment string into the middle of its bss section for example.)
   Out of curiosity, why did you pick this design? Do you map that segment
   as RWX? That prevents many useful sanity checking ("security") features
   from working, in particular WP and NX. WP and NX have probably caught
   more memory bugs in Managarm than any other measures combined. (I mean
   sure, one can enable it retroactively by some linker script hacks but
   that seems unnecessarily clunky for something that just amounts to
   setting two bits in the bootloader).
   _________________
   [67]managarm: Microkernel-based OS capable of running a Wayland desktop
   (Discord: [68]https://discord.gg/7WB6Ur3). My OS-dev projects:
   [[69]mlibc: Portable C library for managarm, qword, Linux, Sigma, ...]
   [[70]LAI: AML interpreter] [[71]xbstrap: Build system for OS
   distributions].
   [72]Top
    [73] Profile

   bzt
    Post subject: Re: BOOTBOOT Multi-platform Micro-kernel Loader
   [74]Post Posted: Thu Jun 18, 2020 10:58 am

                                   Offline
                                    Member
                                   Member
                                 User avatar

   Joined: Thu Oct 13, 2016 4:55 pm
   Posts: 1584
   Hi,
   Thanks for checking out! The answer is in the documentation, but thanks
   for asking!
   Korona wrote:
   Out of curiosity, why did you pick this design? Do you map that segment
   as RWX?
   It uses one boot segment for several reasons:
   First, for simplicity. This is also required by many other boot loaders
   (all that works with raw binaries this is actually a must otherwise you
   can't convert ELFs to raws).
   Second, BOOTBOOT can load PE32+ kernels too, and PE doesn't have the
   concept of multiple, configurable load segments (there's a segment
   pointer for code and one for the data in the header, that's it).
   Third, there's no point in overcomplicating because your kernel will
   switch away from identity mapping and will use its paging tables as
   soon as possible anyway.
   Fourth, BOOTBOOT is a multiplatform loader, and it provides the same
   environment on all platforms. It cannot and should not rely on specific
   CPU features, it tries to keep it as minimal as possible so that it can
   support more platforms. (For example AArch64 has WNX bit too, but x86
   doesn't. If BOOTBOOT were about to utilize that, then it couldn't load
   kernels on x86; not with the same environment that is).
   The Multiboot specification is way too x86 related, and you simply
   can't use that on other platforms. As a result, loaders on other
   platforms create their own, unofficial and incompatible versions of the
   Multiboot spec ([75]read this for example). I put a lot of effort in
   the BOOTBOOT Specification so this can never happen to it. As it
   focuses on the smallest common denominator among platforms, it's
   environment should be available on all platforms, no need for tweaking
   the spec.
   Korona wrote:
   That prevents many useful sanity checking ("security") features from
   working, in particular WP and NX.
   No, not really. My kernel, which is loaded using BOOTBOOT does take
   advantage of both WP and NX security bits (and on AArch64 WNX too), so
   it is doable just fine. From the BOOTBOOT User's Manual, in section
   "Machine State":
   Quote:
   If a kernel wants to separate it's code on a read-only segment and data
   on a non-executable segment for security, it
   can override the page translation tables as soon as it gains control.
   BOOTBOOT Protocol does only
   handle one loadable segment for simplicity (called boot in the example
   linker script, see Appendix).
   Providing memory security is not a job for a bootloader. Your kernel
   will drop identity paging and will use it's own tables anyway. It will
   drop them for sure by the time it creates its first process. So why
   should the loader complicate things? I like simple. This is similar how
   GDT works (with Grub too). It is set up because it's needed, but your
   kernel should set a known GDT according its needs as soon as possible
   anyway.
   In short, the bootloader's job is not to provide full functionality,
   rather to provide the bare minimum to get the system going. For
   example, BOOTBOOT allocates only 1k stack for your kernel per core,
   because it doesn't want to tell you how you should organize your
   memory. 1k is not enough for your kernel that's for sure, but it is
   surely enough to set up paging and stacks the way your kernel wants
   them, and that's about it.
   Cheers,
   bzt
   [76]Top
    [77] Profile

   PeterX
    Post subject: Re: BOOTBOOT Multi-platform Micro-kernel Loader
   [78]Post Posted: Thu Jun 18, 2020 12:19 pm

                                   Offline
                                    Member
                                   Member

   Joined: Fri Nov 22, 2019 5:46 am
   Posts: 590
   Great job!
   But why do you call it "micro-kernel" loader? It's seems like
   unnecessary modesty to me. You could load nearly any kernel, don't you?
   And what platforms is it available for so far? If I understood it
   correctly: Legacy-BIOS PCs, UEFI PCs, RaspPi 3 and 4. Correct?
   Greetings
   Peter
   [79]Top
    [80] Profile

   bzt
    Post subject: Re: BOOTBOOT Multi-platform Micro-kernel Loader
   [81]Post Posted: Thu Jun 18, 2020 7:36 pm

                                   Offline
                                    Member
                                   Member
                                 User avatar

   Joined: Thu Oct 13, 2016 4:55 pm
   Posts: 1584
   PeterX wrote:
   Great job!
   Thanks!
   PeterX wrote:
   But why do you call it "micro-kernel" loader? It's seems like
   unnecessary modesty to me. You could load nearly any kernel, don't you?
   Well, yes, it can load statically linked images, so it can load
   monolithic kernels too. I call it micro-kernel loader because it has a
   neat feature that no other boot loader: it loads an initrd into the
   memory with a bunch of files, then it locates the kernel amongst them
   (so the kernel is not a separate file as with GRUB, just a regular file
   inside the initrd). This suits primarily the needs of a micro-kernel,
   which requires to load several files on boot before it could access the
   disks.
   PeterX wrote:
   And what platforms is it available for so far? If I understood it
   correctly: Legacy-BIOS PCs, UEFI PCs, RaspPi 3 and 4. Correct?
   Yes, for disks, USB storages and SD cards. Plus it can also boot from a
   CDROM via El Torito (both legacy BIOS and UEFI), and from ROM (via BIOS
   Boot Specification and under UEFI as Option ROM, this is useful for
   embedded systems); you can load it as a Linux kernel (using the
   Linux/x86 boot protocol, e.g. qemu -kernel), and last but not least,
   via GRUB, because it supports Multiboot too. Check out
   [82]https://gitlab.com/bztsrc/bootboot/tree/master/images, along with
   the example images there's a Makefile with lots of qemu commands, one
   for each boot option.
   In the future if I could get decent documentation and my hands on a
   board to test with, then I would like to support more. Beageboard is
   definitely on the bucket list, for example. I was also thinking about
   UltraSparc64, but as it's market is shrinking rapidly I don't think it
   worth the effort any more. Making it to work with Macs also a
   possibility (so far I had only one roadblock, I don't know how to get
   the frame buffer address using UGA, but that's the only one thing.
   Everything else works).
   Greetings
   Peter[/quote]
   [83]Top
    [84] Profile

   bzt
    Post subject: Re: BOOTBOOT Multi-platform Micro-kernel Loader
   [85]Post Posted: Fri Jun 19, 2020 9:41 pm

                                   Offline
                                    Member
                                   Member
                                 User avatar

   Joined: Thu Oct 13, 2016 4:55 pm
   Posts: 1584
   Hi All,
   Just a little heads-up. I've upgraded the image creator:
     * It's multilingual now and autodetects OS' language
     * If initrd is given as an image file which is compressed, now that's
       transparently uncompressed to look up the kernel inside
     * New initrd formats has been added, it supports hpodc cpio, POSIX
       ustar, James Molloy's initrd and FS/Z (in lack of an up-to-date
       specification and with no available image creator I had to abandon
       SFS. But if you somehow manage to create an image, you can include
       it with the "file" directive and you should still be able to boot
       from it.)
     * Many JSON tags made optional, the tool now calculates as much
       properties as it can. For example on a partition it's enough to
       specify "type" and "file".
     * You can also use the "directory" directive for partitions, meaning
       you can create partition images from directories on-the-fly.
       Currently supported: tar and FS/Z (easy to add new file system
       drivers, see documentation). Could have added cpio and jamesm too,
       but those play not well with 512 byte sectors.
     * I've updated the FS API to inform it if the image is generated for
       initrd or partition (this is needed for FS/Z, because it supports
       gaps in files, which must be avoided in initrds)
     * On platforms that supports it (that's basically all save Windows)
       symlinks are also parsed and generated into initrds and partition
       images. This depends on S_ISLNK macro and readlink() libc function.

   Cheers,
   bzt
   [86]Top
    [87] Profile

   heemogoblin
    Post subject: Re: BOOTBOOT Multi-platform Micro-kernel Loader
   [88]Post Posted: Thu Jul 09, 2020 7:57 am

                                   Offline

   Joined: Sat Jun 27, 2020 8:00 am
   Posts: 13
   Dear All,
   I am somewhat new to OS development and programming but am quite
   competent with the theory and also the implementation of an OS. Since I
   want my OS to make use of modern features I have decided to build it
   for UEFI firmware and x86_64 architecture. Despite being able to write
   a UEFI bootloader, I could not find any way to compile it and get it to
   call my kernel_main. Then I decided to use a premade bootloader, and
   have settled on your BOOTBOOT as it directly takes me to 64 bit mode
   and wrks with UEFI. I have looked at the example kernel and have
   compiled it to get myself an elf kernel.
   Now here is the problem: I don't know how to boot it in virtualbox. To
   be more specific here are some details:
   - I have my kernel elf (the0s.x86_64.elf) in my Documents/OS/The \OS/
   folder.
   - I have downloaded all of the bootboot code and have it ready.
   - I am interested in using the bootboot.efi loader for UEFI systems.
   - I have tried straight-up creating a .img with disk utility and
   partitioning it but that has problems:
   - Whenever I make one, I can only edit one of its partitions.
   - I can only place the bootboot efi code to the system partition and
   unfortunately the other partition for my kernel is blocked. I have
   tried many workarounds, none work.
   - .imgs to virtualbox are floppy controllers and it is 2020.
   - I compiled the mkbootimg and have checked my kernel. It is OK.
   However I have no clue how to use that to create a .iso with uefi
   compatibility and my kernel .elf at Documents/OS/The \OS/.
   - I am quite confused about the config file. It says that the
   kernel=sys/config - does that mean the kernel is at sys/config/<name>
   or is the kernel called config and is at sys/ direcotry? Also it is in
   a specially named partition?
   I would ideally like please some instructions to create a .iso ideally
   or .vmdk with UEFI booting and my kernel on it so I can test out my OS.
   Any way will do, as long as it can run on ubuntu and will give me a
   vmdk or .iso virtualbox will boot.
   Also could you tell me if I can pass an EFI_SystemTable or a pointer to
   one to my kernel entry point? I'd prefer to get my time via the Runtime
   services GetTime function.
   Apologies for being so naive, but I shall be incredibly grateful if you
   could help me. Thanks in advance!
   [89]Top
    [90] Profile

   Octocontrabass
    Post subject: Re: BOOTBOOT Multi-platform Micro-kernel Loader
   [91]Post Posted: Sat Jul 11, 2020 10:14 pm

                                   Offline
                                    Member
                                   Member

   Joined: Mon Mar 25, 2013 7:01 pm
   Posts: 4978
   You can use VBoxManage to convert raw disk images to a format
   VirtualBox supports. [92]Here is the documentation.
   I don't see why you're not able to access more than one partition on
   your disk image, though.
   [93]Top
    [94] Profile

   bzt
    Post subject: Re: BOOTBOOT Multi-platform Micro-kernel Loader
   [95]Post Posted: Sun Jul 12, 2020 5:17 am

                                   Offline
                                    Member
                                   Member
                                 User avatar

   Joined: Thu Oct 13, 2016 4:55 pm
   Posts: 1584
   Hi,
   Yes, @Octoronstabass is right, you can access more partitions.
   heemogoblin wrote:
   Dear All,
   I am somewhat new to OS development and programming but am quite
   competent with the theory and also the implementation of an OS. Since I
   want my OS to make use of modern features I have decided to build it
   for UEFI firmware and x86_64 architecture. Despite being able to write
   a UEFI bootloader, I could not find any way to compile it and get it to
   call my kernel_main. Then I decided to use a premade bootloader, and
   have settled on your BOOTBOOT as it directly takes me to 64 bit mode
   and wrks with UEFI. I have looked at the example kernel and have
   compiled it to get myself an elf kernel.
   Now here is the problem: I don't know how to boot it in virtualbox. To
   be more specific here are some details:
   You create an image, then you configure your VB machine to boot with
   UEFI: "Detials" > "System" > "Motherboard" click "Enable EFI (special
   OSes only)".
   I'd recommend to use mkbootimg, that's what it is for. But if you want
   to make it by hand, here are my answers.
   heemogoblin wrote:
   - I have my kernel elf (the0s.x86_64.elf) in my Documents/OS/The \OS/
   folder.
   Move it into an initrd folder. Your kernel will be loaded as part of
   the initrd along with other files you want/need on boot.
   heemogoblin wrote:
   - I have downloaded all of the bootboot code and have it ready.
   Good.
   heemogoblin wrote:
   - I am interested in using the bootboot.efi loader for UEFI systems.
   For that, you'll need the following files:
   EFI/BOOT/BOOTX64.EFI - move bootboot.efi here
   BOOTBOOT/INITRD - the initrd image with your kernel in it, can be a tar
   or cpio archive, optionally gzip compressed.
   BOOTBOOT/CONFIG - optional, a configuration that will be passed to your
   kernel. The loader uses only two keys if given, "screen=WxH" and
   "kernel=elf_filename_inside_the_initrd" all the others are for your
   kernel.
   heemogoblin wrote:
   - I have tried straight-up creating a .img with disk utility and
   partitioning it but that has problems:
   - Whenever I make one, I can only edit one of its partitions.
   - I can only place the bootboot efi code to the system partition and
   unfortunately the other partition for my kernel is blocked. I have
   tried many workarounds, none work.
   Not sure what disk utility you're using, but you should create a GPT
   disk, with a partition that is FAT formatted and copy the three files
   above to that system partition. Change the type to EFI System Partition
   (this is important, otherwise EFI won't recognize it). The BOOTBOOT
   User's Manual Appendix has an example how to use fdisk and mkfs.vfat
   for this.
   heemogoblin wrote:
   - .imgs to virtualbox are floppy controllers and it is 2020.
   I don't know where you get that, .img files are just images. For
   example Raspberry OS contains an SD card image. My mkbootimg tool
   creates a hybrid CDROM / disk image by that extension.
   heemogoblin wrote:
   - I compiled the mkbootimg and have checked my kernel. It is OK.
   However I have no clue how to use that to create a .iso with uefi
   compatibility and my kernel .elf at Documents/OS/The \OS/.
   If you have compiled mkbootimg, then you don't need the boot loader
   files, as it has them already (data.c). It is well documented, and
   example configurations are provided. Basically you give it two
   arguments:
   Code:
   ./mkbootimg config.json output.img
   The configuration is described in detail in the README (there's an
   example json in it), there's an example json in the source directory,
   and in the [96]images directory you can find the actual json I've used
   to create the example disk images, as well as a Makefile on how to
   invoke it. If you want it to generate a hybrid ISO9660 image, that can
   be used on CDROMs, then in the mkbootimg json configuration, use
   "iso9660=true". Here's my mkbootimg.json:
   Code:
   {
       "disksize": 128,
       "config": "./config",
       "initrd": { "type": "cpio", "gzip": true, "directory": "initrd" },
       "iso9660": true,
       "partitions": [
           { "type": "boot", "size": 16 }
       ]
   }
   This instructs mkbootimg that load the BOOTBOOT configuration from the
   file "./config", create an initrd in gzipped cpio format from the
   contents of the directory "initrd" (copy the0s.x86_64.elf there). Make
   the image 128M in size and CDROM compatible, and generate one ESP
   partition only (if you need it to generate more GPT records, just add
   more elements to the "partitions" array, and you can specify a
   partition image too with "file").
   There's no need to create a filesystem on the boot partition, nor to
   copy files there, the mkbootimg will take care all of that for you.
   heemogoblin wrote:
   - I am quite confused about the config file. It says that the
   kernel=sys/config - does that mean the kernel is at sys/config/<name>
   or is the kernel called config and is at sys/ direcotry?
   I don't know where you get "kernel=sys/config". The "kernel" is the
   name of your kernel inside the initrd image (under the specified initrd
   directory). If you use mkbootimg, you'll have two config files:
     * the json - describes the disk image you want to create
     * BOOTBOOT config - this will be copied to the ESP partition, and it
       is going to be parsed by the loader and your kernel during boot

   In the latter you can specify the name of your kernel inside the initrd
   archive with "kernel=the0s.x86_64.elf", but that's not necessary if
   your elf kernel is the first executable in the archive.
   heemogoblin wrote:
   Also it is in a specially named partition?
   Yes, the ESP is given a fixed name, "EFI System Partition".
   heemogoblin wrote:
   I would ideally like please some instructions to create a .iso ideally
   or .vmdk with UEFI booting and my kernel on it so I can test out my OS.
   Any way will do, as long as it can run on ubuntu and will give me a
   vmdk or .iso virtualbox will boot.
   The mkbootimg generates a disk image file. With "iso9660=true" it is
   going to be a hybrid image, which you can simply rename to ".iso" and
   it will work. For vmdk I'm not sure, I use vdi for VirtualBox. For
   that, use the following command:
   Code:
   VBoxManage convertfromraw yourimage.img yourimage.vdi
   Because this will generate a random UUID for the vdi, and VirtualBox is
   extremely picky about UUIDs matching its configuration, I'd also
   recommend to use the following:
   Code:
   BoxManage internalcommands sethduuid yourimage.vdi (some fix UUID)
   heemogoblin wrote:
   Also could you tell me if I can pass an EFI_SystemTable or a pointer to
   one to my kernel entry point? I'd prefer to get my time via the Runtime
   services GetTime function.
   Again, described in great detail in the BOOTBOOT User's Manual. The
   protocol maps an informational structure for your kernel, which
   contains both the EFI_SystemTable pointer and both the time (which is
   queried by the EFI GetTime service under UEFI).
   heemogoblin wrote:
   Apologies for being so naive, but I shall be incredibly grateful if you
   could help me. Thanks in advance!
   You should read the documentation first :-) Both the READMEs and pdf
   have all the answers for your questions. But sure, ask and I'll try to
   answer.
   Cheers,
   bzt
   [97]Top
    [98] Profile

   zaval
    Post subject: Re: BOOTBOOT Multi-platform Micro-kernel Loader
   [99]Post Posted: Sun Jul 12, 2020 4:03 pm

                                   Offline
                                    Member
                                   Member
                                 User avatar

   Joined: Fri Feb 17, 2017 4:01 pm
   Posts: 633
   Location: Ukraine, Bachmut
   Quote:
   Despite being able to write a UEFI bootloader, I could not find any way
   to compile it and get it to call my kernel_main. Then I decided to use
   a premade bootloader, and have settled on your BOOTBOOT as it directly
   takes me to 64 bit mode and wrks with UEFI. I have looked at the
   example kernel and have compiled it to get myself an elf kernel.
   does your religion allow you to use MSVC? if so, that's so easy to
   compile your OS Loader with it as compiling "hello world". if it
   doesn't, then *shrugs.
   just for the note, despite bzt scares you, that you are required to
   mark a FAT partition as ESP and use only GPT, it's not true. you can
   create MBR with an ordinary FAT partition and be sure - it will be
   recognized by UEFI. since you are only at the start, I'd go this way
   (it's easier and maybe you'd have less troubles), actually, I do
   exactly this way - I created a small .vhd with VBox - thanks god its
   vhds are liked by diskpart (unlike qemu's). and created there a FAT
   partition. UEFI recognizes the disk, FAT formatted volume, and, of
   course, lets me start my OSL. either from the shell or from the Boot
   Manager menu or, finally, by creating a Load Option with the latter, -
   this way. Just don't forget to follow the guidelines and put your OSL
   in \efi\<YourNameAsAnOsVendor> directory, each OSL in its own directory
   (for the same architecture, I don't know why, but UEFI whimsically
   demands this, despite it distinguishes images well by their paths,
   which, of course, are different for two OSLs even lying in the same
   directory).
   Of course, when you create such a disk, vhd in my case, for an easy
   access with diskpart, you can create 2 partitions or more. and then
   your OSL may access your OS boot volume (where your OS resides) either
   by using UEFI simple file system protocol and friends, if this is a FAT
   volume (because, see, bzt, FAT is a required part by the standard, for
   easening interoperability and osdevers lives :D and not for what you
   fantasize) or using block I/O protocols given to you by UEFI for
   reading disk sectors and then making FS related parsing in the OSL by
   your own.
   and at the end, again and again - on this stubborn placement in
   \efi\boot\bootx64.efi. this is not a normal way of putting one's OSL.
   it's just a last resort in an attempt to start something by the Boot
   Manager on non-removable storages. if there is something else on the
   same disk, this thing won't be even touched. I have no idea why people
   don't look farther than this resort point. it is only somewhat and
   questionably good for removable storages, when you are going to install
   something and flash this storage for a one shot. even then, it's not
   necessary, and could mess up with something else, also blindly
   demanding itself to be placed there (and then when you put that other
   thing there, it overwrites the previous one and you find yoursefl in a
   mess). every UEFI has a "load from file" option - you better place your
   stuff in a personalized place and direct Boot Manager to it. it's more
   to bzt with his bootboot. the first time user directs the Boot Manager
   to load your bootboot, then, at the start, bootboot checks how it was
   started (by analyzing BootCurrent variable) and if it's not from its
   own Load Option, which is the case for the first start, asks a user if
   they want to install bootboot to this machine. on "yes", you just
   create a Load Option for bootboot by using SetVariable(), and that's
   it! this is how it should have been done.
   _________________
   [100]ANT - NT-like OS for x64 and arm64.
   [101]efify - UEFI for a couple of boards (mips and arm). suspended due
   to lost of all the target park boards (russians destroyed our town).
   [102]Top
    [103] Profile

        Display posts from previous: [All posts] Sort by [Post time]
                              [Ascending_]  Go
   [104]Post new topic  [105] Reply to topic  Page 1 of 3
    [ 39 posts ]  [106]Go to page 1, [107]2, [108]3  [109]Next

   [110]Board index » [111]Operating System Development »
   [112]Announcements, Test Requests, & Job openings

   All times are UTC - 6 hours

Who is online

   Users browsing this forum: No registered users and 1 guest
   You cannot post new topics in this forum
   You cannot reply to topics in this forum
   You cannot edit your posts in this forum
   You cannot delete your posts in this forum
   You cannot post attachments in this forum
   Search for: ____________________ Go
   Jump to: [   Announcements, Test Requests, & Job openings]  Go

   Powered by [113]phpBB © 2000, 2002, 2005, 2007 phpBB Group

References

   Visible links:
   1. https://forum.osdev.org/feed.php
   2. https://forum.osdev.org/feed.php?mode=news
   3. https://forum.osdev.org/feed.php?mode=forums
   4. https://forum.osdev.org/feed.php?mode=topics
   5. https://forum.osdev.org/feed.php?mode=topics_active
   6. https://forum.osdev.org/feed.php?f=2
   7. https://forum.osdev.org/feed.php?f=2&t=33362
   8. https://forum.osdev.org/./ucp.php?mode=login&sid=3552323bd691ba1e0995756313969b5b
   9. https://forum.osdev.org/./ucp.php?mode=register&sid=3552323bd691ba1e0995756313969b5b
  10. http://wiki.osdev.org/
  11. https://forum.osdev.org/./faq.php?sid=3552323bd691ba1e0995756313969b5b
  12. https://forum.osdev.org/./search.php?sid=3552323bd691ba1e0995756313969b5b
  13. https://forum.osdev.org/./search.php?search_id=unanswered&sid=3552323bd691ba1e0995756313969b5b
  14. https://forum.osdev.org/./search.php?search_id=active_topics&sid=3552323bd691ba1e0995756313969b5b
  15. https://forum.osdev.org/./index.php?sid=3552323bd691ba1e0995756313969b5b
  16. https://forum.osdev.org/./viewforum.php?f=16&sid=3552323bd691ba1e0995756313969b5b
  17. https://forum.osdev.org/./viewforum.php?f=2&sid=3552323bd691ba1e0995756313969b5b
  18. https://forum.osdev.org/./viewtopic.php?f=2&t=33362&start=0&sid=3552323bd691ba1e0995756313969b5b
  19. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=1950&sid=3552323bd691ba1e0995756313969b5b
  20. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=3731&sid=3552323bd691ba1e0995756313969b5b
  21. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=155&sid=3552323bd691ba1e0995756313969b5b
  22. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=1902&sid=3552323bd691ba1e0995756313969b5b
  23. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=2477&sid=3552323bd691ba1e0995756313969b5b
  24. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=67&sid=3552323bd691ba1e0995756313969b5b
  25. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=14234&sid=3552323bd691ba1e0995756313969b5b
  26. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=11616&sid=3552323bd691ba1e0995756313969b5b
  27. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=12891&sid=3552323bd691ba1e0995756313969b5b
  28. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=117&sid=3552323bd691ba1e0995756313969b5b
  29. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=4287&sid=3552323bd691ba1e0995756313969b5b
  30. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=2&sid=3552323bd691ba1e0995756313969b5b
  31. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=1906&sid=3552323bd691ba1e0995756313969b5b
  32. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=4866&sid=3552323bd691ba1e0995756313969b5b
  33. https://forum.osdev.org/./posting.php?mode=post&f=2&sid=3552323bd691ba1e0995756313969b5b
  34. https://forum.osdev.org/./posting.php?mode=reply&f=2&t=33362&sid=3552323bd691ba1e0995756313969b5b
  35. https://forum.osdev.org/viewtopic.php?f=2&t=33362
  36. https://forum.osdev.org/./viewtopic.php?f=2&t=33362&sid=3552323bd691ba1e0995756313969b5b&start=15
  37. https://forum.osdev.org/./viewtopic.php?f=2&t=33362&sid=3552323bd691ba1e0995756313969b5b&start=30
  38. https://forum.osdev.org/./viewtopic.php?f=2&t=33362&sid=3552323bd691ba1e0995756313969b5b&start=15
  39. https://forum.osdev.org/./viewtopic.php?f=2&t=33362&start=0&sid=3552323bd691ba1e0995756313969b5b&view=print
  40. https://forum.osdev.org/./viewtopic.php?f=2&t=33362&view=previous&sid=3552323bd691ba1e0995756313969b5b
  41. https://forum.osdev.org/./viewtopic.php?f=2&t=33362&view=next&sid=3552323bd691ba1e0995756313969b5b
  42. https://forum.osdev.org/./viewtopic.php?p=287331&sid=3552323bd691ba1e0995756313969b5b#p287331
  43. https://gitlab.com/bztsrc/bootboot
  44. https://gitlab.com/bztsrc/bootboot/blob/master/mykernel/link.ld
  45. https://gitlab.com/bztsrc/bootboot/blob/master/bootboot.h
  46. https://gitlab.com/bztsrc/bootboot/tree/master/mykernel
  47. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
  48. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=17273&sid=3552323bd691ba1e0995756313969b5b
  49. https://forum.osdev.org/./viewtopic.php?p=287447&sid=3552323bd691ba1e0995756313969b5b#p287447
  50. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
  51. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=18898&sid=3552323bd691ba1e0995756313969b5b
  52. https://forum.osdev.org/./viewtopic.php?p=288396&sid=3552323bd691ba1e0995756313969b5b#p288396
  53. https://wiki.osdev.org/BOOTBOOT
  54. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
  55. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=17273&sid=3552323bd691ba1e0995756313969b5b
  56. https://forum.osdev.org/./viewtopic.php?p=305109&sid=3552323bd691ba1e0995756313969b5b#p305109
  57. https://gitlab.com/bztsrc/bootboot/-/tree/master/images
  58. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
  59. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=17273&sid=3552323bd691ba1e0995756313969b5b
  60. https://forum.osdev.org/./viewtopic.php?p=306460&sid=3552323bd691ba1e0995756313969b5b#p306460
  61. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
  62. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=17273&sid=3552323bd691ba1e0995756313969b5b
  63. https://forum.osdev.org/./viewtopic.php?p=306501&sid=3552323bd691ba1e0995756313969b5b#p306501
  64. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
  65. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=17273&sid=3552323bd691ba1e0995756313969b5b
  66. https://forum.osdev.org/./viewtopic.php?p=306504&sid=3552323bd691ba1e0995756313969b5b#p306504
  67. https://github.com/managarm/managarm
  68. https://discord.gg/7WB6Ur3
  69. https://github.com/managarm/mlibc
  70. https://github.com/qword-os/lai
  71. https://github.com/managarm/xbstrap
  72. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
  73. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=3647&sid=3552323bd691ba1e0995756313969b5b
  74. https://forum.osdev.org/./viewtopic.php?p=306507&sid=3552323bd691ba1e0995756313969b5b#p306507
  75. https://github.com/jncronin/rpi-boot/blob/master/MULTIBOOT-ARM
  76. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
  77. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=17273&sid=3552323bd691ba1e0995756313969b5b
  78. https://forum.osdev.org/./viewtopic.php?p=306511&sid=3552323bd691ba1e0995756313969b5b#p306511
  79. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
  80. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=25322&sid=3552323bd691ba1e0995756313969b5b
  81. https://forum.osdev.org/./viewtopic.php?p=306521&sid=3552323bd691ba1e0995756313969b5b#p306521
  82. https://gitlab.com/bztsrc/bootboot/tree/master/images
  83. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
  84. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=17273&sid=3552323bd691ba1e0995756313969b5b
  85. https://forum.osdev.org/./viewtopic.php?p=306532&sid=3552323bd691ba1e0995756313969b5b#p306532
  86. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
  87. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=17273&sid=3552323bd691ba1e0995756313969b5b
  88. https://forum.osdev.org/./viewtopic.php?p=307287&sid=3552323bd691ba1e0995756313969b5b#p307287
  89. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
  90. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=25855&sid=3552323bd691ba1e0995756313969b5b
  91. https://forum.osdev.org/./viewtopic.php?p=307379&sid=3552323bd691ba1e0995756313969b5b#p307379
  92. https://www.virtualbox.org/manual/ch08.html#vboxmanage-convertfromraw
  93. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
  94. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=14234&sid=3552323bd691ba1e0995756313969b5b
  95. https://forum.osdev.org/./viewtopic.php?p=307390&sid=3552323bd691ba1e0995756313969b5b#p307390
  96. https://gitlab.com/bztsrc/bootboot/tree/master/images
  97. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
  98. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=17273&sid=3552323bd691ba1e0995756313969b5b
  99. https://forum.osdev.org/./viewtopic.php?p=307402&sid=3552323bd691ba1e0995756313969b5b#p307402
 100. https://ant-upptech.sourceforge.io/?subject=osdev
 101. https://efify.sourceforge.io/
 102. https://forum.osdev.org/viewtopic.php?f=2&t=33362#wrapheader
 103. https://forum.osdev.org/./memberlist.php?mode=viewprofile&u=17546&sid=3552323bd691ba1e0995756313969b5b
 104. https://forum.osdev.org/./posting.php?mode=post&f=2&sid=3552323bd691ba1e0995756313969b5b
 105. https://forum.osdev.org/./posting.php?mode=reply&f=2&t=33362&sid=3552323bd691ba1e0995756313969b5b
 106. https://forum.osdev.org/viewtopic.php?f=2&t=33362
 107. https://forum.osdev.org/./viewtopic.php?f=2&t=33362&sid=3552323bd691ba1e0995756313969b5b&start=15
 108. https://forum.osdev.org/./viewtopic.php?f=2&t=33362&sid=3552323bd691ba1e0995756313969b5b&start=30
 109. https://forum.osdev.org/./viewtopic.php?f=2&t=33362&sid=3552323bd691ba1e0995756313969b5b&start=15
 110. https://forum.osdev.org/./index.php?sid=3552323bd691ba1e0995756313969b5b
 111. https://forum.osdev.org/./viewforum.php?f=16&sid=3552323bd691ba1e0995756313969b5b
 112. https://forum.osdev.org/./viewforum.php?f=2&sid=3552323bd691ba1e0995756313969b5b
 113. http://www.phpbb.com/

   Hidden links:
 115. https://forum.osdev.org/./index.php?sid=3552323bd691ba1e0995756313969b5b