ARM port?

[feliwir]

Hello,

thanks for this great tutorial series, i've already learnt a lot from it. Now i was wondering if there will also be a guide about OS programming for other architectures/ multiple architectures since I can't really find much about that topic.

Thanks in advance

[phil-opp]

Thanks a lot! Glad you like it :).

I've tried my hands on an ARM board (a stm32 f7) lately and I really missed some good documentation. It differs greatly from x86 in many aspects, so porting this project might not be easy. Most things would work completely different (e.g. there is no long mode, paging is different or not available at all, there is no (official) multiboot support, etc.). So I think this series will continue to focus on x86_64 in the near future.

But I completely agree that better guides/tutorials for ARM are badly needed. @japaric is working on a project named copper, which I'm very excited about! It contains already some code (completely Rust) for LED, button, and timer support. Maybe it helps you.

[unjordy]

Hey,

I've been following along and enjoying blog_os too. While following along, I've been rewriting each part to split it into platform-independent and x86_64 portions, under the reasoning that if my OS one day turned out to be useful, I would want to be able to run it on at least x86_64 and ARM. I've so far written some boot code, an LED blinker (to see if the board is still running code), and a basic serial text_console driver (which shares an interface with the x86_64 text_console, my version of your VGA driver). Briefly, here are some things I've learned in my (so far unsuccessful, but educational) attempt to run on ARM:

• There's a huge difference between microcontroller (Cortex-M architecture, like the STM32) and application-oriented (Cortex-A, like the Raspberry Pi's CPU) cores. It wouldn't make much sense to port a project like blog_os to a Cortex-M target; they're better served by a library of low-level code like copper, or an RTOS. Cortex-A and similar cores are intended to run full operating systems like Linux, and do include a full MMO, paging, etc.
• Booting an ARM core is much, much simpler than booting x86_64. You hit on one of the reasons why in your post - there's no long mode, protected mode, A20 line, or other pile of hacks. My ARM boot code just loads the stack pointer, zeros out BSS, and jumps into Rust main.
• ARM cores don't usually have Multiboot. They have something a bit better: most Linux-oriented ARM firmware passes a pointer to an ARM ATAGs structure to your assembly code in register r2. This seems equivalent to the Multiboot info structure in terms of what it tells the operating system about memory, and has the benefit of being fairly well standardized -- I think it's what the Android OEMs pass to the Linux kernel from their firmware. The Raspberry Pi (which is my porting target even though I hate it with a fury) uses closed source binary blobs for its early stage boot. Some claim that makes the device hard to work with on a bare metal level, but that isn't true; all we care about is the ARM ATAGs struct the firmware gives us.
• Drivers are simpler on ARM, if you have a specific target (board or computer) in mind. It's possible (and common-ish) for one person to write all of the drivers for an ARM SoC's built-in peripherals, because these intentionally have very simple low-level MMIO interfaces -- you're expected to interact with them without an OS in the way. An example is the Raspberry Pi's infamous GPU, which has a simple low-level message-oriented API for drawing graphics to the screen and which is actually pretty simple to use for 2D stuff. Of course the Raspberry Pi has other problems (like actively user-hostile low level documentation and arbitrary, undocumented changes between board models), but it's nothing compared with x86_64.
• Making your code platform-independent isn't as big a job as you might think. When I was working through the Kernel Heap post last night (replacing my super-good solution of just allocating multiples of 4k frames for everything and leaking on deallocation), my platform independence changes were as follows:

Splitting off the HEAP_START and HEAP_SIZE constants into a platform-specific x86.rs file:

pub const HEAP_START: usize = 0o_000_001_000_000_0000;
pub const HEAP_SIZE: usize = 32 * 1024 * 1024; // 32 MB

and conditionally importing the platform-specific module in the main allocator file, using a pattern I've settled on after trying various combinations of includes and conditional compilation:

