Saturday, 2019-05-04

*** tpb has joined #tomu00:00
*** emeb has quit IRC00:25
*** stv0g has quit IRC00:46
*** AmosSam has joined #tomu02:28
*** stv0g has joined #tomu03:46
*** stv0g has quit IRC03:50
*** stv0g has joined #tomu04:01
*** stv0g has quit IRC04:05
*** johnhmay has quit IRC04:18
*** johnhmay has joined #tomu04:22
*** shalzz has joined #tomu05:17
*** shalzz has quit IRC05:21
*** Guest86795 is now known as shalzz05:23
xobsWe discovered the cause of my windows laptop not working with Fomu.05:46
xobsI put a pull up on both Dp and Dn, but only defined the Dp pull up. The Ice40 puts a weak pull up on any unassigned pin, so the Dn line got a nonzero resistance on it that the root hub was sensitive enough to detect.05:48
*** stv0g has joined #tomu06:01
*** stv0g has quit IRC06:05
futarisIRCcloudxobs: That would do it. R8 & R9 are the two pull ups on the schematic?06:10
tntxobs: ah yeah, I thought that would be dnp and just in case you had swapped dn/dp.06:12
xobsfutarisIRCcloud: correct. So as a test we depopulated R8 and that solved the problem.06:12
tntxobs: here my laptop is also sensitive enough to detect a device when the ice40 is unconfigured and has weak pullups on all the IOs ...06:12
xobsIt was more a hedge that we could actually do FS. Which was slightly in question.06:12
tnt(which is a bit annoying actually)06:13
futarisIRCcloudxobs: Could we implement USB Host on the ICE40?  The only electrical difference is 15k pull downs on the host side... (and power from the host)06:16
xobsfutarisIRCcloud: yes, that's definitely doable. We'd actually have to calculate crc5, and we'd need to detect hs/FS, but it's doable.06:19
futarisIRCcloudxobs: Cool. It's a shame that the ID / OTG pin isn't connected on though.  Could always solder on a wire, if we wanted to do host / device (OTG) though...06:23
tpbTitle: latchup-badge/latchup-badge.pdf at master · mwelling/latchup-badge · GitHub (at
futarisIRCcloudOh, and the latchup-badge only has pull-ups on D+ ...06:24
xobsI don't know that wire matters so much.06:24
xobsIt's more to switch the device to host mode.06:25
xobsWe could always just load host firmware.06:25
futarisIRCcloudthat wire is just a pull-up  / pull-down on OTG host cables.  Some mobiles use a different pull down resistor to switch the USB port into an alternate "serial" mode, i.e. RS232 over USB cables...06:33
tpbTitle: Serial debugging - postmarketOS (at
xobsOn Love to Code, we run audio over that pin.06:34
*** ewen has joined #tomu06:36
ewenxobs: That's a very useful discovery about R8.  Is it likely to be possible to put iCE40 pin sufficient tristate that it doesn't pull up enough to affect the detection?06:37
ewen(AFAICT from looking at PVT schematic, there's no R8 on that one.  Just EVTn boards, PVT? and maybe Hacker board?)06:37
xobsIt's only an issue on evt boards.06:38
*** stv0g has joined #tomu06:38
xobsTristating it should solve the problem, yes.06:39
ewenxobs: Always handy when there's a software patch :-)06:39
futarisIRCcloudExcept if it's a 737 MAX.06:39
ewenfutarisIRCcloud: Yes, that's a very good article.  They did have a software patch too... it's just the full version of the "software patch" was a "value add" extra.  Oops.06:41
xobsActually, assigning 0 to that pin also solved the problem. I guess because it's weak enough.06:42
futarisIRCcloudNB, I mentioned in #litex, the mimasv2 is too small for the vexriscv with linux-minimal.06:42
xobsBut I should plonk down a tstriple.06:42
*** stv0g has quit IRC06:42
*** AmosSam has left #tomu06:45
*** AmosSam has joined #tomu06:47
*** stv0g has joined #tomu08:38
*** stv0g has quit IRC08:42
*** stv0g has joined #tomu09:01
*** stv0g has quit IRC09:07
*** ewen has quit IRC09:15
*** stv0g has joined #tomu10:06
*** johnhmay has quit IRC10:14
*** johnhmay has joined #tomu10:14
*** AmosSam has left #tomu12:37
*** AmosSam has joined #tomu12:40
*** futarisIRCcloud has quit IRC15:03
*** stv0g has quit IRC16:17
*** xkapastel has joined #tomu19:15
*** AmosSam has left #tomu22:02
*** AmosSam has joined #tomu22:03
*** stv0g has joined #tomu22:06
* alexhw[m] sent a long message: < >22:33
xobsalexhw ( very complete analysis! I know that epmem should be more resource efficient, but at the moment it's way way too resource intensive in terms of LCs. I think it's on the order of 500% resource utilization. So I've been concentrating on epfifo instead, since that actually fits on real hardware.22:39
*** stv0g has left #tomu22:40
xobsIf you put the multireg back in, that's likely fine. I removed a lot of the multireg values because I assumed the pulses were large enough that there wasn't any issue with clock crossing, but that might not be correct.22:42
alexhw[m]xobs: the transition does not happen on a 12MHz clock edge. And the fsms change their state based on that signal, so I really think there should be a synchronisation/multireg (with 1 stage)22:46
alexhw[m]xobs:I'm working on fixing the rest of the failing unittests and then I'll update the pullrequest. This issue might be the cause of some problems you experience like the three additional received bytes. In the current state they might be a missed packet, where the data still ends up on the epfifo, but the transfer is not recognized as such.22:51
xobsalexhw ( that makes a lot of. I noticed I might also have an ordering issue in software, so I have a patch that might explain at least one of the extra bytes.22:52
xobsThanks again for looking so closely at this!22:53
alexhw[m]Sure, thanks for your support!22:53
*** futarisIRCcloud has joined #tomu23:02

Generated by 2.13.1 by Marius Gedminas - find it at!