| *** tpb has joined #tomu | 00:00 | |
| *** emeb has quit IRC | 00:25 | |
| *** stv0g has quit IRC | 00:46 | |
| *** AmosSam has joined #tomu | 02:28 | |
| futarisIRCcloud | https://twitter.com/GregDavill/status/1124475617791991808 | 03:38 |
|---|---|---|
| *** stv0g has joined #tomu | 03:46 | |
| *** stv0g has quit IRC | 03:50 | |
| *** stv0g has joined #tomu | 04:01 | |
| *** stv0g has quit IRC | 04:05 | |
| *** johnhmay has quit IRC | 04:18 | |
| *** johnhmay has joined #tomu | 04:22 | |
| *** shalzz has joined #tomu | 05:17 | |
| *** shalzz has quit IRC | 05:21 | |
| *** Guest86795 is now known as shalzz | 05:23 | |
| xobs | We discovered the cause of my windows laptop not working with Fomu. | 05:46 |
| xobs | I 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 #tomu | 06:01 | |
| *** stv0g has quit IRC | 06:05 | |
| futarisIRCcloud | xobs: That would do it. R8 & R9 are the two pull ups on the schematic? | 06:10 |
| tnt | xobs: ah yeah, I thought that would be dnp and just in case you had swapped dn/dp. | 06:12 |
| xobs | futarisIRCcloud: correct. So as a test we depopulated R8 and that solved the problem. | 06:12 |
| tnt | xobs: 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 |
| xobs | It 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 |
| futarisIRCcloud | xobs: 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 |
| xobs | futarisIRCcloud: 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 |
| futarisIRCcloud | xobs: Cool. It's a shame that the ID / OTG pin isn't connected on https://github.com/mwelling/latchup-badge/blob/master/latchup-badge.pdf though. Could always solder on a wire, if we wanted to do host / device (OTG) though... | 06:23 |
| tpb | Title: latchup-badge/latchup-badge.pdf at master · mwelling/latchup-badge · GitHub (at github.com) | 06:23 |
| futarisIRCcloud | Oh, and the latchup-badge only has pull-ups on D+ ... | 06:24 |
| xobs | I don't know that wire matters so much. | 06:24 |
| xobs | It's more to switch the device to host mode. | 06:25 |
| xobs | We could always just load host firmware. | 06:25 |
| futarisIRCcloud | that 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 |
| futarisIRCcloud | https://wiki.postmarketos.org/wiki/Serial_debugging | 06:34 |
| tpb | Title: Serial debugging - postmarketOS (at wiki.postmarketos.org) | 06:34 |
| xobs | On Love to Code, we run audio over that pin. | 06:34 |
| *** ewen has joined #tomu | 06:36 | |
| ewen | xobs: 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 |
| xobs | It's only an issue on evt boards. | 06:38 |
| *** stv0g has joined #tomu | 06:38 | |
| xobs | Tristating it should solve the problem, yes. | 06:39 |
| ewen | xobs: Always handy when there's a software patch :-) | 06:39 |
| futarisIRCcloud | Except if it's a 737 MAX. | 06:39 |
| futarisIRCcloud | https://spectrum.ieee.org/aerospace/aviation/how-the-boeing-737-max-disaster-looks-to-a-software-developer | 06:39 |
| ewen | futarisIRCcloud: 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 |
| xobs | Actually, assigning 0 to that pin also solved the problem. I guess because it's weak enough. | 06:42 |
| futarisIRCcloud | NB, I mentioned in #litex, the mimasv2 is too small for the vexriscv with linux-minimal. | 06:42 |
| xobs | But I should plonk down a tstriple. | 06:42 |
| *** stv0g has quit IRC | 06:42 | |
| *** AmosSam has left #tomu | 06:45 | |
| *** AmosSam has joined #tomu | 06:47 | |
| *** stv0g has joined #tomu | 08:38 | |
| *** stv0g has quit IRC | 08:42 | |
| *** stv0g has joined #tomu | 09:01 | |
| *** stv0g has quit IRC | 09:07 | |
| *** ewen has quit IRC | 09:15 | |
| *** stv0g has joined #tomu | 10:06 | |
| *** johnhmay has quit IRC | 10:14 | |
| *** johnhmay has joined #tomu | 10:14 | |
| *** AmosSam has left #tomu | 12:37 | |
| *** AmosSam has joined #tomu | 12:40 | |
| *** futarisIRCcloud has quit IRC | 15:03 | |
| *** stv0g has quit IRC | 16:17 | |
| *** xkapastel has joined #tomu | 19:15 | |
| *** AmosSam has left #tomu | 22:02 | |
| *** AmosSam has joined #tomu | 22:03 | |
| *** stv0g has joined #tomu | 22:06 | |
| * alexhw[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/opoIokYHsYsUQbuDqoObyaIz > | 22:33 | |
| xobs | alexhw (@alexhw:matrix.org): 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 #tomu | 22:40 | |
| xobs | If 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 |
| xobs | alexhw (@alexhw:matrix.org): 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 |
| xobs | Thanks again for looking so closely at this! | 22:53 |
| alexhw[m] | Sure, thanks for your support! | 22:53 |
| *** futarisIRCcloud has joined #tomu | 23:02 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!