Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gnuk port on tomu (experimental) #35

Merged
merged 2 commits into from Aug 21, 2018
Merged

Gnuk port on tomu (experimental) #35

merged 2 commits into from Aug 21, 2018

Conversation

aze00
Copy link

@aze00 aze00 commented Aug 20, 2018

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
Copy link
Member

xobs commented Aug 21, 2018

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.

@xobs xobs merged commit 520d31a into im-tomu:master Aug 21, 2018
@lsfxz
Copy link

lsfxz commented Dec 31, 2018

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
Copy link
Member

mithro commented Dec 31, 2018

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

@lsfxz
Copy link

lsfxz commented Dec 31, 2018

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
Copy link
Member

mithro commented Dec 31, 2018

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

@sowbug
Copy link

sowbug commented Jan 3, 2019

@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
Copy link

sowbug commented Jan 3, 2019

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
Copy link

lsfxz commented Jan 4, 2019

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
Copy link

fm0de commented Jan 18, 2019

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'
`

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants