lcarsip

TinyGo targets an entirely different class of systems and is not something that can be upstream being a different compiler, see https://github.com/usbarmory/tamago/wiki/Frequently-Asked-Qu...

printk is the low level primitive for stdout printing and it's done this way as low level drivers generally only accept single characters.

There are upper level functions which simply takes a []byte and make fmt.Printf() work seamlessly and effectively when not printing on an UART that only takes a single character as output.

In TamaGo stdout is primarily used for debugging.

Real-time has very little to do with the motivation behind this project or writing on bare metal.

We are writing on bare metal to get rid of hundreds of dependencies and millions of lines of unnecessary code to run single-purpose firmware applications.

As an example, if you want to write a cryptocurrency wallet using Go crypto and web libraries, wouldn't it better to do so without the burden of an entire Linux kernel, its userspace and a complex bootloader?

Please check this presentation for more background on motivations behind this project:

https://www.youtube.com/watch?v=4QircrJjEtQ

Example #1: https://github.com/f-secure-foundry/GoKey

Example #2: https://twitter.com/AndreaBarisani/status/130368998099743949...

(which runs, on the USB armory Mk II, a modified version of https://github.com/f-secure-foundry/armory-ums)

gokrazy is not bare metal as it bundles a Linux kernel, so it's basically a mini-Linux distro and therefore quite different.

The Secure Boot feature (https://github.com/f-secure-foundry/usbarmory/wiki/Secure-bo...) in concert with full disk encryption prevent anyone from extracting keys.

When used in combination with user supplied passphrases this leaves little chance for physical attacks.

The two external security elements have active protection against glitching and side channel.

We found no mechanical issue with the board.

While developing TamaGo I have plugged/unplugged it about 200 times a day for months ;).

Yes, however it is pretty much identical to the non-NDA'ed ATECC508.

Also the ATECC608A library from Microchip is open source and you can gather all necessary info from there.

Then we also have the NXP AT71CH with all info available publicly.

We took part of in the original HAB disclosure process for the NXP i.MX series and we carry on testing these parts.

Please see https://github.com/f-secure-foundry/advisories

Of course all P/Ns used for the Mk II have a patched boot ROM, please see https://github.com/f-secure-foundry/usbarmory/wiki/Secure-bo....

The original Mk I was 6 layers in the end, the Mk II is also 6 layers.

And yes the BOM cost is considerable due to its specifications.

The i.MX SoC core we use is comparable to a 1st gen Raspberry PI in speed, but of course slower than newer multi-core ones.

However security and form factor, rather than pure speed, is our goal. For the intent and purposes of the board performance is more than adequate.

Some benchmarks here: https://github.com/f-secure-foundry/usbarmory/wiki/Benchmark...

The production costs are way more than 15 USD, you have to account for the 6 layers PCB, assembly and a BOM which is higher than what you suggest.

We can take costs down a little more with larger numbers but not by a great margin.

The assembly process of Type-C plugs is also time consuming and therefore costly.