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
ylamarre has quit [Quit: ylamarre]
fengling__ has quit [Ping timeout: 256 seconds]
<mithro>
so, if your system has a whole bunch of uarts interfaces, what do you think the best way to make it so stuff running on the lm32 is accessible via any of them?
fengling__ has joined #m-labs
<whitequark>
mithro: what's the larger problem you're solving?
<mithro>
whitequark: I have multiple uarts connected to the FPGA, I want a user to connect to any of them and get the command line interface
<whitequark>
what are the UARTs otherwise used for? are these full UARTs or just RX/TX?
<mithro>
USB Serial adapters connected to FPGA pins
<whitequark>
mithro: do those have RTS/CTS/etc connected? if yes I'd just use those
<whitequark>
to avoid fiddling with in-band escapes
<mithro>
whitequark: no, just RX/TX I believe
<whitequark>
you could maybe use the Break signal
<mithro>
whitequark: I'm happy for each of the UARTs to interfere with each other if people try to use them at the same time
<whitequark>
ah no, I'm worrying about regular communications accidentally triggering that mode
<mithro>
what do you mean?
<whitequark>
oh wait, I might have misunderstood the problem
<whitequark>
would there be any other communication except lm32's console going on through those UARTs?
<mithro>
whitequark: well, the serialboot - but that is lm32 console too, right?
<whitequark>
I guess
<whitequark>
if there's nothing else going on on those, can't you just connect all tx and rx pins internally? seems simplest to me
evilspirit has joined #m-labs
<sb0>
rjo, yes, the fmc card breaks the jtag chain. to maximize time wastage on stupid issues, there is enough capacitance for some jtag comms to work (highly unreliably)
<sb0>
rjo, the kc705 in the assembly room is patched to never let jtag through fmc
<sb0>
whitequark, if large-rpc is difficult (i also had this impression about C) then i suppose the core device storage buffers could be part of the kernel, loaded in multiple packets
<sb0>
whitequark, there's also the picoro hack for coroutines in C
<whitequark>
sb0: that hack relies on static ints, so it will not work for the send/receive_rpc functions
<whitequark>
I will later revisit this and figure out some suitable solution
<whitequark>
there are a few I have in mind
<whitequark>
I think the second easiest way to solve that is to call into the TCP stack on buffer over/underflow condition, even from inside the depth of a receive_rpc
<whitequark>
but that requires nontrivial (though comparatively mild) refactoring of session.c and extensive testing, so I opted for enlarging the buffers for now.
ylamarre has joined #m-labs
<GitHub64>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vu1TB
<GitHub64>
artiq/master 1543141 Sebastien Bourdeauducq: update copyright year
rohitksingh has joined #m-labs
<GitHub60>
[artiq] sbourdeauducq pushed 1 new commit to applets: http://git.io/vu1nT
<GitHub60>
artiq/applets 597c2e4 Sebastien Bourdeauducq: gui/applets: startup and embedding working
<GitHub97>
buildbot-config/master 42bf86c whitequark: Only trigger builds for master branch on GitHub.
<mithro>
So, I don't understand what .re stands for in the CSRStorage class?
<mithro>
read enable? But it seems to be triggered when a write occurs?
<mithro>
Is it to prevent reads while updating the register or something?
ylamarre has quit [Remote host closed the connection]
ylamarre has joined #m-labs
<sb0>
mithro, it means you should read the CSR
<mithro>
sb0: so it means someone has written into the CSR and we should read it and update our state?
<sb0>
yes
ysionneau has quit [Ping timeout: 256 seconds]
ysionneau has joined #m-labs
ylamarre has quit [Ping timeout: 260 seconds]
<sb0>
whitequark, i don't see what the problem is with picoro
<whitequark>
sb0: oh, that's a different thing than what I thought of
<whitequark>
but it has a different set of problems
<whitequark>
specifically, we will need to allocate multiple stacks to use it
<whitequark>
which I guess we can do.
<whitequark>
hm, there are some annoying edgecases with coredevice storage.
<whitequark>
sb0: do I remember correctly that you wanted retrieval from coredevice storage to be zero-copy?
<sb0>
whitequark, that would be nice
<sb0>
but not absolutely necessary
<whitequark>
I tried to repurpose send/receive_rpc but now that I look closer at them, it wasn't a good idea after all.
<whitequark>
what value types was it again? ints and lists of ints?
<whitequark>
why don't we have an issue anyway...
<sb0>
lists of ints
<whitequark>
nested lists too, right?
<sb0>
no
<whitequark>
oh
<whitequark>
well, this makes my life much simpler then.
<whitequark>
also, you can get the interface you wanted, since it is not polymorphic anymore
<whitequark>
meanwhile would you reflash gateware on lab kc705?
<sb0>
rjo, there's still issue with the flash proxy bitstreams
<sb0>
$ artiq_flash
<sb0>
proxy bitstream bscan_spi_xc7k325t.bit not found
<sb0>
after i installed from conda
<whitequark>
sb0: what was the API you wanted?
<sb0>
rjo, ah no it works, but it was looking for qc2
<whitequark>
self.coredevice.get_dataset(...) ?
<whitequark>
er
<whitequark>
get_storage?
<whitequark>
I don't remember
<sb0>
self.core.set/get_something, yes
<whitequark>
set_storage is OK?
<sb0>
not sure what 'something' should be
<whitequark>
set_cache maybe
<whitequark>
since that's kinda what it is
<sb0>
datacache?
<whitequark>
what other kind of cache is there?
<sb0>
whitequark, flashed
<sb0>
whitequark, is openocd not working for you?
<whitequark>
sb0: I just didn't want to figure it out right now. I'd rather implement this storage...
<whitequark>
and it was necessary to reflash because otherwise I would load an incompatible runtime in a few moments.
<sb0>
god is qt/x11 a pile of junk
<whitequark>
what now?
<sb0>
closing an embedded window does not deliver a close event to the embedded application
<sb0>
EVERYTHING is broken
<whitequark>
calling QWindow.close?
<sb0>
yes
<whitequark>
hm, wait
<whitequark>
lists of integers. int32 or int64?
<sb0>
32 I think
<whitequark>
ok
<sb0>
well i'll just use subprocess.kill(), fuck it
<sb0>
whitequark, i think we should revisit pipes. i still dislike TCP for parent/child process communication, and then we can just keep a pipe open and close it to signal child termination request
<sb0>
since obviously we can count on nothing from the steaming pile of shit that passes as windowing system on modern computers
<whitequark>
hm, not sure
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
fengling__ is now known as fengling
fengling has quit [Quit: WeeChat 1.2]
<sb0>
another thing that is ridiculously broken with qt5: hi-dpi. doesn't increase the font size, simply adds a lot of blank space to your UI
<mithro>
We have a fx2 firmware embedded in an lm32 firmware embedded in our gateware... Layers! :-)
<GitHub99>
[artiq] sbourdeauducq pushed 1 new commit to applets: http://git.io/vuDIg
<GitHub99>
artiq/applets 1ea73be Sebastien Bourdeauducq: gui/applets: all basic functionality, no state save/restore
<mithro>
Next task is to move the lm32 and fx2 firmware onto the SPI flash
sb0 has quit [Quit: Leaving]
<mithro>
when programming fpga gateware to spiflash should I be using the .bit or the .bin file?
<mithro>
seems like the .bin file....
FabM has quit [Ping timeout: 256 seconds]
FabM has joined #m-labs
ylamarre has joined #m-labs
rohitksingh has quit [Ping timeout: 240 seconds]
ylamarre has quit [Quit: ylamarre]
rohitksingh has joined #m-labs
bb-m-labs has quit [Ping timeout: 255 seconds]
bb-m-labs has joined #m-labs
ylamarre has joined #m-labs
ylamarre has quit [Ping timeout: 240 seconds]
evilspirit has quit [Ping timeout: 264 seconds]
bentley` has quit [Ping timeout: 276 seconds]
<acathla>
Hum, I see cores/mxcrg.v in misoc sources. Why is it there? Is it necessary?