| *** tpb has joined #tomu | 00:00 | |
| *** futarisIRCcloud has joined #tomu | 00:42 | |
| *** drprune has joined #tomu | 01:43 | |
| drprune | I'm having trouble getting U2F working. | 01:43 |
|---|---|---|
| drprune | Built and flashed with own injected private key. | 01:44 |
| xobs | drprune: is it just not working? what os are you on? | 01:45 |
| drprune | tomu shows up in lsusb, but neither chrome nor firefox seems able to use it. | 01:45 |
| drprune | debian 9 | 01:45 |
| xobs | have you added a udev rule to give your username permission to access the /dev/ entry? | 01:45 |
| drprune | I added cut'n'pasta rule from website. | 01:46 |
| drprune | CTION=="add|change", KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="cdab", TAG+="uaccess" | 01:46 |
| drprune | plus one with ids from lsusb | 01:46 |
| drprune | Here is log when plugged in | 01:46 |
| drprune | Mar 20 14:30:47 eliot kernel: usb 3-3: new full-speed USB device number 34 using xhci_hcd | 01:47 |
| drprune | Mar 20 14:30:48 eliot kernel: usb 3-3: New USB device found, idVendor=16d0, idProduct=0e90 | 01:47 |
| drprune | Mar 20 14:30:48 eliot kernel: usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 | 01:47 |
| drprune | Mar 20 14:30:48 eliot kernel: usb 3-3: Product: U2F-token (EFM32) | 01:47 |
| drprune | Arrr, i guess I should read https://github.com/gl-sergei/u2f-token more thoroughly... | 01:49 |
| tpb | Title: GitHub - gl-sergei/u2f-token: u2f token firmware for stm32f103 and efm32hg boards (at github.com) | 01:49 |
| drprune | I followed instructions from https://tomu.im/ under "U2F / Fido firmware" | 01:53 |
| xobs | Hmm... and it sounds like that doesn't work with Debian 9 anymore? Did you get it working then? | 01:54 |
| drprune | Not yet. | 01:54 |
| drprune | Wondering if there is a lower level way to communicate with the token other than using a browser and test website | 01:55 |
| xobs | I do see a "libu2f-udev" package in Sid, but I don't know if that's useful. | 01:56 |
| drprune | Just backing up a bit. | 01:58 |
| drprune | if I visit https://demo.yubico.com/webauthn-technical/registration, and touch the key as requested, the red led comes on for a little while. But nothing happens in the browser. | 01:59 |
| tpb | Title: Yubico demo website (at demo.yubico.com) | 01:59 |
| xobs | Firefox? | 01:59 |
| drprune | firefox or google-chrome | 02:00 |
| drprune | FF has some prompts about the key | 02:01 |
| xobs | The 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 |
| drprune | Actually it seems the red led comes on any time I touch the RH pad | 02:05 |
| xobs | You know the pads are working, which is good! | 02:06 |
| drprune | I see there are a bunch of packages with 'u2f' in their name. Do I need any installed to use the token? | 02:10 |
| xobs | You shouldn't need that, no. U2F is just a specialized HID class, and your browser should be able to communicate with it. | 02:11 |
| xobs | They likely go over /dev/hidraw*, which your browser needs to be able to access. | 02:11 |
| xobs | I 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 |
| drprune | crw------- 1 root root 247, 0 Mar 20 14:32 /dev/hidraw0 | 02:12 |
| drprune | crw------- 1 root root 247, 1 Mar 20 14:59 /dev/hidraw1 | 02:12 |
| drprune | so... no user access. The "uaccess" tag is meant to do something about this? | 02:13 |
| drprune | I guess I can manually change perms and see if that works... | 02:14 |
| drprune | That changed things | 02:17 |
| xobs | It 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 |
| drprune | Now 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 |
| xobs | Perhaps "uaccess" is only a systemd thing, and if you're running a system without systemd then it won't work. | 02:18 |
| drprune | Nope, have systemd | 02:18 |
| *** Farscrap has quit IRC | 02:27 | |
| drprune | Sadly I can't continue down the rabbit hole at this point. Maybe back later... | 02:32 |
| xobs | Alright, take care! | 02:32 |
| drprune | xobs: thanks for trying | 02:32 |
| drprune | OK. I reflashed with the released v1.0 u2f-TOMU.bin, and initialised according to https://github.com/gl-sergei/u2f-token/releases | 03:33 |
| tpb | Title: Releases · gl-sergei/u2f-token · GitHub (at github.com) | 03:33 |
| drprune | Finally it is working! | 03:33 |
| xobs | Hooray! Glad it's working now :) | 03:33 |
| drprune | Now 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 #tomu | 03:41 | |
| *** samueldr has quit IRC | 04:21 | |
| *** rohitksingh_work has quit IRC | 04:26 | |
| *** rohitksingh_work has joined #tomu | 04:27 | |
| *** samueldr has joined #tomu | 04:29 | |
| drprune | for which I seems I need the .elf file of the firmware | 05:17 |
| *** futarisIRCcloud has quit IRC | 05:42 | |
| *** drprune has quit IRC | 05:44 | |
| *** futarisIRCcloud has joined #tomu | 06:27 | |
| *** drprune has joined #tomu | 07:28 | |
| *** ewen has joined #tomu | 08:13 | |
| ewen | xobs: the Fomu EVT3 schematic shows LEDs connected RGB0 = Red, RGB1 = Blue , RGB2 = Green | 08:15 |
| ewen | Eg, https://raw.githubusercontent.com/im-tomu/fomu-hardware/evt3/reference/tomu-fpga-evt3-sch.pdf | 08:15 |
| ewen | But experimentally it appears on EVT3 that RGB0 / user5 button controls Blue LED, and RGB1 / user6 button controls Red LED. | 08:16 |
| xobs | ewen: yeah, I got the footprint wrong. :( | 08:16 |
| xobs | I 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 |
| ewen | xobs: Aha! That explains my confusion lookng at the schematic. | 08:16 |
| xobs | I just discovered that yesterday. | 08:17 |
| MadHacker | Surely that's a "just relabel it" job. :) | 08:17 |
| ewen | Cool, so long as it's "expected behaviour" and not me misunderstanding :-) | 08:17 |
| MadHacker | Change the schematic and noone need ever know. ;) | 08:17 |
| ewen | xobs: I'm updating the blink example with comments for which channel is which... | 08:17 |
| xobs | ewen: thanks! Probably also a good idea to set the "RED" channel to the lowest possible current. | 08:18 |
| xobs | Well, second-lowest. | 08:18 |
| ewen | xobs: I started this investigation when I saw earlier you mentined the iCE40UP had a current level to its LED driver. | 08:18 |
| ewen | xobs: 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 |
| tnt | Lattice 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 |
| ewen | tnt: Consistency is hard :-) | 08:19 |
| xobs | That's what I get for blindly committing internal test code... | 08:19 |
| ewen | xobs: That's the EVT experience, right?! :-) | 08:20 |
| tnt | So 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 :p | 08:20 |
| ewen | For anyone following along at home, this is Lattice guide to LED driver module: https://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/IK/ICE40LEDDriverUsageGuide.ashx?document_id=50668 | 08:21 |
| ewen | (pages 19-20 ish are the relevant ones here) | 08:21 |
| ewen | tnt: That's also my experience of the LED driver. The choice is "rather bright" (4ma) through "OMG that's bright" (24ma) | 08:22 |
| tnt | yeah, at full power I can light up the room :p | 08:23 |
| ewen | tnt: Setting 4MA and half mode is reasonable though. | 08:23 |
| MadHacker | The constant currentness is important even if you need to PWM it. The LED has a maximum current rating. | 08:23 |
| MadHacker | It's generally an instantaneous specification. | 08:23 |
| tnt | Sure, 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 |
| ewen | MadHacker: 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 |
| MadHacker | tnt: 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 |
| MadHacker | Also the high end is a sensible drive current for bigger LED drivers for actual lighting work. | 08:26 |
| MadHacker | 24mA into a MOSFET gate is not insane at that sort of speed. | 08:27 |
| xobs | ewen: if you want to get fancy, you can use the SB_LEDDA_IP block to do things like adding a "breathe effect". | 08:28 |
| MadHacker | Our bare LEDs on a PCB are not normal in a packaged product really. :) | 08:28 |
| ewen | xobs: 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 |
| tnt | It'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 |
| MadHacker | Lattice seem to have some general weirdness. Apparently the HX4K is the HX8K relabelled too. | 08:34 |
| MadHacker | The other half of the die is present and correct, just has no I/O pins on the smaller packages. | 08:34 |
| tnt | yeah, that's not uncommon, all fpga vendor do that pretty much. | 08:34 |
| MadHacker | Mm, but you can actually use it via icestorm. :) | 08:35 |
| MadHacker | I'd be the first to recommend not doing so in a shipping product, but it's interesting. | 08:35 |
| ewen | xobs: https://github.com/im-tomu/fomu-tests/pull/3 has my local changes. I've possibly made the LEDs *too* dim for, eg, someone in sunshine. But they suit nighttime here :-) | 08:35 |
| tpb | Title: Blink brightness by ewenmcneill · Pull Request #3 · im-tomu/fomu-tests · GitHub (at github.com) | 08:35 |
| ewen | xobs: And there's localparam definitions of all values I could see in the datasheet to help someone tweak to their own preferences. | 08:36 |
| xobs | ewen: 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 |
| ewen | xobs: 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 |
| ewen | xobs: Maybe RGBA_CURRENT_MODE_{FULL,HALF}? | 08:43 |
| xobs | I 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 |
| ewen | xobs: Yes, that's confusing. But baked into the hardware as best I can tell :-) | 08:44 |
| ewen | xobs: 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 |
| ewen | xobs: I'm going to try renaming them to be less confusing.... | 08:47 |
| ewen | xobs: xobs: https://github.com/ewenmcneill/fomu-tests/blob/blink-brightness/blink/blink.v | 08:50 |
| tpb | Title: fomu-tests/blink.v at blink-brightness · ewenmcneill/fomu-tests · GitHub (at github.com) | 08:50 |
| ewen | xobs: ...CURRENT_MODE_{FULL,HALF}, and ...CURRENT_nnMA_ooMA. | 08:50 |
| ewen | If that looks better, I can make another pull request... | 08:51 |
| xobs | ewen: I think it's fine for now. Just keed to keep the "HALF" part in mind. | 08:52 |
| ewen | xobs: I'm less confused by these new names, so I've made: https://github.com/im-tomu/fomu-tests/pull/4 | 08:55 |
| tpb | Title: blink: less confusing RGB_CURRENT_nnMA names by ewenmcneill · Pull Request #4 · im-tomu/fomu-tests · GitHub (at github.com) | 08:55 |
| ewen | (If you hate it, just close the pull request :-) ) | 08:55 |
| xobs | ewen: I'll go ahead and merge it! | 08:57 |
| ewen | xobs: Thanks! (and goodnight :-) ) | 09:02 |
| xobs | Goodnight! | 09:03 |
| xobs | Goodnight! | 09:03 |
| 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 IRC | 09:07 | |
| *** ewen has quit IRC | 09:07 | |
| tnt | xobs: Might want to have a look at https://github.com/smunaut/ice40-playground/blob/experimental/projects/riscv_usb/fw/mini-printf.c | 09:08 |
| tpb | Title: ice40-playground/mini-printf.c at experimental · smunaut/ice40-playground · GitHub (at github.com) | 09:08 |
| xobs | tnt: I'm using a variant of tprintf, but even that one seems to require a divider: value /= radix; | 09:09 |
| tnt | mmm, right :/ | 09:10 |
| MadHacker | xobs: 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 |
| MadHacker | TBH 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 |
| xobs | MadHacker: I'll try that. | 09:35 |
| xobs | I'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 IRC | 09:49 | |
| MadHacker | Managing to fit it at all, never mind how good the result is, is doing pretty well. | 09:51 |
| *** awe00 has joined #tomu | 09:59 | |
| *** rohitksingh_work has quit IRC | 12:36 | |
| *** rohitksingh has joined #tomu | 13:32 | |
| *** rohitksingh has quit IRC | 13:42 | |
| mithro | http://beta.taricorp.net/2019/fomu-beginners-guide/ | 16:23 |
| tpb | Title: Fomu: a beginners guide · タリ (at beta.taricorp.net) | 16:23 |
| *** Kitlith_ has quit IRC | 16:31 | |
| *** Kitlith_ has joined #tomu | 16:34 | |
| *** awe00 has quit IRC | 17:25 | |
| *** imdeni has quit IRC | 18:38 | |
| *** jeroud has quit IRC | 18:39 | |
| *** elms has quit IRC | 18:39 | |
| *** johnhmay has quit IRC | 18:39 | |
| *** imdeni has joined #tomu | 18:40 | |
| *** jeroud has joined #tomu | 18:42 | |
| *** johnhmay has joined #tomu | 18:42 | |
| *** elms has joined #tomu | 18:42 | |
| *** awe00 has joined #tomu | 18:52 | |
| *** drprune has joined #tomu | 20:43 | |
| *** AmosSam has left #tomu | 20:51 | |
| *** AmosSam has joined #tomu | 20:55 | |
| *** awe00 has quit IRC | 21:47 | |
| *** cdmatter has quit IRC | 22:16 | |
| *** cdmatter has joined #tomu | 22:19 | |
| *** cdmatter has quit IRC | 22:24 | |
| *** cdmatter has joined #tomu | 22:25 | |
| *** drprune has quit IRC | 23:02 | |
| *** Farscrap has joined #tomu | 23:56 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!