
GERT: Run Go on Bare Metal ARMv7 - chuckdries
https://github.com/ycoroneos/G.E.R.T
======
arcticbull
I'm really not sure the drive for garbage collected languages in memory
constrained systems with no user recoverability. Seems like a recipe for a
device that just stops working from time to time.

Embedded systems, IMO, must be deterministic, reliable and consistent.
Introducing garbage collection violates these three principals. Without them,
how can you guarantee an interrupt can be reliably serviced in time? How can
you guarantee that memory growth won't be exhausted because of some unexpected
condition which prevents a timely GC? Many embedded systems developers don't
even use malloc() in lieu of static allocations so they can actually
understand their memory requirements.

It's either big enough for Linux, in which case have at it, or you need to
reconsider why you're down in the kilobytes of total memory with a garbage
collector.

~~~
zzalpha
_I 'm really not sure the drive for garbage collected languages in memory
constrained systems with no user recoverability. Seems like a recipe for a
device that just stops working from time to time._

J2ME would like to have a word with you...

~~~
sp0ck
J2ME is nowhere near being hard real-time. Minimal Java ME Embedded
configuration: 32-bit MCU, 130 KB RAM, 350 KB Flash/ROM. This is close to
border where systems have MMU and is considered very "big" configuration in
realm of embedded systems. 10-20 kB RAM/64kB flash is a lot for many many
applications. Rust seems to be on a good path to be the real C competitor in
general bare-metal development. Right now Cortex-M* family support is on level
when you can start writing some apps in it. I'm not considering Ada to be
mainstream.

~~~
pjmlp
J2ME is not the only game in town for embedded Java, check Aonix and Aicas
offerings instead.

As another example, MicroEJ is targeted at Cortex-M CPUs.

And there is also Astrobe selling Oberon-07 compilers for M3 and M4
processors.

> 32-bit MCU, 130 KB RAM, 350 KB Flash/ROM

Anything less than this is most certainly some kind of PIC, not everyone is
using them for embedded real-time deployments.

~~~
sp0ck
Correct me if I'm wrong: Aonix is not existing - it was bought by PTC. Their
real time Java is now targeting only x64/x86 systems.

You are wrong about "anything less" Anything less is probably 90% of market.
You will find 130kB RAM, 350kB flash only in high end products from NXP(LCP
family), Kinetis(KL family) or STI( STM family). You only need so much RAM for
JAVA :)

~~~
pjmlp
Yes, they were bought by PTC.

However I don't know what they have done with the PicoJava offerings, since
PTC isn't as friendly as Aonix regarding the making the documentation
available.

As for the market, it depends on which one the products built with those CPUs
are actually being sold to.

My Cisco phone and the Ricoh printer around the corner both are running some
form of embedded Java.

Maybe you think they are part of the remaining 10%, however Cisco and Ricoh
though it was worthwhile for their sales.

~~~
sp0ck
I believe we have different definition of embedded system. There are a lot of
them, for me simplest definition is CPU/uC system without MMU. Those Cisco
Ricoh gear have Linux running inside (at least for phone I have it's some
200MHz MIPS)

~~~
nickpsecurity
"I believe we have different definition of embedded system. "

Counterpoint:

[http://www.atmel.com/Images/45107A-Choosing-a-MCU-
Fredriksen...](http://www.atmel.com/Images/45107A-Choosing-a-MCU-
Fredriksen_Article_103114.pdf)

The 32-bit market was at $6 billion by 2014 per Amtel's report. There's also a
huge amount of sales for Windows Embedded and embedded Linux's. That
represents a significant chunk of a massive market. So, it's quite worthwhile
to call even a 32-bit-targeted, hard-real-time GC useful for "embedded"
systems. As he said, it's part of the standard definition used in the embedded
sector. The 32-bit side is going up rapidly, too, due to decreasing cost and
power usage.

EDIT: The specs on them are also starting to look like the desktops of old.
Actually, started to do that quite a while ago.

