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
mumptai has quit [Quit: Verlassend]
<cyrozap>
I'm having trouble understanding misoc/cores/spi_flash...
<cyrozap>
I'm just trying to get it to use MOSI and MISO, not DQ because my SPI flash doesn't support dual/quad-rate.
<rjo>
cyrozap: what's in a name?
<rjo>
cyrozap: those are just different names for the same signals. spi_flash works fine with single width spi.
Mon_ has joined #m-labs
Mon_ is now known as Guest12633
Guest12633 has quit [Quit: This computer has gone to sleep]
<whitequark>
sb0: hmmm no idea
<whitequark>
wow, 10^-10 vapor pressure
<whitequark>
that's amazing
Guest12633 has joined #m-labs
<cr1901_modern>
rjo: sb0 did mention that it would be nice if naming was consistent for different i/o devices on the same pins, but I guess that's fairly low on the todo list/"nice to have" feature.
<cr1901_modern>
I got thrown off by it when trying to port my board
<cyrozap>
rjo: Not in my experience, it complains that there's no DQ pins defined.
<cyrozap>
rjo: As in, doing spi_flash.SpiFlash(platform.request("spiflash")) doesn't work.
<rjo>
cyrozap: well. the platform's naming has to match the core's naming.
<cyrozap>
rjo: Right, but spi_flash gets the bus width from the width of dq, but the flash I'm using does not support 2x.
<rjo>
cr1901_modern: sure. but in this case the name can depend on how you talk to it.
<rjo>
cyrozap: spi_flash works if dq is a single bit wide.
<rjo>
the only thing it does not (directly) support is the case where there are two lines and miso is 1-bit wide.
<rjo>
which is "real" "standard" spi in some sense.
<cyrozap>
rjo: Ah, that's where the issue is, MOSI and MISO are seperate on this board.
<rjo>
cr1901_modern: you can do this by having overlapping platform records that expose the same signals under different names. IIRC I did that for one of the platforms I wrote. it is a bit dirty because you get the error very late if you mess up.
<rjo>
in this case it is actually beneficial that spi_flash expects "dq" while the other "generic" spi core has "miso/mosi".
<rjo>
cyrozap: you should be able to adapt spi_flash. but it will get even uglier than it is now...
Guest12633 has quit [Quit: This computer has gone to sleep]
Mon_ has joined #m-labs
Mon_ is now known as Guest8378
Guest8378 has quit [Quit: This computer has gone to sleep]
Mon_1 has joined #m-labs
Mon_1 has quit [Client Quit]
Mon_1 has joined #m-labs
Mon_1 has quit [Quit: This computer has gone to sleep]
Mon_ has joined #m-labs
Mon_ has quit [Client Quit]
<whitequark>
sb0: why did you put the runtime under artiq/runtime?..
<whitequark>
also haha wow I just hit the submodule bug
Mon_ has joined #m-labs
Mon_ is now known as Guest81408
Guest81408 has quit [Client Quit]
<whitequark>
sb0: also why did you take absolute paths in the runtime makefile and replaced them with relative?
Mon_1 has joined #m-labs
Mon_1 has quit [Client Quit]
Mon_1 has joined #m-labs
Mon_1 has quit [Quit: This computer has gone to sleep]
<whitequark>
sb0: File "pygit2/libgit2_build.py", line 71, in <module>
<whitequark>
ImportError: No module named 'cffi'
<whitequark>
how do I fix this on Debian?
<whitequark>
hm, pygit seems to just miss the cffi dependency for some reason
Mon_1 has joined #m-labs
<whitequark>
and pycparser too... wtf
<GitHub107>
[misoc] whitequark pushed 1 new commit to master: http://git.io/v8nro
<sb0>
yes. it has a python3.5 package, but the python3 executable points to 3.4.
<sb0>
at least it does so on my machine
<whitequark>
yes, python3 points to python3.5
<sb0>
no, 3.4.3 here
<sb0>
even though I did install that python3.5 package
<sb0>
and if I try to remove the 3.4 package, it uninstalls half of my system ...
<whitequark>
yes, you cannot remove 3.4
<whitequark>
loooots of things in ubuntu depend on it (you can tell because they hog all the memory)
<sb0>
whitequark, we should use a consistent python interpreter, either python3 or python3.5, but not python3.5 in artiq_flash.sh and python3 everywhere else
<sb0>
because the current directory is the build directory, which is what you want
<whitequark>
yes, I've figured that out
<sb0>
those type hints could still be useful to annotate the return values of RPCs, maybe
<GitHub159>
[artiq] whitequark pushed 1 new commit to master: http://git.io/v8cka
<GitHub159>
artiq/master 51f04f6 whitequark: Explicitly use the python3.5 binary everywhere.
rohitksingh has quit [Ping timeout: 240 seconds]
<whitequark>
sb0: xc3sprog fails on my machine
<whitequark>
what do I use to properly program pipistrello, again?
<sb0>
fpgaprog is shitty but reliable
<sb0>
openocd should be better, but I could not get it to work
<whitequark>
*sigh*
<whitequark>
I can't program runtime.fbi using fpgaprog, right?
<whitequark>
so there are three options and none of them work.
<whitequark>
> During the Xilinx toolchain installation, uncheck Install cable drivers (they are not required as we use better and open source alternatives).
<whitequark>
> better
<sb0>
yes, maybe "less bad" would be a more appropriate word.
<sb0>
anyway. you can program runtime.fbi I think, in the worst case by using dd
<sb0>
to concatenate it after the BIOS with appropriate padding
<whitequark>
ok
<whitequark>
do you remember the addresses?
<sb0>
but you may have better luck than I did with openocd
<sb0>
they're in artiq_flash.sh
<sb0>
and yes, those FPGA programming tools piss me off, which is why I tend to focus on kc705
<whitequark>
have a spare kc705 yet? :]
<sb0>
we can probably get two, otherwise sharing one in HK should be possible I think...
<whitequark>
I'd actually prefer if it was just plugged into Ethernet somewhere in the lab or wherever
<whitequark>
it's not like I ever need physical access, do I?
travis-ci has joined #m-labs
<travis-ci>
m-labs/artiq#575 (master - 0b5e1d1 : whitequark): The build passed.