Wednesday, 2019-03-20

*** tpb has joined #tomu00:00
*** futarisIRCcloud has joined #tomu00:42
*** drprune has joined #tomu01:43
drpruneI'm having trouble getting U2F working.01:43
drpruneBuilt and flashed with own injected private key.01:44
xobsdrprune: is it just not working? what os are you on?01:45
drprunetomu shows up in lsusb, but neither chrome nor firefox seems able to use it.01:45
drprunedebian 901:45
xobshave you added a udev rule to give your username permission to access the /dev/ entry?01:45
drpruneI added cut'n'pasta rule from website.01:46
drpruneCTION=="add|change", KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="cdab", TAG+="uaccess"01:46
drpruneplus one with ids from lsusb01:46
drpruneHere is log when plugged in01:46
drpruneMar 20 14:30:47 eliot kernel: usb 3-3: new full-speed USB device number 34 using xhci_hcd01:47
drpruneMar 20 14:30:48 eliot kernel: usb 3-3: New USB device found, idVendor=16d0, idProduct=0e9001:47
drpruneMar 20 14:30:48 eliot kernel: usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=301:47
drpruneMar 20 14:30:48 eliot kernel: usb 3-3: Product: U2F-token (EFM32)01:47
drpruneArrr, i guess I should read more thoroughly...01:49
tpbTitle: GitHub - gl-sergei/u2f-token: u2f token firmware for stm32f103 and efm32hg boards (at
drpruneI followed instructions from under "U2F / Fido firmware"01:53
xobsHmm... and it sounds like that doesn't work with Debian 9 anymore?  Did you get it working then?01:54
drpruneNot yet.01:54
drpruneWondering if there is a lower level way to communicate with the token other than using a browser and test website01:55
xobsI do see a "libu2f-udev" package in Sid, but I don't know if that's useful.01:56
drpruneJust backing up a bit.01:58
drpruneif I visit, and touch the key as requested, the red led comes on for a little while. But nothing happens in the browser.01:59
tpbTitle: Yubico demo website (at
drprunefirefox or google-chrome02:00
drpruneFF has some prompts about the key02:01
xobsThe blinking is a good sign.  Can you try to make sure you touch the copper, just to see if it isn't a touchpad issue?02:02
drpruneActually it seems the red led comes on any time I touch the RH pad02:05
xobsYou know the pads are working, which is good!02:06
drpruneI see there are a bunch of packages with 'u2f' in their name. Do I need any installed to use the token?02:10
xobsYou shouldn't need that, no. U2F is just a specialized HID class, and your browser should be able to communicate with it.02:11
xobsThey likely go over /dev/hidraw*, which your browser needs to be able to access.02:11
xobsI think that's what the "uaccess" flag is, but udev is weird and mysterious.  You can try just opening up permissions on /dev/hidraw* and seeing if that helps things, though...02:12
drprunecrw------- 1 root root 247, 0 Mar 20 14:32 /dev/hidraw002:12
drprunecrw------- 1 root root 247, 1 Mar 20 14:59 /dev/hidraw102:12
drpruneso... no user access.  The "uaccess" tag is meant to do something about this?02:13
drpruneI guess I can manually change perms and see if that works...02:14
drpruneThat changed things02:17
xobsIt looks like "uaccess" means "allow access to this device to any active user session".  So it could be that your kernel doesn't support uaccess, or that the idProduct and idVendor are swapped or incorrect, or the udev rule isn't getting evaluated, or that you're not accessing it via an active session.02:17
drpruneNow when I try the browser, the key starts flashing rapidly. Then tap the key, the red led stays on. Aaaand it stuck in that state.02:18
xobsPerhaps "uaccess" is only a systemd thing, and if you're running a system without systemd then it won't work.02:18
drpruneNope, have systemd02:18
*** Farscrap has quit IRC02:27
drpruneSadly I can't continue down the rabbit hole at this point.  Maybe back later...02:32
xobsAlright, take care!02:32
drprunexobs: thanks for trying02:32
drpruneOK. I reflashed with the released v1.0 u2f-TOMU.bin, and initialised according to
tpbTitle: Releases · gl-sergei/u2f-token · GitHub (at
drpruneFinally it is working!03:33
xobsHooray!  Glad it's working now :)03:33
drpruneNow I think I should go back to injecting a private key generated on the host, so I don't lose it on firmware upgrade...03:35
*** rohitksingh_work has joined #tomu03:41
*** samueldr has quit IRC04:21
*** rohitksingh_work has quit IRC04:26
*** rohitksingh_work has joined #tomu04:27
*** samueldr has joined #tomu04:29
drprunefor which I seems I need the .elf file of the firmware05:17
*** futarisIRCcloud has quit IRC05:42
*** drprune has quit IRC05:44
*** futarisIRCcloud has joined #tomu06:27
*** drprune has joined #tomu07:28
*** ewen has joined #tomu08:13
ewenxobs: the Fomu EVT3 schematic shows LEDs connected RGB0 = Red, RGB1 = Blue , RGB2 = Green08:15
ewenBut experimentally it appears on EVT3 that RGB0 / user5 button controls Blue LED, and RGB1 / user6 button controls Red LED.08:16
xobsewen: yeah, I got the footprint wrong. :(08:16
xobsI swapped pins 1 and 2, which isn't actually a problem because pin 4 is the key, and it's 3.3V, which is correct.08:16
ewenxobs: Aha!  That explains my confusion lookng at the schematic.08:16
xobsI just discovered that yesterday.08:17
MadHackerSurely that's a "just relabel it" job. :)08:17
ewenCool, so long as it's "expected behaviour" and not me misunderstanding :-)08:17
MadHackerChange the schematic and noone need ever know. ;)08:17
ewenxobs: I'm updating the blink example with comments for which channel is which...08:17
xobsewen: thanks!  Probably also a good idea to set the "RED" channel to the lowest possible current.08:18
xobsWell, second-lowest.08:18
ewenxobs: I started this investigation when I saw earlier you mentined the iCE40UP had a current level to its LED driver.08:18
ewenxobs: So, yes, I'll set them lower.  (The 8ma / 16ma / 24ma comments are also misleading, as they were set to the same value...)08:19
tntLattice even gets it wrong ... betweent he U4k and UP5k (which are otherwise perfectly pin to pin compatbile), the RGB0..2  got swapped 0->2  1->1  2->0 ...08:19
ewentnt: Consistency is hard :-)08:19
xobsThat's what I get for blindly committing internal test code...08:19
ewenxobs: That's the EVT experience, right?! :-)08:20
tntSo far I found that constant current driver pretty ... usless with the led I have. They are blindingly bright even at the lower current setting with half current mode enabled. I hve to also PWM them to 10% for it to be an acceptable brightnes :p08:20
ewenFor anyone following along at home, this is Lattice guide to LED driver module:
ewen(pages 19-20 ish are the relevant ones here)08:21
ewentnt: That's also my experience of the LED driver.  The choice is "rather bright" (4ma) through "OMG that's bright" (24ma)08:22
tntyeah, at full power I can light up the room :p08:23
ewentnt: Setting 4MA and half mode is reasonable though.08:23
MadHackerThe constant currentness is important even if you need to PWM it. The LED has a maximum current rating.08:23
MadHackerIt's generally an instantaneous specification.08:23
tntSure, I meant more the 'range' is not especially useful. Like a 100 uA to 5 mA range would have been more useful (at least for me).08:24
ewenMadHacker: From what I can tell of this example code, the RGB0 (Blue) and RGB1 (Red) are effectively not PWM'd, but the RGB2 (Green) is kinda PWM'd off some of the counter bits (but possibly changed faster than the PWM)08:24
MadHackertnt: It's about the right range for generic indicator LEDs. The high end is good for "bright light that shines through thin white plastic case", and the low end is fine for "User stares directly into LED".08:26
MadHacker(with appropriate LEDs, of course)08:26
MadHackerAlso the high end is a sensible drive current for bigger LED drivers for actual lighting work.08:26
MadHacker24mA into a MOSFET gate is not insane at that sort of speed.08:27
xobsewen: if you want to get fancy, you can use the SB_LEDDA_IP block to do things like adding a "breathe effect".08:28
MadHackerOur bare LEDs on a PCB are not normal in a packaged product really. :)08:28
ewenxobs: Yes, I saw that comment, and thought it'd be fun to investigate.  This is the first *actual* Verilog change I've written though...08:29
tntIt's funny how the iCE5LP1K and 2K have SB_LEDDA_IP but not iCE5LP4K ... Apparently the actual hardip in there is broken and doesn't work and so it gets replaced by a soft IP in fabric by icecube. (and that IP uses 'extra' resources that's available in the 1k and 2k part because it's all the same die), but of course for the 4k all logic is available to the user so they can't create that softip in it without stealing logic from the user ...08:32
MadHackerLattice seem to have some general weirdness. Apparently the HX4K is the HX8K relabelled too.08:34
MadHackerThe other half of the die is present and correct, just has no I/O pins on the smaller packages.08:34
tntyeah, that's not uncommon, all fpga vendor do that pretty much.08:34
MadHackerMm, but you can actually use it via icestorm. :)08:35
MadHackerI'd be the first to recommend not doing so in a shipping product, but it's interesting.08:35
ewenxobs: has my local changes.  I've possibly made the LEDs *too* dim for, eg, someone in sunshine.  But they suit nighttime here :-)08:35
tpbTitle: Blink brightness by ewenmcneill · Pull Request #3 · im-tomu/fomu-tests · GitHub (at
ewenxobs: And there's localparam definitions of all values I could see in the datasheet to help someone tweak to their own preferences.08:36
xobsewen: thanks! my only comment would be that "FULL" and "HALF" might be a bit misleading, but that's fine. it looks good, and removes a lot of the ambiguity.08:38
ewenxobs: We can call them something else if you've got a better idea.  The datasheet calls them "full current mode" and "half current mode"....08:43
ewenxobs: Maybe RGBA_CURRENT_MODE_{FULL,HALF}?08:43
xobsI meant that you have "FULL", and then go defparam RGBA_DRIVER.RGB0_CURRENT = RGBA_CURRENT_8MA, which is actually 4mA when setting "HALF".  It's confusing, but that's just how it is.08:44
ewenxobs: Yes, that's confusing.  But baked into the hardware as best I can tell :-)08:44
ewenxobs: Technically p20 of the LED Guide doesn't actually give them names.08:45
ewen(Just describes what they mean in each mode.)08:45
ewenxobs: I'm going to try renaming them to be less confusing....08:47
ewenxobs: xobs:
tpbTitle: fomu-tests/blink.v at blink-brightness · ewenmcneill/fomu-tests · GitHub (at
ewenxobs: ...CURRENT_MODE_{FULL,HALF}, and ...CURRENT_nnMA_ooMA.08:50
ewenIf that looks better, I can make another pull request...08:51
xobsewen: I think it's fine for now. Just keed to keep the "HALF" part in mind.08:52
ewenxobs: I'm less confused by these new names, so I've made:
tpbTitle: blink: less confusing RGB_CURRENT_nnMA names by ewenmcneill · Pull Request #4 · im-tomu/fomu-tests · GitHub (at
ewen(If you hate it, just close the pull request :-) )08:55
xobsewen: I'll go ahead and merge it!08:57
ewenxobs: Thanks!  (and goodnight :-) )09:02
xobs...right, I've just discovered that apparently it helps to have division enabled on the CPU when using printf("%x")09:06
*** futarisIRCcloud has quit IRC09:07
*** ewen has quit IRC09:07
tntxobs: Might want to have a look at
tpbTitle: ice40-playground/mini-printf.c at experimental · smunaut/ice40-playground · GitHub (at
xobstnt: I'm using a variant of tprintf, but even that one seems to require a divider: value /= radix;09:09
tntmmm, right :/09:10
MadHackerxobs: If you know your radices can only be 10 and 16, you could just code in the shifts and subtractions instead.09:32
MadHacker%d and %x are presumably all you actually need to accommodate.09:33
MadHackerTBH just putting in a check that forces them to those two values is probably enough; the compiler will probably optimise the division away at that point.09:33
xobsMadHacker: I'll try that.09:35
xobsI'm honestly kinda surprised at nextpnr that it's able to place and route an FPGA that's 96% full.  It doesn't meet timing, but that's not the point.09:39
*** drprune has quit IRC09:49
MadHackerManaging to fit it at all, never mind how good the result is, is doing pretty well.09:51
*** awe00 has joined #tomu09:59
*** rohitksingh_work has quit IRC12:36
*** rohitksingh has joined #tomu13:32
*** rohitksingh has quit IRC13:42
tpbTitle: Fomu: a beginners guide · タリ (at
*** Kitlith_ has quit IRC16:31
*** Kitlith_ has joined #tomu16:34
*** awe00 has quit IRC17:25
*** imdeni has quit IRC18:38
*** jeroud has quit IRC18:39
*** elms has quit IRC18:39
*** johnhmay has quit IRC18:39
*** imdeni has joined #tomu18:40
*** jeroud has joined #tomu18:42
*** johnhmay has joined #tomu18:42
*** elms has joined #tomu18:42
*** awe00 has joined #tomu18:52
*** drprune has joined #tomu20:43
*** AmosSam has left #tomu20:51
*** AmosSam has joined #tomu20:55
*** awe00 has quit IRC21:47
*** cdmatter has quit IRC22:16
*** cdmatter has joined #tomu22:19
*** cdmatter has quit IRC22:24
*** cdmatter has joined #tomu22:25
*** drprune has quit IRC23:02
*** Farscrap has joined #tomu23:56

Generated by 2.13.1 by Marius Gedminas - find it at!