Gnuk port on tomu (experimental)

[aze00]

This is still in early dev stage.

• only curve25516/ed25516 are supported.
• builds and fits in tomu flash/ram w/o a bootloader.
  • toboot + gnuk will be possible if flash is further reduced down by ~6kb
    this should be possible if the hw aes driver is implemented.
• builds and runs for linux emulation target with no regressions observed.

TODO:

• test on hardware
• hw aes implementation
• toboot compatibility
• merge back to upstream gnuk
  • improve configure and makefile for tomu
  • add options to disable crypto suites
  • add options to optimize code for size (do not unroll loops)

[xobs]

I think this is a great idea, and demonstrates yet another reason why this repo name should change. We have tomu-quickstart which is where you quickly get software running, and we have tomu-samples which is where the larger software projects seem to be collecting. Maybe a rename of this repo to tomu-software is in order.

I'll merge this for now, so that people know it's a thing that's happening. We should be sure to update the submodule version when it's more complete.

[lsfxz]

So I tried flashing it on a spare tomu I had lying around (flashing the gnuk.bin), with the result that absolutely nothing happens when plugging the tomu in (ie. nothing in dmesg; seems it's not recognized as a USB device at all).

Now I wonder if I did anything wrong, or if there's something I could do to help debugging the problem. My knowlegde of low level / embedded programming and debugging is rather limited, but I'm willing to learn – and I have usb2uart devices, an st-link v2 clone, a hydrabus and a few stm32f103 boards lying around, if any one of those would be used for debugging.

[mithro]

@lsfxz Did you update the bootloader before trying to flash the U2F firmware?

[lsfxz]

Not recently, but from my understanding the current gnuk.bin (not U2F, btw – U2F worked fine) is too large to be flashed next to toboot anyway (which seemed to still be the case as flashing via dfu didn't work for lack of space).

[mithro]

@lsfxz Oh, I don't know anything about the gnuk firmware -- sorry.

[sowbug]

@lsfxz not sure if this issue is the right place for ongoing getting-started discussion, but here's my (unsuccessful so far) attempt to flash a working gnuk to a tomu.

First of all, note that as of Ubuntu 18.04, building tomu is broken: im-tomu/tomu-quickstart#13. The symptom is that the build works, but the image doesn't do anything useful when you flash to the device -- just like what you saw.

I tried spinning up an Ubuntu 16.04 LTS image on a virtual server and building:

sudo apt install binutils-arm-none-eabi gcc-arm-none-eabi libnewlib-arm-none-eabi
git clone https://github.com/im-tomu/tomu-samples/
cd tomu-samples/
git submodule init
git submodule update
cd gnuk/
git submodule init
git submodule update
cd src/
./configure --target=TOMU --vidpid=234b:0000
make
(then scp build/gnuk.bin back to my workstation and flash it)

I was hopeful this would do something, but I saw nothing in lsusb. I'll continue updating this issue if I make any progress. Next step is to try bbcmicrobit/micropython#514 (comment).

[sowbug]

Rats: apparently I was running the fixed newlib already on 18.04. So that wasn't the problem, and the 16.04 expedition was a wild goose chase. I was able to flash my tomu back to toboot, so I do know that my stlink-v2/openocd setup is working correctly.

[lsfxz]

I'm on Arch with rather recent versions of arm-none-eabi-gcc, -binutils and -newlib, so yeah, that's probably not the issue (in my case, at least) – but with comparable "symptoms" it could have been, so the goose-chasing is understandable ;)

[fm0de]

I can confirm this.
Flashing with openocd works fine but nothing is detected on USB. Nothing in dmesg. And for working with DFU the resulting binary is about 6kB to big.
When trying to compile with --enable-debug it fails withgnuk/src/usb_ctrl.c:177: undefined reference to usb_lld_setup_endpoint'
`