kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined #m-labs
<sb0>
whitequark, I'm generally not flashing anything, just load to SRAM + flterm
<sb0>
you can use port identifiers, e.g. /dev/serial/by-path/pci-0000:00:14.0-usb-0:8.4:1.0-port0 for the aux kc705
<whitequark>
sb0: the problem was with openocd
<whitequark>
not serial
<sb0>
<whitequark> oh, it's now at /dev/ttyUSB7... << I was referring to this
<whitequark>
right, it wasn't
<whitequark>
but sure
<sb0>
for openocd, use the ftdi serial numbers
<whitequark>
should be udev rules anyway
<whitequark>
yes, I already figured it otu.
mumptai has joined #m-labs
<cr1901_modern>
sb0: Been forgetting to ask this, but in MiSoC, 1xs SPI flash reads are only supported through bit-banging, correct?
<sb0>
1xs?
<sb0>
there is the spi core, the spiflash core, and bitbanging. choose one.
<cr1901_modern>
sb0: I meant SPU flash that "receives read data on miso" instead of using multiple pins
<cr1901_modern>
SPI*
<cr1901_modern>
if spi_width == 1, data will be sent back on mosi b/c of how the receive logic is implemented
<sb0>
bidirectional spi data? i don't think we have any implementation of that
<cr1901_modern>
I'm explaining this poorly... the SPI core supports three different type of read commands: _QIOFR, _DIOFR, and _FAST_READ. Both the Quad and Dual read send commands over mosi and receive on dq0, dq1, and possibly dq2 and dq3 >>
<cr1901_modern>
dq0 == mosi, dq1 == miso
kuldeep has quit [Ping timeout: 268 seconds]
<cr1901_modern>
If spi_width == 1, data is received over dq0 (mosi)... it should be received over dq1
* cr1901_modern
can't test this right now, but patch soon
<cr1901_modern>
And if I'm wrong, well you can yell at me later :P
hedgeberg is now known as hedgeberg|away
kuldeep has joined #m-labs
mumptai has quit [Remote host closed the connection]
<sb0>
whitequark, I have a slice that I put into a Cursor to write a packet into it. then I want the slice memory again to compute a CRC. I cannot do that easily because the slice has been moved into the Cursor. how do you propose resolving that?
<whitequark>
cursor.into_inner()
<whitequark>
or .get_ref()/.get_mut() if you don't want to lose position
<sb0>
yes, I need to write the CRC afterwards
<sb0>
thanks
<sb0>
whitequark, using kc705s
<sb0>
whitequark, why do you run flterms on ttyUSB0?
Gurty has quit [Remote host closed the connection]
Gurty has joined #m-labs
Gurty has joined #m-labs
Gurty has quit [Changing host]
<sb0>
rjo, so for DRTIO inputs, I'm currently playing with the idea of having a "poll request" still active until a timeout (referenced to the TSC) occurs or an event is in the FIFO
<sb0>
this way, the latency when waiting for an event is both reduced (1-way through the DRTIO stack) and more deterministic (no jitter +/- one poll cycle if the polling is started sufficiently in advance)
<rjo>
sb0: like a one-event prefetch?
<rjo>
sb0: what if the kernel decides not to retrieve that prefetched event and instead poll a different (input) channel?
<sb0>
no prefetch. what I mean is: if the FIFO is empty, the "FIFO empty" response is delayed until a certain TSC value (that can be chosen equal to e.g. a TTL input gate closing)
<sb0>
if the FIFO receives an event during that time, it is returned
<sb0>
immediately
<rjo>
ok. would that timeout be supplied in the poll request?
<sb0>
yes
<rjo>
how would the kernel cpu abort such a request before the timeout?
<sb0>
in what case does it need to do that?
<rjo>
kernel cpu being reset/kernel evicted.
<sb0>
it would probably be acceptable to lose input events in this case
<sb0>
the new kernel doesn't expect them
<rjo>
it may be just fine to discard that
<rjo>
or some exception?
<sb0>
typically new kernels do a RTIO reset
<sb0>
I think the corner case of kernel abort + loading of a new kernel while some events are in the FIFO isn't handled well by the current system either, unless the new kernel does a RTIO reset
<sb0>
*some input events
<sb0>
a DRTIO reset would also flush the input FIFO
<rjo>
one thing i have come to notic is that in general the master DRTIO opens up exactly one channel to the the satellite DRTIO.
<rjo>
then actually the gateware could just make sure that events get transferred. for output once the master has them. for inpput once the slave has them.
<rjo>
(the latter up to a deadline/timeout)
<rjo>
then once the master decides to close the channel/change to a different DRTIO endpoint, stuff just gets dropped at the switches.
<rjo>
this notion of a p2p pipe between the drtio master and the remote drtio channel seems to mesh well with your notion of poll requests. they would establish and sustain the pipe.
kilae has joined #m-labs
mumptai has joined #m-labs
hedgeberg|away is now known as hedgeberg
rohitksingh has quit [Quit: Leaving.]
kilae has quit [Quit: ChatZilla 0.9.93 [Firefox 51.0.1/20170125094131]]
<cr1901_modern>
_florent_: Thanks. Part of my motivation was Litex has a working SPIflash 1x and I'd like misoc to have feature parity w/ Litex (and vice-versa)
<cr1901_modern>
That being said, your recent incorporation of misoc changes rendered most of my pull reqs redundant