Replies: 15 comments
-
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. |
Beta Was this translation helpful? Give feedback.
-
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:
Splitting off the HEAP_START and HEAP_SIZE constants into a platform-specific x86.rs file:
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:
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
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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.). |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
@phil-opp , as far as I understand, the If so, what do you think of adding some disclaimer sections beside the |
Beta Was this translation helpful? Give feedback.
-
Maybe I can help a bit, check out my work in progress here: 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. |
Beta Was this translation helpful? Give feedback.
-
@dodikk I've not looked into booting Cortex-A, but afaict there's no fundamental reason |
Beta Was this translation helpful? Give feedback.
-
@andre-richter , @IsaacWoods , thank you for the helpful replies and links.
I guess that
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". |
Beta Was this translation helpful? Give feedback.
-
Sorry for "necro posting" but I'd have some questions related to the discussion on the microcontrollers. So, my question is :
I thought of this Meaning, it provides :
P.S. I might have misunderstood the points in the above discussion as
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). |
Beta Was this translation helpful? Give feedback.
-
@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! |
Beta Was this translation helpful? Give feedback.
-
Thanks for the suggestion. I added a note to the second post that we're targeting the x86 architecture in 8416845. |
Beta Was this translation helpful? Give feedback.
-
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 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. |
Beta Was this translation helpful? Give feedback.
-
@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:
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 |
Beta Was this translation helpful? Give feedback.
-
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
Beta Was this translation helpful? Give feedback.
All reactions