02:48 <cr1901_modern> Oh problem solved then XD

06:53 <sb0> _florent_, how is the _UpConverter supposed to behave on EOP?

07:00 <sb0> _florent_, in particular, it doesn't like eop=1 & stb=0. shouldn't stb qualify eop?

07:01 <sb0> _florent_, and you can remove the converter reset from the liteeth phy, right?

10:17 <_florent_> sb0: I look at that soon

11:06 <sb0> rjo, if we start having remote kernels, we should really look at existing distributed computing systems (erlang, mpi, etc.)

11:18 <rjo> sb0: if they need full messaging yes. but afaict the driving use case would be very encapsulated kernels that process a bunch of RTIO stuff locally and emit data upstream.

11:18 <rjo> i.e. they would be more like "soft PHYs"

11:20 <rjo> and ack. that specific feature is a bit down the road. arbitration between DMA and kernel API is not however.

11:22 <rjo> and why do you want to give up on the useful capabilities (e.g. debugging, load over serial) for the DRTIO satellites?

11:26 <sb0> if there's sdram in all the satellites then the current boot mechanism is fine

11:38 <key2> hi

11:44 <sb0> hi

11:51 <key2> sb0: do you get to program the sqpi with qemu using a first stage loader that you load with xc3sprog ?

11:59 <sb0> sqpi with qemu?

11:59 <key2> with openocd

11:59 <key2> sorry i was doublethreading

12:01 <rjo> we have rewritten the "first stage loaders" to be cleaner, and flexible.

12:02 <key2> aha

12:02 <key2> where is that ?

12:03 <rjo> openocd

12:03 <key2> trunk ?

12:03 <rjo> yes

12:05 <key2> it's directly a .bit or .v ?

12:11 <rjo> migen and .bit

12:20 <key2> yeah but where is the .py then ?

12:20 <key2> basically I want to generate the file for arty board

12:20 <key2> to not use vivado to program it

12:20 <key2> what would be the procedure ?

12:20 <rjo> see the openocd documentation.

15:06 <GitHub37> [artiq] sbourdeauducq created drtio (+89 new commits): https://git.io/vXSvT

15:06 <GitHub37> artiq/drtio 4e47dec Sebastien Bourdeauducq: drtio: add scrambler/descrambler and test

15:06 <GitHub37> artiq/drtio 8a92c2c Sebastien Bourdeauducq: drtio: add RX link layer, fixes, simple loopback demo

15:06 <GitHub37> artiq/drtio fa83ad0 Sebastien Bourdeauducq: drtio: add TX link layer

15:17 <rjo> sb0: i think we can rename artiq_drtio to artiq_private and keep it for this kind of staging

15:18 <sb0> ok, but I don't foresee any private staging for a while

15:24 <sb0> I have already deleted it anyway, but I'll create an artiq_private when we need this sort of thing again

15:50 <rjo> sb0: there are a bunch of in-flight features for sayma.

16:27 <larsc> rjo: I talked to the people who should know this on the phone and they assured me that at the jesd RX output in the DAC everything will be aligned

16:28 <larsc> but the additional pipeline that follows might have a latency difference of 1 clock cycle from DAC to DAC

16:28 <larsc> but this latency difference stays constant between power cycles

16:28 <rjo> larsc: excellent. thanks a lot!

16:29 <larsc> so if you are able to measure a 1 DAC clock cycle difference you could calibrate

16:31 <rjo> larsc: measuring that (even to the femtosecond level) is not hard. but if it's a deterministic shift it will only ever matter in IQ applications for us.

16:39 <cr1901_modern> https://github.com/m-labs/artiq/issues/616#issuecomment-260832693 Hrm, yea. Windoze is kinda broken in that respect AFAIK. It's pretty ignorant of uses of PPP except for dialup.

16:54 <rjo> but haven't windowsers been doing good old null-modem things for decades?

17:00 <cr1901_modern> rjo: Well, yes. And PPP ports show up as your typical COM port. Just that last time I tried doing PPP for fun and masochism, I was forced to go through a GUI. Meaning idk if the API is documented, or I just wasn't smart enough back then to do it.

17:01 <cr1901_modern> Going through a GUI doesn't really help b/c it wants you to connect to an ISP. And it seems kinda farfetched to emulate an ISP on Pipistrello.

23:28 <shenki> hello! i'm hacking on some software that runs on a lm32. i was wondering how interrupts are delivered to the firmware

23:28 <shenki> the bios is loaded at 0 and has an interrupt handler in the crt0.S, but the firwmare gets loaded into ram

23:29 <shenki> so how does it get irqs for eg. the uart?

23:40 <cr1901_modern> Erm, I'm pretty sure all IRQs use the same interrupt vector and there is a register you check to see which device actually caused the interrupt?

23:57 <mithro> cr1901_modern: Yes, but the interrupt vector is a specific location in the address space

23:58 <mithro> cr1901_modern: so if the BIOS puts its own interrupt handling vector there, how does the firmware loaded by the bios end up with the firmware's interrupt handling vector there?