BOOTBOOT Multi-platform Micro-kernel Loader

[Cdev]

Hey bzt.

This is a general questions post (very much on-topic, but possibly these are repeated - though I could not find answers), and I apologize in advance if it's a bit too lengthy or feature a few "stupid questions".

I initially fell in love with BOOTBOOT when starting my osdev journey a couple weeks back, but I could not get it to work and had some problems despite reading the docs (maybe I just missed stuff, in such a case feel free to just say so). I ended up using Limine, which I like a lot save for lack of support for anything not x86 .There is a stivale2 ARM bootloader, sabaton , but :

1. It seems to currently be focus on mobile phones , with support for pinephone and progress being made for iPhones. I consider phones to be a meme .
2. It's in Zig, and I don't want to learn another lang just to know what my bootloader does (no offence, Zig is probably fine, just not for me + no binaries).
3. It has some differences from the usual stivale2 protocol in the interface it gives to the kernel (not any significant ones, and that's pretty amazing btw)

Now, I have got some code down and am relooking bootloaders, especially since I like RPi, so have a few questions :

1. Is the 4GiB mmap limit on x86_64 BIOS concrete; is there any hope of change there ? The logic seems to be that it loads in protected mode, so what if I chain-load it from Grub or such a thing ? I'm not too worried about the other features of level 2 , just this one matters to me ATM.
2. Why does BOOTBOOT restrict the mmap to 16GiB on other platforms; is there any hope of change there ?
3. AFAIK, upon last check a few weeks back, the "mkbootimg" binary is making BIOS-only images (tried VBox UEFI and real hw UEFI, didn't boot) ? I would like to generate x86 images that could boot on UEFI + BIOS (I believe the term is El-Torito ?). How can this be done ? Also, how would one use mkbootimg to generate an image for other archs than x86_64 ?
4. I could not understand the spec PDF (it seemed a bit too concise to me ) on how one should go about getting the mmap or dealing with SMP, is this covered elsewhere ?
5. Why does mkbootimg need two configuration files ? Is it necessary to have a JSON + a .txt ? Maybe it is for some reason, I just found it odd.
6. By RasPi 3+ support, do you include the RasPi 400 (the one with the keyboard) ?
7. Is it possible to specify a stack size for the kernel in the BOOTBOOT protocol ?
8. Does BOOTBOOT supply some way to handle SMP cross platform , or is this left to the kernel to handle ?
9. The spec says something about the x86_64 BIOS Initrd is restricted to "~96k" ; is there any hope for change there ?
10. The mmap is said to not be in order; is there any hope for change there ? Because (maybe there is a workaround but) I use an explicit free list allocator with entires in ascending order (similar to the one in K&R unit , and to sort a variable number of mmap entries would itself require a malloc() , but the mmap is needed to do a malloc (ouch).

Thanks a lot for enduring this rather long post, and thanks for putting in the time and effort to make a viable no-nonsense bootloader for those targeting 64-bit RasPi. If the mmap limitations are permanent , I might have to (much to my disliking) have two source files for dealing with the x86 btldr (limine) and the RasPi/ btldr (bootboot) - or arrange some sort of abstraction for the kernel to work regardless of bootloader - so before I did that, I though I should consult you.

[bzt]

Hey bzt.

This is a general questions post (very much on-topic, but possibly these are repeated - though I could not find answers), and I apologize in advance if it's a bit too lengthy or feature a few "stupid questions".

Have no worries, it's better if you ask even if the question is stupid than not to ask at all. You can only learn if you have questions.

It was hard to figure out what you mean, because mmap and paging are two totally different things, but you seem to mix those badly. The first is a list of memory areas provided by the firmware (no 4G nor 16G limit for that, as a matter of fact records could hold any value up to 64 bits), and the latter is set up by BOOTBOOT and used by the MMU to place your kernel in higher-half.

1. Is the 4GiB mmap limit on x86_64 BIOS concrete; is there any hope of change there ? The logic seems to be that it loads in protected mode, so what if I chain-load it from Grub or such a thing ? I'm not too worried about the other features of level 2 , just this one matters to me ATM.

There's no such thing, "4GiB mmap limit". First, Grub does not set the paging for you, as multiboot is for prot-mode. BOOTBOOT loads a long-mode kernel in higher half, and for that, paging is a must (different to mmap).
Second, chainloading through Grub works out-of-the-box. But you could also load bootboot.bin as a multiboot "kernel", and then BOOTBOOT will set up the paging for you. (The reason why only 4G is mapped with the BIOS loader is, because it loads in protmode, it can't access more memory than that, so it surely loads the initrd in the first 4G. There's nothing it could pass to the kernel above 4G, everything it sets up must be in the first 4G because of the protmode addressing.)

2. Why does BOOTBOOT restrict the mmap to 16GiB on other platforms; is there any hope of change there ?

It does not restrict anything. Your kernel supposed to set up its paging tables the way it wants them; BOOTBOOT only provides a minimal paging which is mandatory to enter long mode. Your kernel not supposed to use that for long, only in the initialization phase. (Same way like you don't rely on Grub's GDT nor stack, instead you set them up for your kernel as soon as possible.)

3. AFAIK, upon last check a few weeks back, the "mkbootimg" binary is making BIOS-only images

I have absolutely no clue what makes you think that.

(tried VBox UEFI and real hw UEFI, didn't boot) ?

Then there were something else, misconfiguration perhaps. I would need the exact error messages to help you, for example, did you set up the boot devices to boot from your device?
FYI, I test BOOTBOOT with bochs, qemu, and VirtualBox too. Works for me. There are lot of people using BOOTBOOT on real machines with UEFI, that works too.

I would like to generate x86 images that could boot on UEFI + BIOS

Then this is your lucky day, that's exactly what BOOTBOOT's mkbootimg does.

(I believe the term is El-Torito ?). How can this be done ?

Nope, El-Torito is for CD and DVD-ROMs. Basically mkbootimg creates a special hybrid image which you can boot from an USB stick on BIOS machines as well as on UEFI machines; or you could burn the image to a CD-ROM and boot that disc on BIOS machines or UEFI machines (there are 4 different booting mechanisms here, BIOS+disk, UEFI+disk, BIOS+cdrom, UEFI+cdrom). This has been tested very throughfully by many people, not just by me, even in the wildest scenarios. For example last time I had to modify the loader was for someone who used Grub-mkrescue to have a boot manager, loaded BOOTBOOT as a multiboot kernel from the CDROM to provide long mode enviroment, but wanted to load the initrd from the ESP on the hard-drive. Quite extravagant configuration if you ask me, but even this works.

Also, how would one use mkbootimg to generate an image for other archs than x86_64 ?

That's simple. Take a look at the Makefile in the images directory. The one and only difference between generating the x86 bootable image and the ARM bootable image is which kernel is copied into the initrd. Everything else is automated and taken care for you.

4. I could not understand the spec PDF (it seemed a bit too concise to me ) on how one should go about getting the mmap or dealing with SMP, is this covered elsewhere ?

It is covered in the PDF pretty detailed. About the mmap, you can find all the information you need on page 16. About paging, see page 18. For the SMP, you can even find example codes in the Appendix on page 28 on how to tell APs from BP apart.
In a nutshell, memory map is passed in the bootboot struct, as an array of (start,length) pairs, and you have convenience macros to deal with it (oh, there are comments in the bootboot.h too explaining those macros), and you don't have to worry about SMP because your kernel is started on all cores in parallel. If you want different code to run on each core, then you have to query the core id (that's what you can find in the Appendix), but also mentioned in the README.md

5. Why does mkbootimg need two configuration files ? Is it necessary to have a JSON + a .txt ? Maybe it is for some reason, I just found it odd.

It doesn't. The text config file is for the loader, parsed during boot. The JSON is for the mkbootimg, parsed in compilation time when the disk image is constructed. Mkbootimg needs the boot-time config so that it can save it into the image for the loader (otherwise mkbootimg checks that config to get the name of the kernel should you use a non-standard name for it).

6. By RasPi 3+ support, do you include the RasPi 400 (the one with the keyboard) ?

I don't have that hardware, so I cannot test it. If someone can provide me detailed feedback, then I'm willing to add support for the RPi 400.

7. Is it possible to specify a stack size for the kernel in the BOOTBOOT protocol ?

Yes, for the level 2 loaders (basically all except the BIOS version). But you should not rely on the boot environment for too long, the boot stacks are small, because their only purpose to allow your kernel init to run to set up the final stacks. BOOTBOOT does not tell you how to write your OS, it only provides a minimal environment so that you can start your kernel without Assembly hacks and trampoline codes. But you still have to write your OS.

8. Does BOOTBOOT supply some way to handle SMP cross platform , or is this left to the kernel to handle ?

BOOTBOOT supports SMP in a cross-platform way, your kernel is started on all cores in parallel, no matter the architecture (and this will be the same even when new architectures will be added to BOOTBOOT in the future).

9. The spec says something about the x86_64 BIOS Initrd is restricted to "~96k" ; is there any hope for change there ?

Nope, the initrd size is restricted to 16M. That ~96k limitation is only for the BIOS Expansion ROM image, and that limitation is mandated by the BIOS Boot Specification, so unlikely to change. If that's not enough for you, then don't load the initrd from ROM; you can load the initrd from other sources like from disk for example. Since you're not planning to create an embedded appliance, do not mind ROM boot, focus on ESP:\BOOTBOOT\INITRD only.

10. The mmap is said to not be in order; is there any hope for change there ? Because (maybe there is a workaround but) I use an explicit free list allocator with entires in ascending order (similar to the one in K&R unit , and to sort a variable number of mmap entries would itself require a malloc() , but the mmap is needed to do a malloc (ouch).

Just as with all the other things, you're not supposed to use the boot environment as-is. You should parse the mmap and build up your memory allocator's lists the way you seem them fit. (Sorting in place does not need malloc BTW)

For the records, there's a 99.99999% chance that BOOTBOOT passes the mmap in order, because both E820 and UEFI MemoryMap should be sorted. However since BOOTBOOT passes the mmap in the exact order the firmware gave it the map, it cannot guarantee that all firmware will only report ordered entries. If your memory allocator depends on an ordered list, then it's better if you sort it yourself just to be on the safe side. For example when you copy the free memory records from the BOOTBOOT mmap to your allocator's free list, you could use insertion sort. That's fast and simple. Or you could use quick-sort, but that's harder to port. Neither of these require malloc.

Thanks a lot for enduring this rather long post, and thanks for putting in the time and effort to make a viable no-nonsense bootloader for those targeting 64-bit RasPi. If the mmap limitations are permanent , I might have to (much to my disliking) have two source files for dealing with the x86 btldr (limine) and the RasPi/ btldr (bootboot) - or arrange some sort of abstraction for the kernel to work regardless of bootloader - so before I did that, I though I should consult you.

You're welcome, took me a while to answer. And again, there's absolutely no limitations on the paging, nor on the memory map. It is totally up to your kernel how you do it.

Cheers,
bzt

[Cdev]

It was hard to figure out what you mean, because mmap and paging are two totally different things, but you seem to mix those badly. The first is a list of memory areas provided by the firmware (no 4G nor 16G limit for that, as a matter of fact records could hold any value up to 64 bits), and the latter is set up by BOOTBOOT and used by the MMU to place your kernel in higher-half.

Oh right, my bad. So if I understand correctly, supposing the machine has more memory than BOOTBOOT's identity-map threshold (4G for stage 1 and 16G for stage 2) , the free+usable sections above said threshold show up the same way they do below it, in the memory map ?

I don't mind the amount of identity-mapped/paged memory being restricted; what I meant to ask was about the memory map returned by the loader, that's all.

Second, chainloading through Grub works out-of-the-box. But you could also load bootboot.bin as a multiboot "kernel", and then BOOTBOOT will set up the paging for you.

So, if I, as you say, load bootboot.bin as a multiboot "kernel", say with Grub on BIOS, will this identity map upto 4GiB or 16GiB ?

Your kernel not supposed to use that for long, only in the initialization phase. (Same way like you don't rely on Grub's GDT nor stack, instead you set them up for your kernel as soon as possible.)

Apt analogy, got it.

Then there were something else, misconfiguration perhaps. I would need the exact error messages to help you, for example, did you set up the boot devices to boot from your device?
FYI, I test BOOTBOOT with bochs, qemu, and VirtualBox too. Works for me. There are lot of people using BOOTBOOT on real machines with UEFI, that works too.

Probably. I will get back to you with my config + precise description of the issue should it continue to persist. As for the last time, VBox just dumped me to UEFI shell and real hw UEFI did not find the USB bootlable either, though I forget the exact behavior it had. Might have been some config issue, not sure.

That's simple. Take a look at the Makefile in the images directory. The one and only difference between generating the x86 bootable image and the ARM bootable image is which kernel is copied into the initrd. Everything else is automated and taken care for you.

That's quite nice, thanks. I suppose the tool parses the executable to figure out it's target.

For the SMP, you can even find example codes in the Appendix on page 28 on how to tell APs from BP apart.

I had missed this, sorry.

In a nutshell, memory map is passed in the bootboot struct, as an array of (start,length) pairs, and you have convenience macros to deal with it

Ah, I see. The spec does talk much on this, it deals more with the macros themselves. Consequently I am not certainly how the array is arranged such that I can iterate over it and use the macros on each entry .

Code: Select all

you don't have to worry about SMP because your kernel is started on all cores in parallel

Yes, I noticed this , and (silly question incoming !) was kind of perplexed what the (single-threaded) kernel would do running on multiple cores (how even, would it do this ?)

If someone can provide me detailed feedback, then I'm willing to add support for the RPi 400.

From what I could later gather from the official website as well as reviews by enthusiasts (I do not have it myself either) it appears to basically be a RPi4 with different casing, and I think you do support the 4, so I don't think you have to do anything about it.

Code: Select all

it only provides a minimal environment so that you can start your kernel without Assembly hacks and trampoline codes.

Understood, but at the end of the day, to set up your own stacks, do paging, manage SMP, and the like, one anyways needs Assembly (maybe even Assembly hacks) , is it not ? Well, it's certainly much better than needing an assembly stub to get into long mode but while facilitating that, why keep "small boot stacks" ? I understand that "you still have to write your OS", and surely one has to, but why say "you should not rely on the boot environment for too long" when talking of a modern, long-mode bootloader ?

That ~96k limitation is only for the BIOS Expansion ROM image, and that limitation is mandated by the BIOS Boot Specification

Ah, ROM image, i see. Not a problem then.

For the records, there's a 99.99999% chance that BOOTBOOT passes the mmap in order, because both E820 and UEFI MemoryMap should be sorted. However since BOOTBOOT passes the mmap in the exact order the firmware gave it the map, it cannot guarantee that all firmware will only report ordered entries. If your memory allocator depends on an ordered list, then it's better if you sort it yourself just to be on the safe side. For example when you copy the free memory records from the BOOTBOOT mmap to your allocator's free list, you could use insertion sort. That's fast and simple. Or you could use quick-sort, but that's harder to port. Neither of these require malloc.

[/quote]
Thanks for the insight ! It makes sense now. So basically, assuming error-free firmware, one only needs to worry about sorting the memory map on BIOS , though one should just sort it everywhere because firmware can be error-prone.

Thanks again.

[bzt]

Oh right, my bad. So if I understand correctly, supposing the machine has more memory than BOOTBOOT's identity-map threshold (4G for stage 1 and 16G for stage 2) , the free+usable sections above said threshold show up the same way they do below it, in the memory map ?

Those are completely independent things. The memory map is just a list of areas and their type (usable, ACPI, MMIO etc.). That list has nothing to do with the identity mapping, and the identity mapping does not influence that list.

I don't mind the amount of identity-mapped/paged memory being restricted; what I meant to ask was about the memory map returned by the loader, that's all.

The memory map can hold any 2^64 values for both the address and the length. The only restriction for the memory map is, that the length must be rounded down to paragraphs (16 bytes). This isn't really relevant as both E820 and UEFI MMap reports lengths rounded down to pages (4096 bytes) anyway.

So, if I, as you say, load bootboot.bin as a multiboot "kernel", say with Grub on BIOS, will this identity map upto 4GiB or 16GiB ?

bootboot.bin identity maps 4G. Doesn't matter if Grub chainloads bootboot.bin (in which case it starts in real-mode) or loads it as a multiboot kernel (in which case it's started in prot-mode), because the long-mode switch (along with the paging setup) is made in bootboot.bin and not in Grub.

Probably. I will get back to you with my config + precise description of the issue should it continue to persist. As for the last time, VBox just dumped me to UEFI shell and real hw UEFI did not find the USB bootlable either, though I forget the exact behavior it had. Might have been some config issue, not sure.

Sounds like a missing boot order configuration. Try this at the UEFI shell prompt:

Code: Select all

FS0:
EFI\BOOT\BOOTX64.EFI

Consequently I am not certainly how the array is arranged such that I can iterate over it and use the macros on each entry .

Look, it's 8+8 bytes for each record, after the header. That means

Code: Select all

0xFFFFFFFFFFE00000 - start of the bootboot struct
0xFFFFFFFFFFE00004 - 4 bytes, bootboot size
0xFFFFFFFFFFE00080 - memory map start
    0xFFFFFFFFFFE00080 - start address of the first record
    0xFFFFFFFFFFE00088 - size + type of the first record
    0xFFFFFFFFFFE00090 - start address of the second record
    0xFFFFFFFFFFE00098 - size + type of the second record
       ...                                   (this goes up to the address 0xFFFFFFFFFFE00000 + bootboot size)

From C, you can use this:

Code: Select all

MMapEnt *mmap_ent, *mmap_last = &bootboot + bootboot.size;

for(mmap_ent = &bootboot.mmap; mmap_ent < mmap_last; mmap_ent++) {
    printf("address: %lx  size %ld   type %d\n",
        MMapEnt_Ptr(mmap_ent),
        MMapEnt_Size(mmap_ent),
        MMapEnt_Type(mmap_ent));
}

If you're curious, you can see the definitions and explanations in the bootboot.h header file, but Ptr() is stored in the first 64 bits, Type() in the next 4 bits, and Size() in the remaining 60 bits for each record.

As described in the spec, if you don't want to use "mmap_last", you could have used

Code: Select all

MMapEnt *mmap_ent =  &bootboot.mmap;
int i, nument = (bootboot.size - 128) / 16;
// ... and use mmap_ent[i] where i >= 0 and i < nument

what the (single-threaded) kernel would do running on multiple cores (how even, would it do this ?)

A BOOTBOOT compliant kernel must be aware of parallelism. So at a minimum, a single-threaded kernel must query the lapicid (using the cpuid instruction for example), compare it's id with bootboot.bspid, and if doesn't match, stop the AP core.

For example, doing a very minimal modification to the example in the Appendix

Code: Select all

_start:
  mov  $1, %eax
  cpuid
  shr  $24, %ebx
  cmpw %bx, bootboot + 0xC   // bootboot.bspid
  je  .bsp
  /* things to do on application processors */
1:
  cli
  hlt
  jmp 1b
.bsp:
  /* things to do on bootstrap processor */

Would put APs to sleep and reduce a BOOTBOOT compliant kernel to a "single-threaded" kernel. However unlike the normal multi-threaded operation, this needs a minimal Assembly preambule like above.

From what I could later gather from the official website as well as reviews by enthusiasts (I do not have it myself either) it appears to basically be a RPi4 with different casing, and I think you do support the 4, so I don't think you have to do anything about it.

I would need system register dumps, because I'm pretty sure it's using a different board id, so MMIO detection might be off. Otherwise yes, it should be straightforward to support, and I want it to.

Well, it's certainly much better than needing an assembly stub to get into long mode but while facilitating that, why keep "small boot stacks" ?

Because BOOTBOOT is a multi-platform boot loader, and it's protocol supports cores up to 65535. Since all cores must have its own stack during boot, using a bigger stack could waste huge amount of memory. (Reclaiming the RAM used by the boot stacks after booting has finished is totally up to the kernel, BOOTBOOT can't do anything about that.)

I understand that "you still have to write your OS", and surely one has to, but why say "you should not rely on the boot environment for too long" when talking of a modern, long-mode bootloader ?

Because BOOTBOOT doesn't only support long-mode, it is a multi-platform loader that provides the same (minimal, but) common environment on all 64 bit architectures. On the other hand, kernels are different, they want to handle the machine differently, there's no way that that minimal common environment would satisfy all kernel's needs. So knowing this I haven't even tried to create something that could be good for all, rather I said let's make that boot environment as simple as possible, and let the kernels set up the environment the way they want it. It's like the ideology behind the BIOS boot sector: BIOS does not want to tell you what OS you can use, it just loads the first sector to the same address for all OS, and lets them handle the rest.

Thanks for the insight ! It makes sense now. So basically, assuming error-free firmware, one only needs to worry about sorting the memory map on BIOS , though one should just sort it everywhere because firmware can be error-prone.

Yes, exactly. But when your OS becomes advanced enough to move out of VMs, you'll realize pretty soon you must never assume error-free firmware So it's the best if you guarantee all prerequisites your kernel needs yourself. For example, if you're using an allocator that needs the free list to be sorted, then assume the original memory map isn't sorted and sort it before you start to use memory allocation. If your allocator doesn't care about the ordering of the free lists, then you can just use the memory map as-is.

Cheers,
bzt

[sj95126]

This isn't really relevant as both E820 and UEFI MMap reports lengths rounded down to pages (4096 bytes) anyway.

That's not always the case. E820 maps can contain regions whose sizes are not multiples of 4096.

For example, on an older HP laptop I use for testing, the first two regions are:
0x0-0x9d7ff, length 0x9d800 (usable)
0x9d800-0x9ffff, length 0x2800 (reserved)

update: I realized you might have been referring to E820 maps that your loader has already processed and page aligned, then passed to the boot object - if that's the case, ignore my answer.

[bzt]

This isn't really relevant as both E820 and UEFI MMap reports lengths rounded down to pages (4096 bytes) anyway.

That's not always the case. E820 maps can contain regions whose sizes are not multiples of 4096.

For example, on an older HP laptop I use for testing, the first two regions are:
0x0-0x9d7ff, length 0x9d800 (usable)
0x9d800-0x9ffff, length 0x2800 (reserved)

update: I realized you might have been referring to E820 maps that your loader has already processed and page aligned, then passed to the boot object - if that's the case, ignore my answer.

Erm, no, neither. You forgot to quote the sentence before that. The BOOTBOOT loader does not page align E820 map entries. It does not change the start address in any way, and it only does round down sizes to paragraphs (16 bytes), and that is what's irrelevant if the firmware already provides multiple of page lengths.

Even though your HP laptop doesn't report memory in multiple of pages, that 16 bytes rounding down that BOOTBOOT would use isn't necessary, because both 0x9d800 and 0x2800 are multiple of 16 bytes in the first place.

Oh, and one more thing, even though the BOOTBOOT protocol does not guarantee that memory map entries will be sorted on all platforms, the BIOS implementation does sort the entries by starting addresses ascending. I might add sort to the UEFI mmap too.

Cheers,
bzt

[bzt]

I've changed the BOOTBOOT protocol spec from "memory map should be sorted" to "memory map must be sorted". I've added sort to the coreboot and UEFI implementations to be on the safe side, recompiled everything and uploaded the binaries (the RPi and BIOS versions already provided sorted list for sure).

However one still have to copy out records for the allocator, because memory map contains all areas (unused and used alike), while the free memory list in the allocator only needs the unused areas, and there's no guarantee that the allocator uses the same format as the memory map in the first place.

Cheers,
bzt

[benjixu]

Hello, bzt
I am glad that you can introduce the BOOTBOOT Multi-platform to us. I am a begnner in OS develpment. Mostly, I have to consider the hardware details in each platform. Take the interrupt, for instance, calling the interrupt in x86 and arm are different. I have to be familiar with the interrupt protocol first. I wanna my OS can support the multi-platform not only in x86 but also in arm, risc-v, etc. Those detail annoying me a lot. Plus, if I have to get the memory information in x86, that I have to call the 0x15 and store the information in E820. But if I want to get memory information in the arm, the situation is different. Those operations are different on each platform. Dose BOOTBOOT can help me to support the unified API to get around those problems? If the bootboot can help me to solve it, do you have any tutorials to learn it as a beginner? If BOOTBOOT can't solve that problem, do you know other tools that can help us to solve this problem? Thank you very much

Sincerely,
Benjixu

[nexos]

No, it does not.
BOOTBOOT is a bootloader. Most platforms have pretty tricky initialization sequences (like switching to long mode, enabling A20 gate, etc), and any bootloader tries to abstract this. Note that a bootloader does not control the hardware for you. It initializes, detects some stuff (like memory maps, perhaps hardware buses, etc), but then it hands off to the OS, and the OS has to manage the hardware.

My OS is going to multi platform as well. I am going to support i386, x86_64, aarch64, and RISC-V 64. To be multiplatform, your codebase must be portable. That means all code that is specific to one platform must be separate from code that is not. For example, code that manages interrupts and paging is hardware specific, but something like a thread scheduler or the memory manager can be made to be platform independent. It takes a lot of work, but is doable.

As for tutoriasls, you should use the manuals for these platforms as a reference. These manuals are relatively easy to understand, and any question about them can be asked here.

Note that for beginners, I would recommend starting with x86 do to the available resources about it.