diff options
Diffstat (limited to 'doc/forum.osdev.org_viewtopic.php_f=2_t=33362.txt')
| -rw-r--r-- | doc/forum.osdev.org_viewtopic.php_f=2_t=33362.txt | 1015 |
1 files changed, 1015 insertions, 0 deletions
diff --git a/doc/forum.osdev.org_viewtopic.php_f=2_t=33362.txt b/doc/forum.osdev.org_viewtopic.php_f=2_t=33362.txt new file mode 100644 index 0000000..505d05b --- /dev/null +++ b/doc/forum.osdev.org_viewtopic.php_f=2_t=33362.txt @@ -0,0 +1,1015 @@ + #[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 |