proposal: all: add bare metal ARM support

[abarisani]

Hello,

I'd like to request reconsideration of our previous proposal (declined) as there have been new simplifications in our patch that should solve some, if not all, concerns previously raised.

Small recap: our TamaGo project adds support for vanilla Go runtime and packages execution on ARMv7 bare metal. Please see the original issue which remains valid in its initial description.

The main changes of our most recent integration are as follows:

• we completely removed any ARM exception handling or low-level assembly, with the exception of rt0 entry point support (here and here, which is required and included in Go for all supported architectures and a CallOnG0 function to facilitate external integration of exception handlers (which is very similar to existing approaches).

• all remaining code is simple "glue" code adapter from other supported architectures and to extend support of a new GOOS keyword

• runtime support in os_tamago_arm.go is much reduced compared to the first proposed version and now consists only of stubs and simple "glue" code.

Overall our latest patch has ~4200 insertions over 133 files, however the overwhelming majority of changes are one-liners two add GOOS=tamago support, almost verbatim clones of existing code (lock_js.go > lock_tamago.go,, mem_plan9.go > mem_tamago.go) and os_tamago_arm.go remains the largest newly added file.

We think these changes should address the main concerns that resulted the rejection of our previous proposal.

Our new patch should not raise any longer concerns on chip erratas as it is as agnostic as possible in the low level management of SoC specific, or even ARM, architecture. It allows external packages to provide ARM support.

We demonstrated useful implementation of all Go packages, including os and net, for instance we successfully enable networking with gVisor in our Ethernet over USB driver.

Since our last issue we implemented a full Trusted Execution Environment (GoTEE) with this framework as well as a full OpenPGP/FIDO U2F smartcard (GoKey).

Others have expressed interest for running Go on the bare metal and we also received contributions which extend support to other platforms such as Raspberry PIs using the same original Go distribution patch.

Given the recent refactoring that takes chip errata concerns out of the way, provides a more minimal patch, and the recent demonstrations of what can be developed with this, I kindy ask re-consideration of our proposal.

Thanks!

[thanm]

Hello,

In the discussion of the previous proposal, there was some minimal talk about builders for GOOS=none, e.g. #37503 (comment) (which basically boils down to "Will there be a builder? Yes, there will be a builder.").

I think it would be useful to have a bit more concrete/detailed conversation about builder support.

To wit: suppose the proposal is accepted, and a GOOS=none builder is set up. Will this builder be capable of running "all.bash"? Will the builder provide full support for "gomote" operations? Suppose that someone from the Go team checks in a change to the compiler or linker, and a test fails on the GOOS=none builder. Who will look at that failure and how?

Thanks.

[abarisani]

all.bash currently runs on all tamago-go releases, I think overall builder and linker tests can happen identically to other architectures.

The challenge would only be for runtime tests that are written in a manner that depends on an OS being present, I am not sure how this is currently handled for platforms like plan9 or js. What I can say is that this can run under qemu.

[bcmills]

For JS, iOS, and Android, tests are run by having a separate host for builds and invoking the binaries using go_*_exec scripts:

~/go$ find . -name go_*_exec*
./misc/wasm/go_js_wasm_exec
./misc/ios/go_ios_exec.go
./misc/android/go_android_exec.go

Presumably the TamaGo builder would need a similar script.

[bcmills]

The challenge would only be for runtime tests that are written in a manner that depends on an OS being present, I am not sure how this is currently handled for platforms like plan9 or js.

Plan 9 can run the actual Go toolchain, albeit slowly.

For JS, Android, and iOS, cmd/dist distinguishes between tests that build and invoke Go subprocesses and tests that should run directly on the builder. (Search for registerHostTest in src/cmd/dist.)

Test binaries that contain a mix of the two can use internal/testenv.MustHaveExec to mark that they need an OS capable of starting subprocesses. If there are other bits of OS functionality that could be missing, they may need additional testenv functions.

[abarisani]

Understood, I see no problem in having a similar approach for TamaGo. We could provide an USB armory as separate host to receive the tests or maybe (easier) just have a script that spawns the test within qemu ?

[firelizzard18]

This may be of interest to @tinygo-org

/cc @deadprogram @aykevl @justinclift

[rsc]

Why is it difficult to maintain this tree as a GitHub fork of golang/go?

[abarisani]

It is currently not that difficult, but its inclusion upstream would help ensuring that a GOOS=none support is minded in relation to potentially breaking changes, that its quality is consistent with the rest of the Go distribution code and that it would remain available over time.

Secondarily it would also help promoting, and further develop, this use case among Go user base.

Allowing easier hooks to generic "GOOS=none" within Go can certainly spawn up more interesting uses beyond the specific TamaGo goals and implementation, so I think in general it would help the Go ecosystem.

[rsc]

What you are saying is that it would move the maintenance burden for this code off of your team and onto the Go contributors more generally. Saying "its inclusion upstream would help ensuring that a GOOS=none support is minded in relation to potentially breaking changes" is another way of saying "it would be yet another special case, little-used port that slows down maintenance and development of the primary ports", or perhaps of saying (without realizing it) "we don't intend to keep up with your changes and want you to do it".

Contribution of new ports are "free like a puppy", to use the old Sun line: they are a gift that will require significant time and effort to keep alive. We already have a bunch of those, and inevitably the contributors move on, leaving us responsible for either continued upkeep (which takes away time we could be working on changes that benefit far more users) or removing the port (which makes us the bad guys).

I would much rather figure out what is making it difficult to keep this port out of tree and fix those underlying issues. That would let you maintain the port as you see fit and decouple our development and yours. It would make clear who is responsible for ongoing maintenance and fixing issues. It would scale far better - we can't put every port into the main tree. And it would provide a model for the next niche port.

[mvdan]

I don't have a strong opinion either way, but: how does GOOS=none compare to, say, GOARCH=loong64? If the point is to have someone responsible for its maintenance in-tree, perhaps Andrea would be up for that.

[abarisani]

My team (more than once) expressed the firm intention to maintain this. Please stop saying that we want upstream inclusion to offload maintenance because this is simply not true.

This proposal specifically would ease integration of TamaGo like ports in Go, so the way I see it it specifically addresses the current challenges in doing so by acting as a generic ARM template and possibly in the future for other architectures.

This effort is to promote a generic framework and hooks to be accepted upstream with our contribution to maintain it.

[abarisani]

Let me be more clear and re-state my thinking. I think our patch specifically helps addressing the challenges in creating new ports of this kind and this is why we think it should be upstreamed (with our firm intention to maintain it at least for ARM).

It is not the intention of our proposal to just "offload" this for our own convenience. We are excited about using Go on the bare metal, promote its use and help make it easy for all while preserving this possibility in the process.