#[cfg(target_arch = "x86_64")]
#[path = "x86.rs"]
mod platform;
#[cfg(target_arch = "i686")]
#[path = "x86.rs"]
mod platform;
pub use self::platform::*;

Once I port the allocator to ARM - a bit far off at the moment - I'll make a new arm.rs file and add this before pub use self::platform::*;:

#[cfg(target_arch = "arm")]
#[path = "arm.rs"]
mod platform;

Plenty of the memory mapping code in blog_os -- excluding the bits that actually touch the CPU page tables and flush caches -- looks portable to my eye. Drivers are of course specific to each platform, so the platform-independent parts of those are largely just interface. Fortunately, ARM serial console drivers are even simpler than drivers for the x86 VGA console.

[Evrey]

You can always have a look at the seL4 sources to learn how to do an ARM port. seL4 is a very small kernel and as it only supports ARM and x86 as of now, learning ARM by comparing its sources to the x86 ones should be possible.

Besides that, unlike those of x86, the ARM manuals are quite an easy read. However, I grew up with the old architectures and I am currently emulating an ARMv4T. Comparing this to the more up-to-date manual I just linked... damn, has ARM evolved. And I really miss some older concepts like "all instructions are conditional". Anyways, this manual for the Cortex A9 has some sections on the basic memory map and on memory protection. Hope, it helps.

[phil-opp]

Thanks a lot for the detailed explanations, @unjordy! ARM, and especially the Cortex-A core, looks really interesting. Now I want to play with it :). Are there any good alternatives to the RaspberryPi, or is it still the most common board?

Thanks for the links, @Evrey, they look very useful. Maybe I'll write some posts about an ARM port eventually, but I think that we need to extend our existing kernel first. At our current stage, the kernels wouldn't have much in common (different boot sequence, different multiboot-like system, different text output driver, etc.).

[unjordy]

You're in luck, @phil-opp! We're starting to see more and more inexpensive Cortex-A boards come out directed toward hobbyists who want to use them to run Linux; some even have proper bare metal documentation. Better options include C.H.I.P. (~$9, haven't received mine yet so no idea on actual hardware documentation), Orange Pi, and some models of ODROID. All of these are more powerful than any of the rPI stuff, including the 3. All that said, you're right, the Raspberry Pi is still the gold standard for hobby ARM work, and most people asking for an ARM port are very likely asking so they can write an OS for their rPI. Since the boards are all very cheap, I can recommend picking up a Raspberry Pi and working with it and gaining experience with the ARM SoC until inconveniences like the USB 2.0 system bus make you want something better, faster, and cheaper. Do keep in mind that the Raspberry Pi 3 doesn't run in 64-bit mode and very likely never will (despite the Raspberry Pi Foundation advertising otherwise), and the Raspberry Pi Zero is entirely mythological at this point because I can't figure out where or how to buy one. Despite all my complaints, I've got the feeling you'll enjoy exploring whichever ARM platform you settle on.

[konohitowa]

Do keep in mind that the Raspberry Pi 3 doesn't run in 64-bit mode and very likely never will (despite the Raspberry Pi Foundation advertising otherwise),

https://github.com/swarren/rpi-3-aarch64-demo

[dodikk]

It differs greatly from x86 in many aspects, so porting this project might not be easy.

@phil-opp , as far as I understand, the xbuild and bootimage utilities are not going to work for ARM or other MCU devices (Atmel, PIC by Microchip, etc.). Right?

If so, what do you think of adding some disclaimer sections beside the This blog is openly developed on Github. text header ?

[andre-richter]

Maybe I can help a bit, check out my work in progress here:
https://github.com/andre-richter/rust-raspi3-tutorial

Currently a bit quiet because I am porting the MMIO in the tutorials and my cortex-a crate to the tock register crate. I hope I can finish that within next month, then I will port more tutorials.

[IsaacWoods]

@dodikk cargo-xbuild should work for any target - I use it to compile for thumbv7em-none-eabi for example.

I've not looked into booting Cortex-A, but afaict there's no fundamental reason bootimage couldn't be extended to ARM devices. It just doesn't have support atm.

[dodikk]

@andre-richter , @IsaacWoods , thank you for the helpful replies and links.

cargo-xbuild should work for any target - I use it to compile for thumbv7em-none-eabi for example.
... but afaict there's no fundamental reason bootimage couldn't be extended to ARM devices. It just doesn't have support atm.

I guess that

Having such information within some of the articles 
would make the blog even more beginner-friendly. 

Meaning, @phil-opp has developed some tools to simplify the learning curve for the beginners... But is is not obvious enough (imho) "which hardware platforms it can target".
Is the "target configuration" JSON file from the "minimal rust kernel" article just enough to get that freedom of choice?

[dodikk]

Sorry for "necro posting" but I'd have some questions related to the discussion on the microcontrollers.

So, my question is :

Why is blog_os pointless on the microcontroller hardware?

There's a huge difference between microcontroller (Cortex-M architecture, like the STM32) and application-oriented (Cortex-A, like the Raspberry Pi's CPU) cores.

