09:13 <mtrbot-ml> [mattermost] <hartytp> @sb10q I thought it was too good to be true that Sayma booted fine on the first try. Any idea why the RTM panics?

09:23 <mtrbot-ml> [mattermost] <hartytp> are there any non-obvious things i need to do to get Sayma to boot (dip switches, jumpers, etc)?

09:44 <mtrbot-ml> [mattermost] <pkulik> dip switch above fpga - 2nd and 3rd switch to on

09:45 <mtrbot-ml> [mattermost] <pkulik> jtag programmer may stop fpga from booting

09:54 <mtrbot-ml> [mattermost] <hartytp> @pkulik thanks. I'll add a note on the wiki. but, 1001 is how it shipped to me so looks fine

09:55 <mtrbot-ml> [mattermost] <pkulik> in what way does it not boot?

10:23 <mtrbot-ml> [mattermost] <hartytp> @pkulik https://github.com/m-labs/artiq/issues/1457

10:23 <mtrbot-ml> [mattermost] <hartytp> RTM Si5324 does not ACK

10:33 <mtrbot-ml> [mattermost] <pkulik> hmm, I've seen this problem but I didn't have time to investigate

10:52 <mtrbot-ml> [mattermost] <sb10q> No I don't know. There was a similar issue on metlino but this was because of the MMC, which can't be a problem here, correct?

10:52 <mtrbot-ml> [mattermost] <sb10q> I have not seen it on my boards

11:08 <mtrbot-ml> [mattermost] <hartytp> @pkulik okay, good to know it's not just me. Probably coincidence but this is (superficially at least) identical to the issue I had on Kasli v2.0

11:09 <mtrbot-ml> [mattermost] <hartytp> This is currently blocking me from doing any more work on Sayma, so do let me know if you can think of anything i can do

11:19 <mtrbot-ml> [mattermost] <pkulik> @hartytp one thing you could try is to unplug and replug rtm to amc

11:19 <mtrbot-ml> [mattermost] <pkulik> (when powered off of course)

11:19 <mtrbot-ml> [mattermost] <hartytp> ok

11:19 <mtrbot-ml> [mattermost] <hartytp> why would that help???

11:20 <mtrbot-ml> [mattermost] <pkulik> I don't have any theory behind this

11:21 <mtrbot-ml> [mattermost] <hartytp> done, but no change

