>Firstly, bare metal here means this stack can create an img with an executable that will be run with nothing more the uboot? I.e. No OS, no kernel, not even a Rust runtime (hence, presumably, no std in the example)?

Yes, that is correct. No OS, no kernel, no runtime. Now, Rust is isolating a core library (called libcore) that can be used without runtime support (and hence in projects like this one).

To be pedantic, from compiler design point of view, that is also a runtime.

Well, it uses the libc runtime [This is actually mostly incorrect, see comment below by dbaupp], which obliges me to invoke the old quote, "the greatest trick C ever played was to convince the world it has no runtime".

I wish I could track down the originator of that quote, but I have no idea. I'm sure someone here will know.

Libcore doesn't use the (entire) libc runtime; IIRC, it essentially just needs the memcpy and memset symbols to be defined.

Why not just implement those in Rust too? It seems like you could break the dependency entirely.

Yes, you can, and they are even provided in pure Rust for exactly that reason: http://doc.rust-lang.org/master/rlibc/

(Seems there were 2 more mem* symbols required than I remembered.)

You can implement those in Rust if you want.

Couldn't it use librlibc then?

Yes, that's exactly what librlibc is for and what is used.

The runtime really isn't mandatory, though. It's entirely feasible to have an embedded system where the only code that runs is your own.

I'll agree that glibc is a much larger iceberg than people think, though.

Yes, now we have to make the world understand what a lie it was.

Zinc doesn't really need u-boot too. So far we're targeting smaller MCUs that don't even run "big" OSes like Linux, but there's absolutely no problem in running zinc on e.g. RPi.

Zinc includes it's own preemptive scheduler, so, effectively it's an OS for user-defined tasks, as it does manage the hardware resources.

Platform trees in zinc are not really the same as devices tress in linux. Initially I tried to use linux device tree specification but in progress I realised, that zinc doesn't need some things and needs others. And with all the changes there's no reason to keep similar syntax.

First question: I don't know but I interpreted it the same as you.

Second question: The "platform trees" described in this post are not exactly the same as the "device trees" used by Linux on ARM (and also MIPS I think?). They are essentially the same concept, but device trees have their own DSL amd binary format. They are basically descriptions of the hardware om a system: the CPUs, the RAM, the peripherals. It allows the same kernel image to boot on multiple systems by intwrpreting the devicetree at boot time, rather than having to embed info about the system at compile time. You can get more info about device trees (a.k.a FDTs where F stands for "flattened") on devicetree.org and elinux.org.

Yes, that is usually what bare metal means.