<GitHub110>
[artiq] sbourdeauducq commented on issue #854: That board I sent was for the 1.8V bug. I don't know how Ethernet behaves on it with the latest MMC firmware. It may or may not exhibit the 'no link after rgmii setup' bug. https://github.com/m-labs/artiq/issues/854#issuecomment-363283389
<GitHub169>
[artiq] sbourdeauducq commented on issue #915: The ARTIQ conda package not installing correctly on Windows, either on the release-3 branch or master; both specify binutils-or1k-linux >=2.27. https://github.com/m-labs/artiq/issues/915#issuecomment-363324526
<GitHub16>
[smoltcp] canndrew opened pull request #153: Relax type constraints on payload_mut methods (master...relax-payload_mut-constraints) https://github.com/m-labs/smoltcp/pull/153
<GitHub196>
[smoltcp] m-labs-homu commented on issue #153: :pushpin: Commit abbaa37 has been approved by `whitequark`
<whitequark>
WTF, this comes with a KERNEL MODULE?
<whitequark>
are they nuts?
<rjo>
whitequark: i haven't figured out what's that for. but afaict we don't need it.
<rjo>
if you browse around at ftp://ftp.princetoninstruments.com/Public/Software/Official/PICam there is a manual as well ftp://ftp.piacton.com/Public/Manuals/Princeton%20Instruments/PICam%205.x%20Programmers%20Manual.pdf
<whitequark>
why does this garbage install its files with permissions 0700...
<rjo>
there are a bunch of things in there. let's maximize functionality and work around the dumb things (like the kernel module) if we can. i am happy to have a windows machine do the firmware upgrade if that's needed.
<whitequark>
there is a linux firmware updater on that ftp
<rjo>
whitequark: yes. but it might not be that seamless. anyway. let's work around the things you don't like pragmatically without too much complaining. ;)
<GitHub166>
[artiq] hartytp commented on issue #908: Anyway to be clear, in case I do find time to look into this, your plan is basically to dig through the git history, building various versions of Sayma gateware/firmware with SAWG (at a few hours per build) until we find the point where it stopped working? IIRC, that's a bit complicated by the fact that the tools to build Sayma have changed a bit over time, so it's not always
<GitHub180>
[artiq] hartytp commented on issue #908: Anyway to be clear, in case I do find time to look into this, your plan is basically to dig through the git history, building various versions of Sayma gateware/firmware with SAWG (at a few hours per build) until we find the point where it stopped working? IIRC, that's a bit complicated by the fact that the tools to build Sayma have changed a bit over time, so it's not always
<GitHub56>
[artiq] hartytp commented on issue #908: Well, as I said, as this seems like standard yak shaving for getting a board up and running, rather than a particular hardware/design issue with Sayma. So, do you mind taking a look at it first -- it's likely to be quicker for you since you've probably kept a closer eye on the changes that have been made to ARTIQ over the past weeks. https://github.com/m-labs/artiq/issues/9
<sb0>
there is a kernel module for talking to the camera over ethernet?
<whitequark>
sb0: yes.
<whitequark>
it includes a chunk of some RTOS.
<whitequark>
oh, no, it's worse
<sb0>
this reminds me of the xilinx trash for talking to the jtag cables a couple years ago (in a rare stroke of genius, xilinx replaced that with libusb since then)
<whitequark>
they distribute a proprietary .a and an open-source RTOS-like API that delegates to Linux
<whitequark>
clearly derived from some windows trash
<GitHub144>
[artiq] gkasprow commented on issue #854: I want to be able to observe the RGMII signals on rx and tx side. But this I do with my existing design, without MAC but for single packets. I'd like to run it with higher data rate.... https://github.com/m-labs/artiq/issues/854#issuecomment-363398120
<GitHub143>
[artiq] sbourdeauducq commented on issue #854: I did receive correct packets using my design, and I dumped them after the whole chain, the contents and CRC were correct. Maybe you did the rework a bit differently than me (did you cut the RX clock trace or just added the wire?) and your timing is different. A RX phase adjustement and/or verifying that our reworks are the same (I cut the trace, but maybe I did not do
<GitHub30>
[artiq] sbourdeauducq commented on issue #854: Also, it is impossible for a RGMII design to "simply work", other than by chance, or if they have some sort of automatic calibration which sounds impractical. The timing windows are small and this needs phase calibration for every board design.... https://github.com/m-labs/artiq/issues/854#issuecomment-363401223
<GitHub83>
[artiq] sbourdeauducq commented on issue #854: Also, it is impossible for a RGMII design to "simply work", other than by chance, or if they have some sort of automatic calibration which sounds impractical. The timing windows are small, the PHY timings and PCB layouts are varied, and this needs phase calibration for every board design.... https://github.com/m-labs/artiq/issues/854#issuecomment-363401223
<GitHub40>
[artiq] sbourdeauducq commented on issue #854: Also, it is impossible for a RGMII design to "simply work", other than by chance, or if they have some sort of automatic calibration which sounds impractical. The timing windows are small, the PHY timings and PCB layouts are varied, and this needs phase calibration for every board design. As I remember, you had to do some hacks (e.g. invert the clock on IDDR) to get your
<GitHub108>
[artiq] gkasprow commented on issue #854: @sbourdeauducq I can route the clock to same bank using some of TLCKC/TCLKD clock pairs. They won't be used in the future. The clock trace delay would be much longer, but at least it won't depend on FPGA silicon PTV variation. https://github.com/m-labs/artiq/issues/854#issuecomment-363401949
<GitHub157>
[artiq] gkasprow commented on issue #854: OK, my wire is roughly 2cm shorter. Cannot we add some auto-tuning capability? It can be done via UART-controlled fine delay that can be setup by packet loss rate. It's just a few lines of Python code. https://github.com/m-labs/artiq/issues/854#issuecomment-363403189
<GitHub92>
[artiq] sbourdeauducq commented on issue #854: Let's focus on the board issues so that they can be effectively fixed in the next PCB revision. For actual users, there is the Ethernet-FMC escape route. https://github.com/m-labs/artiq/issues/854#issuecomment-363405027
<GitHub43>
[artiq] gkasprow commented on issue #854: Did you get the FMC-Ethernet board? I think my piece can be switched to 1.8V so could verify of this works, providing that you get yours from same vendor. https://github.com/m-labs/artiq/issues/854#issuecomment-363405980
rohitksingh_work has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
attie has quit [Remote host closed the connection]
attie has joined #m-labs
kristianpaul has joined #m-labs
attie has quit [Ping timeout: 268 seconds]
attie has joined #m-labs
<GitHub73>
[smoltcp] dlrobertson commented on pull request #139 bf04ed3: Yeah, I wasn't sure if this `Repr` would be more usable if it was like the ICMP, TCP, and UDP reprs where the `data` is in the `Repr`, or like like IPv6 and IPv4 where the `data` is not in the `Repr`s. https://github.com/m-labs/smoltcp/pull/139#discussion_r166328078
rohitksingh has joined #m-labs
rohitksingh_ has joined #m-labs
rohitksingh has quit [Ping timeout: 260 seconds]
rohitksingh_ is now known as rohitksingh
rohitksingh1 has joined #m-labs
rohitksingh2 has joined #m-labs
rohitksingh1 has quit [Quit: Leaving.]
rohitksingh2 has quit [Ping timeout: 240 seconds]
rohitksingh1 has joined #m-labs
rohitksingh2 has joined #m-labs
rohitksingh2 has quit [Client Quit]
FabM has quit [Ping timeout: 256 seconds]
rohitksingh1 has quit [Quit: Leaving.]
rohitksingh1 has joined #m-labs
FabM has joined #m-labs
rohitksingh1 has quit [Quit: Leaving.]
attie has quit [Ping timeout: 268 seconds]
attie has joined #m-labs
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 248 seconds]
rohitksingh has quit [Quit: Connection closed for inactivity]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #m-labs
mumptai has joined #m-labs
<GitHub154>
[smoltcp] dlrobertson commented on issue #141: @whitequark would you like all the changes to the TCP timestamps etc to be in this PR too? If so, I'm assuming they should be in a separate commit https://github.com/m-labs/smoltcp/pull/141#issuecomment-363552444
attie has quit [Ping timeout: 260 seconds]
attie has joined #m-labs
mumptai has quit [Remote host closed the connection]