00:57 <bb-m-labs> build #630 of artiq-win64-test is complete: Warnings [warnings python_coverage] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/630 blamelist: whitequark <whitequark@whitequark.org>

01:00 <bb-m-labs> build #1842 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1842

01:48 <sb0> dlrobertson, yes, we have many difficult smoltcp bugs

01:50 <sb0> eg https://github.com/m-labs/smoltcp/issues/93

02:52 <GitHub26> [artiq] sbourdeauducq commented on issue #856: The following change to MiSoC breaks serwb 100%:... https://github.com/m-labs/artiq/issues/856#issuecomment-352227890

03:00 <sb0> so, the si5324 will lock fine to the system clock, but almost never lock to rgmii_rx_clock

03:01 <sb0> what the hell is going on

03:01 <sb0> vivado trash not connecting rgmii_rx_clock correctly to the lvds output buffer?

03:44 <GitHub95> [artiq] sbourdeauducq commented on issue #854: I tried that on my design, and the data corruption is different depending whether I use the inverted clock with swapped nibbles, or the non-inverted clock with .... https://github.com/m-labs/artiq/issues/854#issuecomment-352229766

03:46 <GitHub172> [artiq] sbourdeauducq commented on issue #854: I tried that on my design, and the data corruption is different depending whether I use the inverted clock with swapped nibbles, or the non-inverted clock with the original ordering.... https://github.com/m-labs/artiq/issues/854#issuecomment-352229766

03:48 <GitHub119> [artiq] sbourdeauducq commented on issue #854: I tried that on my design, and the data corruption is different depending whether I use the inverted clock with swapped nibbles, or the non-inverted clock with the original ordering.... https://github.com/m-labs/artiq/issues/854#issuecomment-352229766

03:58 <GitHub188> [artiq] sbourdeauducq commented on issue #854: @gkasprow Did you have to use those constraints to get the design working?... https://github.com/m-labs/artiq/issues/854#issuecomment-352230219

04:43 <sb0> why are the mmc jtag signals going both to the regular 10-pin ARM mini-connector and the SCANSTA?

04:43 <sb0> is the SCANSTA going to interfere?

04:44 <dlrobertson> sb0: interesting... I don't know much about artiq, but (I think) I was able to repro this using one of the smoltcp examples

04:44 <sb0> "you can just ignore the MMC/SCANSTA" - Greg and Joe. good one...

05:41 <sb0> dlrobertson, good

07:52 <sb0> oh amazing, openocd connects to the mmc without any shenanigans

07:59 <sb0> ah but then opencd freezes during flashing, and one sayma bricked. that's more like it!

07:59 <sb0> Error: Failed to read memory and, additionally, failed to find out where

08:37 <sb0> # After reset, the chip is clocked by an internal RC oscillator.

08:37 <sb0> # When board-specific code (reset-init handler or device firmware)

08:37 <sb0> # configures another oscillator and/or PLL0, set CCLK to match; if

08:37 <sb0> # you don't, then flash erase and write operations may misbehave.

08:37 <sb0> quality design right there again

08:42 <sb0> whitequark, you ordered another ARM JTAG programmer a while ago, did it arrive?

08:45 <sb0> this mmc thing even has a sdram controller and a 1024x768 TFT panel driver built in. one could run linux on that chip...

08:45 <sb0> ah, not that particular one

08:45 <sb0> no LCD

10:00 <GitHub152> [artiq] gkasprow commented on issue #854: Initially I used these constraints but the compilation took >10h. So I relaxed them, compilation takes much less but this may cause issues with timings https://github.com/m-labs/artiq/issues/854#issuecomment-352244338

10:01 <GitHub85> [artiq] gkasprow commented on issue #854: @sbourdeauducq I can route the clock with piece of wire to the clock pin in another bank. https://github.com/m-labs/artiq/issues/854#issuecomment-352244364

10:04 <GitHub92> [artiq] sbourdeauducq commented on issue #854: How hard is that rework? https://github.com/m-labs/artiq/issues/854#issuecomment-352244520

10:43 <GitHub19> [artiq] enjoy-digital commented on issue #856: Hmm ok, at least this can help me understand what is going on. https://github.com/m-labs/artiq/issues/856#issuecomment-352246558