It wouldn't make much sense to port a project like blog_os to a Cortex-M target; they're better served by a library of low-level code like copper, or an RTOS

I thought of this blog_os as a foundation for creating someone's own RTOS or "firmware" (the articles and features prior to the "VGA text mode").

Meaning, it provides :

1. An environment that does not rely on the underlying OS API (Unix signals or Win API)
2. The "trampoline" to the fn _start()
   ** in which one can either make a "hello world" style led blinking loop with the GPIO pins and other good things... Or initialize the RTOS tasks... Or do some other stuff.

Why is RTOS in Rust considered to not have much sense?

P.S. I might have misunderstood the points in the above discussion as

1. I am not a native speaker
2. I am a beginner in both Rust lang and embedded programming

P.P.S. I'm really willing to educate myself in the subject, so I'm asking these questions that might seem stupid (especially to the people with a better background in the field).

[IsaacWoods]

@dodikk A full-blown OS is usually overkill for microcontrollers. For example, I'm building a keyboard firmware for a Cortex-M microcontroller - I have no need to run processes, to output anything to the screen (the only debugging output is flashing an LED, in fact) or anything else a 'real' OS needs.

Because Blog OS is not yet very mature, it shares a lot of characteristics with a firmware, but that's not generally true of whole operating system kernels. A lot of the code would be redundant for most applications, and along with the small flash sizes that microcontrollers usually have, it's space we can't afford to waste.

Hope that answers some of your questions!

[phil-opp]

@dodikk

Having such information within some of the articles would make the blog even more beginner-friendly.

Thanks for the suggestion. I added a note to the second post that we're targeting the x86 architecture in 8416845.

[Mandragorian]

Hello,

Regarding support for multiple architectures, while I of course understand that providing support for every possible architecture is way beyond the scope of this tutorial, would it be a good idea to nevertheless organize the code in order to facilitate support for multiple architectures?

For example a module called arch which has multiple submodules for each architecture the OS supports. Then arch.rs could have

mod x86;

#[cfg(feature = "x86")]
pub use x86::*;

Where the methods each submodule exports are conforming to an architecture agnostic API.

This could give an idea how one could go on to port the OS to a new platform.

[phil-opp]

@Mandragorian I agree that it makes sense to organize code this way. However, I'm not sure if it's a good idea for the blog since:

• Almost all code that we have now would need to go into the arch module.
• It's very easy to accidentally forget putting something platform specific in the arch module because there isn't another supported platform right now.
• It is difficult to provide platform independent abstractions because we don't know how the other platforms work yet.

I think it's better to just keep the kernel platform specific until we start porting it to another architecture. Then we can discuss the differences between the platforms and create the arch module in a way that allows abstracting over the platform differences.