11:21 <mtrbot-ml> [mattermost] <hartytp> :(

11:22 <mtrbot-ml> [mattermost] <hartytp> I don't know if it's just working outside my normal lab, but things have been a pain recently. Even to the point where Kasli v1.1 wouldn't give me a link on ethernet at all. Eventually @dpn suggested plugging ethernet directly into my laptop rather than going through an ethernet switch, which fixed the problem which fixed things (@sb10q any idea why that is?). Just lots of small unexpected issues which are eatin

11:23 <mtrbot-ml> [mattermost] <sb10q> 100Mbit/s switch?

11:24 <mtrbot-ml> [mattermost] <hartytp> DES-108

11:24 <mtrbot-ml> [mattermost] <hartytp> aah, is Kasli GB only?

11:25 <mtrbot-ml> [mattermost] <sb10q> The DES-108 8-Port Fast Ethernet Unmanaged Desktop Switch is a 8-port 10/100 Mbps

11:25 <mtrbot-ml> [mattermost] <sb10q> so yes that's not going to work

11:25 <mtrbot-ml> [mattermost] <sb10q> most things SFP/RJ45 are 1Gbps only

11:26 <mtrbot-ml> [mattermost] <hartytp> right, that explains things. I'd forgotten to check.

11:27 <rjo> SFP/RJ45 is definitely not "1 Gbps only". On the contrary: many GBICs are 10/100/1000 autonegotiating which is incompatible.

11:28 <rjo> Kasli/Sayma is 1000Base only

11:28 <mtrbot-ml> [mattermost] <hartytp> I did know that somewhere in the back of my mind, but it didn't occur to me as a potential source of this issue.

11:30 <mtrbot-ml> [mattermost] <sb10q> I haven't seen many that support the lower data rates

11:30 <mtrbot-ml> [mattermost] <sb10q> there are some, yes

11:31 <rjo> They are very common. And people hit that issue. Joe, did for example.

11:32 <mtrbot-ml> [mattermost] <pkulik> me too, when I started with artiq on kasli

11:32 <mtrbot-ml> [mattermost] <hartytp> Well, common or not, it's definitely something we've hit more than once and has wasted a non-negligible amount of staff time here

11:32 <mtrbot-ml> [mattermost] <hartytp> is it documented clearly somewhere? If not, I'll open and issue and submit a doc PR when I have time

11:34 <mtrbot-ml> [mattermost] <sb10q> what's the protocol on the FPGA side?

11:35 <mtrbot-ml> [mattermost] <sb10q> and yes it's in the manual, quoting: "For Kasli, insert a SFP/RJ45 transceiver (normally included with purchases from M-Labs and QUARTIQ) into the SFP0 port and connect it to a gigabit Ethernet port in your network. It is necessary that the port be gigabit - 10/100 ports cannot be used. If you need to interface Kasli with 10/100 network equipment, connect them through a gigabit switch."

11:38 <mtrbot-ml> [mattermost] <hartytp> Okay, thanks for pointing that out. I wonder if there is a way we can emphasise it a bit, since it is easily missed...

11:40 <mtrbot-ml> [mattermost] <hartytp> anyway, back to Sayma, @pkulik I'm not sure what else I can do to debug this right now so I'll wait to hear suggestions from you. Happy to try with different binaries/hardware if you send them to me

11:45 <mtrbot-ml> [mattermost] <pkulik> @hartytp you could try different combinations of amc+rtm, but at this point it's just guessing from my side

11:54 <mtrbot-ml> [mattermost] <hartytp> okay, I'll try that next time I can get a care package out of the lab. But, it does sound like there is an issue somewhere that needs to be addressed before Sayma is ready for deployment

11:56 <mtrbot-ml> [mattermost] <hartytp> I'll let you know how that works out. Otherwise, shall I send the pair I have to you for debugging?

11:59 <mtrbot-ml> [mattermost] <pkulik> no

12:00 <mtrbot-ml> [mattermost] <pkulik> in my experience it's not a permanent issue and usually power cycles helped

12:01 <mtrbot-ml> [mattermost] <pkulik> so it's most probable that I won't see this issue once you send us the hardware

13:07 <mtrbot-ml> [mattermost] <dpn> @sb10q: Silly question, but as I still don't find Nix best practices exactly intuitive, could you point me in the right direction regarding depending on your nix-scripts from a separate repository? I want to add some client-only derivations for macOS, plus some Oxford-internal dependencies, but use your derivations for all the various toolchain dependencies. One option would just be to pull in m-labs/nix-scripts as

13:15 <mtrbot-ml> [mattermost] <sb10q> You can import the artiq-fast and artiq-full channels

13:17 <mtrbot-ml> [mattermost] <sb10q> E.g. assume that the user already set those up and do import <artiq-fast> { inherit pkgs; }

13:39 <mtrbot-ml> [mattermost] <sb10q> Okay it seems the protocol is sgmii on those sfp that have 10/100

13:40 <mtrbot-ml> [mattermost] <sb10q> And it's basically a few extra auto negotiation features + repeat the bits when on 10 or 100 after auto negotiation

13:41 <mtrbot-ml> [mattermost] <sb10q> So there's no xilinx transceiver involvement, shouldn't be a big deal to implement

18:29 <mtrbot-ml> [mattermost] <dpn> Ah, right, `{ inherit pkgs; }` – I'll give it a try, thanks

18:32 <mtrbot-ml> [mattermost] <dpn> And +1 for 10/100 support being a very useful addition – one of the great things about 1000BASE-T from a user's perspective was that autonegotiation became mandatory, so things not "just working" almost feels like a violation of some implicit contract

20:33 <rjo> I don't think that implies that 10/100 need to be supported. Autonegotiation can also just fail.