Thread by @Dinoosaure

A simple #OCaml "Hello World" for a #RPi4 as a bare-metal Operating System with #MirageOS (in 4 days)

At this stage, I'm only able to boot the "caml runtime" on RPi4. But, in MirageOS, we did everything in OCaml, so it's perfect to start IoT in OCaml.

The next step will be the integration in MirageOS 4 where I specially pay my attention into how we orchestrate the compilation from the boot.S to the "caml_startup" function. UART is our serial port to be able to print something: en.wikipedia.org/wiki/Universal…

But the gap between the ability to boot a small bare-metal OS and the integration of the caml runtime is huge. Specially when the cross-compilation story with OCaml is not very... fun...

Indeed, I see 2 main points where the cross-compilation become hugely complex and the ceremony can be the scenario of a Western spaghetti.

The first point is about the absolute location of the caml compiler where you need to care about **all** paths and a certain **fixed** layout of the toolchain. But the OCaml core team is aware about this specific problem: github.com/ocaml/ocaml/is…

The second problem is options and their orders! If you know about the linker, you know what I means. It requires extra binaries which call compilers **plus** some options in the right order (and before what the user/the OCaml compiler puts).

The third issue (yes !) is about C libraries as a 3-part of the OS. Indeed, a Caml library can include a C library - and you must be sure to take the right one (compiled with right flags, etc.). MirageOS 4 and specially opam-monorepo solves this issue! github.com/ocamllabs/opam…

Finally, the path becomes complex when you need a C library and a mathematic lib needed by the caml runtime. Of course, GLIBC is **not** an option.

But MirageOS has a nice experience with that and "ocaml-freestanding", our caml runtime for the virtualization purpose (but not only that): github.com/mirage/ocaml-f…

So we did the static link between a small #nolibc (better is your program with less C!) and we use #openlibm. At least, we must implement from the OS point-of-view only three things: 1) a monotonic clock 2) sbrk 3) puts ... and that's all!

So I mostly followed the great work from Solo5 which does the same thing. And a great thanks to the team, it's nice to see and understand how the pipe can go well!!! github.com/Solo5/solo5

More specifically about RPi4, I would to thanks this tutorial which explains step by step how to make a bare-metal OS: rpi4os.com (and some other sources from Rust/RPi3/osdev wiki)

And finally, I made it in this repository: github.com/dinosaure/gilb… as a souvenir about our cancelled MirageOS retreat in Morocco (I'm currently in Málaga).