00:46 <cr1901_modern> rjo: Ping when you're around.

02:05 <GitHub60> [artiq] sbourdeauducq commented on issue #633: Stupid question, does right click -> global/group CCB policy -> Create and enable applets fix the problem? https://git.io/v1sV5

02:06 <GitHub90> [artiq] sbourdeauducq commented on issue #633: > it should disable it and the applet should disappear, right?... https://git.io/v1sVN

02:12 <GitHub119> [artiq] sbourdeauducq commented on issue #623: > Why does the timing fail in 3.0 exactly?... https://git.io/v1sw4

03:17 <GitHub138> [artiq] r-srinivas commented on issue #633: >Stupid question, does right click -> global/group CCB policy -> Create and enable applets fix the problem?... https://git.io/v1s6d

03:21 <GitHub120> [artiq] sbourdeauducq commented on issue #633: That's how it's intended to work. "Create" could be changed to a term that means "mess with the user's windows", if we can find a good one.... https://git.io/v1sit

03:21 <GitHub183> [artiq] sbourdeauducq closed issue #633: disable_applet not working https://git.io/v1Y6I

03:22 <GitHub124> [artiq] sbourdeauducq commented on issue #633: That's how it's intended to work. "Enable" could be changed to a term that means "mess with the user's windows", if we can find a good one.... https://git.io/v1sit

