sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<GitHub104>
[artiq] sbourdeauducq commented on issue #854: @gkasprow Thanks! Looks good. Please double-check that the particular SFP/RJ45 module you are shipping works with Sayma in the MII configuration. https://github.com/m-labs/artiq/issues/854#issuecomment-354217182
<sb0>
whitequark, did you test your changes on sayma?
<sb0>
oh it's generating it for both C and Rust...
<sb0>
this gets complicated. who's using LM32 anyway?
* cr1901_modern
raises hand
<cr1901_modern>
also mithro is
<cr1901_modern>
Not to mention I wasn't able to compile the or1k toolchain on Windows last I tried
<whitequark>
sb0: why wouldn't it work on sayms?
<whitequark>
*sayma?
<whitequark>
or rather which changes do you mean specifically?
<sb0>
sdram
<sb0>
change of flash addresses
<whitequark>
sdram generates the byte-for-byte identical output for sdram_phy.h
<whitequark>
except for whitespace
<sb0>
ok
<whitequark>
change of flash addresses, no, but it seems unlikely to break
<whitequark>
what's the software workflow with sayma? I never touched it
<sb0>
same as kc705, except that the boards fail from time to time and need power-cycling the relay on ttyACM0
<whitequark>
oh ok
<sb0>
and the vivado trash uses much more RAM and CPU time, too
<whitequark>
cr1901_modern: mithro: sb0: *devilish grin* how about we port rust to lm32 and then just kill gcc and c in misoc completely
<sb0>
whitequark, no time for this
<whitequark>
not a serious suggestion
<cr1901_modern>
whitequark: Although it is not a serious suggestion, I am not against this
<whitequark>
though I've eliminated all C code in ARTIQ except for unwinder and libm
<whitequark>
(not all pushed yet, and not all tested yet, but soon)
<whitequark>
it'll have its own bootloader, and compiler-rt and the rest of the support junk is already all ported to rust
<whitequark>
i'm really looking forward to being able to just point lldb to `target remote kc705:1234` and debug the panicked system instead of the perversion we have right now
<sb0>
early in Sayma I suggested we keep a kintex-7, and of course this is causing problems right now in the form of additional vivado bloat (and code like sdram, gth, etc. that needed to be rewritten)...
<sb0>
also there is nothing wrong with winmodems, except they lacked documentation, and FOSS people sucked at signal processing back then. the latter issue seems to have significantly changed.
<cr1901_modern>
Is winmodem support not shit anymore?
<whitequark>
ah, okay
<sb0>
from a purist FOSS perspective, winmodems are actually a good thing: it can replace proprietary DSP with free software
<cr1901_modern>
Support for them was awful the last time I tried it (2011s) and I figured they would've gone the way of the dodo by now
<whitequark>
well yes, we have LTE modems now, which have linux with way more proprietary DSP on them
<whitequark>
in a way it's even worse
<whitequark>
sb0: am I right in that I can make a "bitstream" that solely sets the USR_ACCESS primitive?
<sb0>
whitequark, from my understanding of xilinx architecture yes
<whitequark>
ok
<sb0>
try using rjo3's python tool
<sb0>
but this will have to be supported on ultrascale (sayma), artix-7 (kasli), and kintex-7 (kc705)
<whitequark>
yes, I have that in open tabs
<sb0>
sounds like a bit of hassle
<whitequark>
well
<whitequark>
I guess, but I want to have a reliable debug/boot/flash flow
<whitequark>
right now e.g. if the firmware goes into a bootloop, it's a pain
<whitequark>
I have to go do the typical embedded recovery shit
<GitHub136>
[smoltcp] whitequark commented on pull request #110 728415e: Ummmm, no. The *whole point* of having newtypes here is so that *timestamps* (absolute) and *intervals* (relative) cannot be accidentally mixed (which happened several times). https://github.com/m-labs/smoltcp/pull/110#discussion_r158898150
<GitHub126>
[smoltcp] dlrobertson commented on issue #110: I wanted to get feedback on the actual `Timestamp` structure before substituting all of the `timestamp: u64` locations with it. I wasn't entirely sure what all of the requirements were for this type. At the moment the assumption is that it is a little more than a fancy integer. https://github.com/m-labs/smoltcp/pull/110#issuecomment-354230063
<GitHub117>
[smoltcp] whitequark commented on pull request #110 728415e: Look at how libstd implements this. We need more or less the same thing, but simpler (it only has to handle milliseconds, and it doesn't have to hide its internals quite as ardently). https://github.com/m-labs/smoltcp/pull/110#discussion_r158898188
<GitHub58>
[smoltcp] whitequark commented on issue #109: Google "TCP checksum offload". Basically, the OS puts zero in the checksum field, and since tcpdump is receiving packets from the OS, it also gets packets with such timestamps. But the NIC, before transmitting the packet, calculates the actual timestamp and substitutes it just in time. https://github.com/m-labs/smoltcp/issues/109#issuecomment-354230256
<bb-m-labs>
build #1877 of artiq is complete: Exception [exception interrupted conda_remove] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1877 blamelist: whitequark <whitequark@whitequark.org>
<sb0>
whitequark, can you go over the si5324 code and check that it does enable both outputs?
<sb0>
at least we have a si5324 and not some other incompatible beast that greg or joe found, but the clock output connection to the fpga of course had to be made incompatible
<bb-m-labs>
build #1007 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1007 blamelist: whitequark <whitequark@whitequark.org>, Robert Jordens <rj@m-labs.hk>, Sebastien Bourdeauducq <sb@m-labs.hk>
<bb-m-labs>
build #1887 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1887 blamelist: whitequark <whitequark@whitequark.org>, Robert Jordens <rj@m-labs.hk>, Sebastien Bourdeauducq <sb@m-labs.hk>
d_n|a has quit [Ping timeout: 240 seconds]
<cr1901_modern>
rjo: I lied, it is documented in Lattice's manuals; thanks for the hint.
<cr1901_modern>
Idk if the FOSS tools support it as-is though
luozijun has joined #m-labs
luozijun has quit [Ping timeout: 265 seconds]
<sb0>
rjo, how you much do you care about this output coloring?
<sb0>
only python 3.6 seems to have a nice way to deal with this bug
luozijun has joined #m-labs
luozijun has quit [Ping timeout: 240 seconds]
<rjo>
sb0: quite a bit. why?
<rjo>
sb0: assuming you mean the xilinx output coloring.
<GitHub43>
[smoltcp] dlrobertson commented on pull request #110 ae84b39: My goal here was to implement something similar to `Timespec` and `Duration` from libstd. This is what `Timespec` and `Duration` do, so it is what I used. We certainly could use `TimeStamp(u64)`, but it wasn't that much work to add a seconds and nanoseconds member and most other implementations I found use something like this instead of `TimeStamp(u64)`
<rjo>
"WARNING: [Synth 8-6040] Register �_r driving address of a ROM cannot be packed in BRAM/URAM because of presence of initial value." including the messed up name...