[https://cache.freescale.com/files/32bit/doc/fact_sheet/IMX7S...](https://cache.freescale.com/files/32bit/doc/fact_sheet/IMX7SRSFS.pdf)

------
kbumsik
Wow, it's a great piece of work. I was always wondering how to implement such
big golang runtime on bare-metal, but someone finally did it. I glad to have a
paper as well. So how big is the compiled binary of golang runtime? I hope it
would be small enough to port to Cortex-M series MCUs.

~~~
triplefault
Hi I'm the author of GERT. The size of the ELF for the laser projector program
is 2.1M so it probably will not fit on a cortex-m :(. Additionally, I don't
think GERT will be as useful on a single-core SOC as it is on a multicore chip
because blocking operations (like reading a UART) may literally take forever.
The memory safety can certainly be useful though! I'd say just start tinkering
and try it out. You can probably gut enough of the elf to get it to a few
hundred kilobytes.

------
Jhsto
Impressive work! One question though, what is the bootup time? There's the GIF
on the Github repository, but I can't accurately tell it from that.

Would it be possible for you to make a program that just exists and then time
the whole bootup process? Thank you.

I have a specific use-case and would be willing to buy the board if it is fast
enough.

------
bogomipz
>"The minimal set of OS primitives that Go relies on have been re-implemented
entirely in Go and Plan 9 assembly inside the modified runtime."

Is the minimal set of OS primitives that Go relies on documented anywhere?

~~~
cyphar
It looks like
[https://github.com/ycoroneos/golang_embedded](https://github.com/ycoroneos/golang_embedded)
gives details on what changes were necessary to the Go runtime package.

~~~
triplefault
That's correct. My thesis
([https://github.com/ycoroneos/G.E.R.T/blob/master/thesis/main...](https://github.com/ycoroneos/G.E.R.T/blob/master/thesis/main.pdf))
also has detailed info in chapter 3. The github documentation is still a work
in progress :P

~~~
cyphar
It's awesome that you've released your masters project under a free software
license. You see a lot of research that took several years of labour but wilts
away because it remained proprietary. Well done!

------
andreiw
Great. When will this target ARMv8 64-bit 'A' profile chips?

~~~
triplefault
It's planned. If ARMv8 had market penetration ~1.5 years ago, then I probably
would have started that way. One big issue with most SOCs is the lack of
publicly available data sheets for writing good drivers. That's also why I
picked the imx6Q; its data sheet is very detailed.

~~~
andreiw
I'd say that even two years ago most mobile phones being sold were already
ARMv8. That doesn't help with the SoC documentation, you're right that this
has been a consistent weak spot. Usually documentation is offered up or it
washes up only when the market relevancy of any one SoC approaches zero.
Before then, it's passworded up and jealously guarded. Makes no sense to me,
especially when you consider most of any one SoC to be consisting of reused
generic IP blocks. I mean, I can deal with an NDA for something tricky like
your new GPU, but that doesn't explain why I can't figure out the interrupt
routing or your clock and GPIO blocks.

If you're referring to ARM servers, then things are still pretty solid (it
takes a while to line up an entire hardware and software ecosystem, even in a
world where you're all set if it runs Linux). There are specs like SBSA and
SBBR that ensure servers from any SoC vendor look roughly the same, but I
would wonder why you would target bare metal in that case anyway. Have you
considered targeting ARMv8 VMs, like the one modeled by KVM/qemu? Extra bonus
in that it looks like an ARM server.

------
pjmlp
Congratulations on the work achieved.

It looks quite interesting.

------
wvh
I just updated Debian on my cubox-i (also iMX6) last week, which also runs
mostly Go code. Never thought that Go would be low-level enough to run on bare
hardware without replicating a lot of OS-level code. Interesting project,
thanks for sharing... I hope I get to check out how you did it when/if I have
some more time.

------
thatgerhard
haha that's my name!