11:20 <whitequark> sb0: did I order it? let me dig through invoices

11:21 <whitequark> sb0: nope, only one order from 1bitsquared in my folder. I think you insisted very much that you don't need that programmer, so I didn't order

11:22 <whitequark> or at least that's what I recall

11:43 <whitequark> sb0: I don't think #93 is difficult

11:45 <dob910> ▄▄▄▄▄▄▄▄▄▄▄▄ HAPPY NIGGER DAY!! PLEASE SAY HI TO ALL THE DUMB NIGGERS IN #OFTC...quicktalkeh676te.onion/6697cfxxrdjb: felix_ G33KatWork _florent_ mumptai_ balrog _whitelogger dlrobertson sandeepkr X-Scale kyak ashafir rqou Ishan_Bansal halfr1 cr1901_modern ho whitequark Gurty wolfspraul rjo sb0 ▄▄▄▄▄

11:54 <sb0> wtf

12:00 <sb0> whitequark, in any case the smoltcp bugs are causing a lot of problems and should be prioritized

12:01 <cr1901_modern> That spam is like something you'd seen on a particular group of imageboards...

12:13 <whitequark> sb0: yes, I am working on them right now

16:28 <GitHub52> [smoltcp] dlrobertson commented on issue #50: Can this be closed? smoltcp is the redox network stack since redox-os/netstack#4. There are still some relevant issues that @batonius mentions that are still not yet implemented, but maybe they should be split out into separate issues? https://github.com/m-labs/smoltcp/issues/50#issuecomment-352267551

16:34 <GitHub181> [artiq] gkasprow commented on issue #854: It would be not that hard.... https://github.com/m-labs/artiq/issues/854#issuecomment-352268006

16:35 <GitHub50> [artiq] gkasprow commented on issue #854: DIO0 is highlighted here. This is bottom view.... https://github.com/m-labs/artiq/issues/854#issuecomment-352268062

17:26 <GitHub161> [smoltcp] dlrobertson opened issue #95: Create Repr and/or Packet Builder types https://github.com/m-labs/smoltcp/issues/95

19:01 <GitHub162> [smoltcp] whitequark commented on issue #95: How would `Repr` builders even work for enum `Repr`s https://github.com/m-labs/smoltcp/issues/95#issuecomment-352277250

19:01 <GitHub186> [smoltcp] whitequark commented on issue #95: How would `Repr` builders even work for enum `Repr`s? https://github.com/m-labs/smoltcp/issues/95#issuecomment-352277250

19:26 <GitHub70> [smoltcp] dlrobertson commented on issue #95: Great question. Honestly, I didn't consider the enum `Repr` case. I guess you could have something like `ReprBuilder::new(<enum type>)` that returns a different builder for each enum type? Otherwise I guess you'd have to store a `type` member and all of the optional data required for each variant. Either way isn't ideal. https://github.com/m-labs/smoltcp/issues/95#issu

20:14 <GitHub144> [smoltcp] whitequark commented on issue #95: IMO there is no particular need for this, and in light of the `enum` case there seems no obvious elegant solution either. I am open to reconsideration if a future use case comes up, of course. https://github.com/m-labs/smoltcp/issues/95#issuecomment-352282018

20:14 <GitHub22> [smoltcp] whitequark closed issue #95: Create Repr and/or Packet Builder types https://github.com/m-labs/smoltcp/issues/95

20:15 <GitHub57> [smoltcp] whitequark commented on issue #35: @dlrobertson Could you take a look at this, please? It's been getting annoying. https://github.com/m-labs/smoltcp/issues/35#issuecomment-352282077

20:25 <GitHub148> [smoltcp] whitequark commented on issue #50: > smoltcp doesn't support loopback interface, an attempt to connect to 127.0.0.1 results in a flood of ARP requests asking for the MAC address of 127.0.0.1.... https://github.com/m-labs/smoltcp/issues/50#issuecomment-352282704

20:25 <GitHub51> [smoltcp] whitequark closed issue #50: smoltcp as Redox network stack https://github.com/m-labs/smoltcp/issues/50

21:16 <GitHub107> [smoltcp] dlrobertson commented on issue #35: Sounds good https://github.com/m-labs/smoltcp/issues/35#issuecomment-352286182