03:47 <GitHub114> [artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/v1sXq

03:47 <GitHub114> artiq/master 696db32 Sébastien Bourdeauducq: dashboard: mention disable in CCB policies

03:56 <GitHub29> [artiq] r-srinivas commented on issue #633: Okay, thanks. Maybe modify? User customisable? https://git.io/v1sX1

03:59 <GitHub56> [artiq] r-srinivas opened issue #635: Deselect group in applet dock https://git.io/v1sXh

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

04:10 <GitHub4> [artiq] sbourdeauducq commented on issue #635: You can drag the applet out of the group to the top-level. https://git.io/v1s1X

04:24 <bb-m-labs> build #1136 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1136 blamelist: S?bastien Bourdeauducq <sb@m-labs.hk>

04:25 <cr1901_modern> I love how buildbot can't get the accented "e" correct

04:25 <GitHub188> [artiq] sbourdeauducq commented on issue #635: And as often, better behavior cannot be obtained without wrangling with Qt:... https://git.io/v1sMz

04:28 <GitHub139> [artiq] r-srinivas closed issue #635: Deselect group in applet dock https://git.io/v1sXh

04:28 <GitHub124> [artiq] r-srinivas commented on issue #635: Okay. If we can just drag it out that's easy enough. https://git.io/v1sMS

04:36 <GitHub164> [artiq] sbourdeauducq commented on issue #635: Let's keep this issue open - small UI improvements like this, even though they are a PITA to program, can save some frustration to the user. https://git.io/v1sDm

04:36 <GitHub17> [artiq] sbourdeauducq reopened issue #635: Deselect group in applet dock https://git.io/v1sXh

04:44 <GitHub126> [artiq] sbourdeauducq commented on issue #633: It is user customizable already: ARTIQ is open source, you can patch your local installation :)... https://git.io/v1sDK

06:12 <GitHub114> [artiq] r-srinivas commented on issue #633: I should clarify that I meant user customisable as a name, as in the user can customise how the applets appear. Enable/disable seems fine, though slightly confusing with also being able to enable/disable applets, but is to enable/disable ccb? Maybe something along the lines of experiment controlled as more descriptive? https://git.io/v1sHl

06:16 <GitHub79> [artiq] r-srinivas commented on issue #633: I should clarify that I meant user customisable as a name, as in the user can customise how the applets appear. Enable/disable seems fine, though slightly confusing with also being able to enable/disable applets, but is to enable/disable ccb? Maybe something along the lines of experiment controlled as more descriptive?... https://git.io/v1sHl

07:42 <GitHub119> [artiq] sbourdeauducq pushed 1 new commit to drtio: https://git.io/v1sFo

07:42 <GitHub119> artiq/drtio a318243 Sebastien Bourdeauducq: rtio: CRI arbiter (untested)

08:31 <GitHub18> [artiq] sbourdeauducq pushed 4 new commits to drtio: https://git.io/v1sAV

08:31 <GitHub18> artiq/drtio 7c59688 Sebastien Bourdeauducq: rtio: simple DMA fixes

08:31 <GitHub18> artiq/drtio 46dbc44 Sebastien Bourdeauducq: rtio: export DMA and CRIInterconnectShared

08:31 <GitHub18> artiq/drtio 6c97a97 Sebastien Bourdeauducq: rtio: support single-master CRI arbiter

08:44 <GitHub124> artiq/drtio 3931d80 Sebastien Bourdeauducq: rtio: fix DMA TimeOffset stream.connect

08:44 <GitHub124> [artiq] sbourdeauducq pushed 1 new commit to drtio: https://git.io/v1sxR

11:14 <sb0> rjo, what do I need to do to get 150MHz out of the FMC card?

11:40 <key2> yo

11:47 <sb0> hi key2

11:48 <key2> sb0: I am currently porting the SPI core to nuttx

11:48 <key2> sb0: the thing is that the current spi core maps the QSPI to the wishbone bus

11:48 <key2> sb0: would it be ok to use the more efficient SPI core and implement the rest in the bios ?

11:49 <sb0> what is the more efficient SPI core?

11:50 <key2> well this one is wired to the QSPI pads

11:50 <key2> https://github.com/m-labs/misoc/blob/master/misoc/cores/spi_flash.py

11:50 <key2> what I want is nuttx to access the n25q128

11:50 <sb0> ah, yes, it is designed to map the SPI flash into the CPU address space, so it can be directly executed

11:50 <key2> for that, it has to see it a a SPI

11:50 <key2> yep

11:50 <key2> so the equestion was

11:50 <key2> can we do that in bios

11:50 <sb0> do what?

11:51 <sb0> the BIOS is inside the SPI flash, if it is not mapped as this core does, it cannot be executed

11:51 <key2> copying from n25qxxx to memmory location

11:51 <sb0> what memory? when the BIOS starts running there is no SDRAM

11:51 <key2> no but the bios is "part" of the core

11:52 <key2> once it start

11:52 <key2> it has to decide either serial boot, netboot, qspi

11:52 <key2> the first reading stage is done by the FPGA logic itself depending on the configuration mode

11:52 <key2> if the mode is to read config from qspi flash, it will frist configure itself from the qspi and not jtag

11:52 <key2> at this stage

11:53 <key2> the lm32 will execute the code that is inside the fpga

11:53 <key2> which is the bios

11:53 <key2> at this stage the qspi was used just to configure the fpga

11:53 <key2> so our logic doesn matter

11:54 <key2> but now, we are in the bios, we want to load from the qspi flash the OS (nuttx for example) and put it at 0x40000000

11:54 <key2> either the current core is used, whch maps directly the qspi flash to the wishbone

11:54 <key2> or, the other option would be to have a qspi core, and use it to copy the data at 0x400000000

11:55 <key2> by accessing the registers and doing the logic in software

11:55 <sb0> why?

11:55 <key2> because most OS do have a n25qxxxx driver over SPI

11:55 <key2> and qemu as well

11:56 <key2> that means, just by porting the QSPI core to qemu, we coudl manage any flash

11:58 <key2> isnt this SPI core more efficient than the one that is in spi_flash ? https://github.com/m-labs/misoc/blob/master/misoc/cores/spi.py

12:03 <key2> btw, is there the logic for writing to the SPI flash in spi_flash.py ?

12:05 <sb0> no, we use bit-banging for that

12:05 <sb0> which is fine, since the writing time is dominated by erasure anyway

12:06 <sb0> so I don't quite see what you are trying to achieve

12:08 <key2> so basically for reading it is mem mapped, for writing we bitbang

12:09 <key2> but that makes it difficult for current OS/Emulator to see it as something standard

12:10 <key2> I was thinking of using the qemu and nuttx drivers that know how to handle a n25qxxxx by showing them the flash on a SPI bus

12:14 <key2> sb0: if you look here for example https://github.com/qemu/qemu/blob/507e4ddc3abf67391bcbc9624fd60b969c159b78/hw/microblaze/petalogix_ml605_mmu.c#L181-L207

12:14 <key2> they add a SPI bus, and they add the n25q128 on it

12:48 <GitHub199> [artiq] whitequark commented on issue #631: @sbourdeauducq This is not a runtime bug but rather another lwip bug:... https://git.io/v1GgV

14:02 <whitequark> sb0: do you know what's the highest bitrate we can run the UART on?

14:02 <whitequark> enabling even modest lwip debug options make the stack unusable because it blocks on UART

16:27 <GitHub74> [artiq] sbourdeauducq commented on issue #631: Either way this needs fixing, as it makes ARTIQ unusable. https://git.io/v1ZUG

16:35 <sb0> maybe 1Mbps or so? try it...

16:40 <rjo> sb0: see README_PHASER.rst

16:43 <rjo> cr1901_modern: i'll be barely online until sunday. but if it's about SPI, I am sure you can teach yourself.

16:46 <sb0> rjo, I mean internally

16:46 <sb0> and yes, I can RTFS, sure ...

16:46 <rjo> sb0: internally of what?

16:47 <sb0> I suppose the clock chip on the FMC card needs to be programmed

16:47 <sb0> how?

16:47 <rjo> sb0: artiq/examples/phaser/startup_kernel.py

16:48 <sb0> so this runs before the RTIO clock is up?

16:49 <rjo> yes.

16:49 <sb0> hm

16:49 <sb0> that's not DRTIO friendly

16:49 <sb0> we need the RTIO clock to drive the transceivers

16:52 <rjo> sb0: the problem is generic. you have solved it for the si5324 already.

17:03 <sb0> sure, can be solved, but needs adaptation and fixing the pesky bugs that won't miss the opportunity to pop up, not just copy-paste existing tested code

17:03 <sb0> anyway

17:05 <sb0> can we clock the slave card from the recovered clock? or is that unadvisable due to phase noise, missing clock connection, or some other issue?

17:19 <GitHub27> [artiq] jordens opened issue #636: improved register layout and tweaked event submission code https://git.io/v1Z3N

17:22 <sb0> whitequark, there is this baud123 guy who seems to have a high opinion of lwip. you may want to bother him.

17:25 <rjo> sb0: that's unadvisable due to noise.

17:26 <whitequark> baud243?

17:26 <whitequark> *baud213?

17:26 <whitequark> er.

17:26 <whitequark> I mean where is he

17:31 <rjo> sb0: it would avoid having/being able to test the active alignment logic but the dac output noise would be significantly degraded.

18:43 <cr1901_modern> rjo: Actually you were right- I did figure it out myself :P. I forgot to say "ignore ping" before I went to sleep.

21:22 <GitHub69> [artiq] r-srinivas commented on issue #407: Artiq 3.0 seemed a little slow running experiments so I had a look at this again. Performance seems to be substantially worse on windows. I'm running the following experiment,... https://git.io/v1nv6