<ysionneau>
we should switch ARTIQ from python to Java I guess :)
<larsc>
native java support in the lm32
<ysionneau>
let's add Jizelle stuff
<sb0>
it's an internet-of-things realtime middleware for collecting big data
<sb0>
isn't jazelle undocumented?
<ysionneau>
dunno, I never understood exactly what hw there was behind this marketing name
<ysionneau>
maybe some extra registers to hold some JVM information
<sb0>
nah, I'd guess it's more elaborate than that
<ysionneau>
ah yes it seems to lead to "direct bytecode execution"
* sb0
is pondering whether to submit an abstract to icalepcs2015
* sb0
doesn't like expensive conferences and long flights very much
<larsc>
sb0: does the mixxeo_soc repository still work?
<sb0>
afaik yes
<larsc>
how do I invoke it?
<larsc>
maybe it's easier to just copy the core to misoc
<ysionneau>
you can use ./make.py -X /path/to/mixxeo-soc
<ysionneau>
(make.py being in the misoc repository)
<larsc>
ah!
<ysionneau>
if that's what you were searching for
<larsc>
yes
<larsc>
now I just need to modify the core to not decode the DVI and then hopefully all will be good
<larsc>
there is the RawDVISample I guess I can use that
<larsc>
is there a pre-build jfmem file for mixxeo somewhere?
<larsc>
fjmem
<ysionneau>
same as for the M1 I guess
<ysionneau>
ah no
<larsc>
urjtag tells you that you don't have the correct permissions to open the device, as opposed to the xilinx cable drivers which just crash
Bertl is now known as Bertl_zZ
<larsc>
is the mixxeo flash map the same as for the milkymist?
<ysionneau>
can't you just use make.py flash_bitstream
<ysionneau>
and flash_bios and such?
<larsc>
maybe
<ysionneau>
for the bitstream it seems it's address 0 for both m1 and mixxeo
<larsc>
No such file or directory: 'tools/byteswap'
<ysionneau>
make -C tools
<larsc>
yea... I'm a bit slow today ;)
<ysionneau>
and if you are using the target "mlabs_video" the bios address in the flash is : cpu_reset_address=0x00180000
<ysionneau>
but all of this is taken care of by make.py
<larsc>
and now only the good old "error: pld subsystem: unknown instruction 'CFG_IN'
<larsc>
which is strange because it is already in the urjtag file
<larsc>
added by sb0
<ysionneau>
the mibuild programmer code does not seem to use the CFG_IN stuff anymore
<larsc>
well the bitfile uses the instruction
<larsc>
one the other hand if I try to define the instruction by hand I get a invalid instruction length error
<larsc>
and I get this "Unknown stepping! (0100)"
<larsc>
hm, ok added the settping to the STEPPINGS file, seems to work
<larsc>
and it doesn't boot anymore...
<sb0>
larsc, you'll love this one. reducing the HDD frequency on the crappy lenovo thing does improve things, not because of timing issues, but because it disables certain problematic DRM features when using a lower speed.
<ysionneau>
omg
<sb0>
but there is, in addition to this bug, a more annoying and intermittent one that makes the hdd controller stop sending interrupts, typically after some dozen GBs have been transferred
<sb0>
oh and I forgot, the sound doesn't work at all, too
<larsc>
"xrandr: Failed to get size of gamma for output default" ...
<larsc>
and even the pll locks
<sb0>
you may get a better edid from the dvimixer C firmware
<larsc>
yea, but the DMA doesn't work
_florent_ has joined #m-labs
<larsc>
the debug module should constantly generating data, shouldn't it?
<GitHub180>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/FcfJ
<GitHub180>
artiq/master 71c5115 Sebastien Bourdeauducq: gui: handle exit in explorer
<sb0>
ysionneau, does artiq_gui work with your latest conda packages?
<ysionneau>
nop :/
<ysionneau>
shared library issues
* ysionneau
just spent 20 min with fedex on the phone
<ysionneau>
this is just crazy
wpwrak_ has joined #m-labs
wpwrak has quit [Ping timeout: 276 seconds]
<larsc>
sb0: I think I need some help with the dma. I connected just a IntCounter as the source and when I start the DMA it does not write anything and busy stays 1
<larsc>
is the way the submodules are created in the dvi debug module still the correct way?
<_florent_>
ysionneau: I had the same problem when importing some electronic stuff... very painful...
<_florent_>
hi larsc
<ysionneau>
that's some obscure broker issue
<_florent_>
I haven't tested Mixxeo with the new "packetized" mode of Endpoint
<ysionneau>
about sending something temporarily or "for good"
<_florent_>
I can have a look this evening and fix it if something is broken
<_florent_>
you are just trying to build the upstream Mixxeo and test it?
<larsc>
me?
<_florent_>
yes
<larsc>
no, I want the raw DVI data
<larsc>
slightly modified things to use RawDVISampler instead of DVISampler
<_florent_>
lasc: I think you issue is here: self.submodules += dma, if you do that, the CSR register won't be instanciated
<_florent_>
you have to do self.submodules.dma = spi.DMAWriteController(dma_lasmi.Writer(lasmim), spi.MODE_SINGLE_SHOT)
<larsc>
_florent_: yep, just noticed that and wondered why the whole DMA was optimized away
<larsc>
thnaks
<_florent_>
that's something that has to be fixed in Migen (or at least that have to raise an error)
<larsc>
_florent_: how exactly are the length and base registers connected to the intsequence?
<larsc>
what I'm seeing is that int_sequence never asserts stb
<larsc>
ah, ok
<larsc>
so the generator writes stuff to the int_sequence
<_florent_>
yes IIRC the generator send a token to the int_sequence with the length and base address
<_florent_>
and the int_sequence generates all the addresses
<larsc>
Looks like the generator never fires
<_florent_>
do you see the logic for it on the verilog? can you share the software?
<larsc>
I've wired the trigger in the generator to 1 now stuff is running
<larsc>
the re signal of the CSR is supposed to be asserted when the register is written to, right?
<_florent_>
yes
<_florent_>
also verify that the csr_map you are using for your dma is not already used by another module (I lost half a day with an issue like that...)
<larsc>
all the other registers work fine
<larsc>
it's just the shoot register
<_florent_>
strange
<larsc>
turned it into CSRStroage(), I can read and write to it, but it still doesn't trigger the transfer
Bertl_zZ is now known as Bertl
<_florent_>
can you share your code?
<larsc>
which code?
<larsc>
I'm poking the registers in the bios using mr/mw
<_florent_>
larsc> which code?: the generated verilog and csr.h
<larsc>
I just started a build without the shoot register give me a moment
mumptai has joined #m-labs
<larsc>
at least I'm getting raw DVI data now if I use the enable instead of the shoot register
<_florent_>
OK, strange but if it works...
<larsc>
next step get the data ontop my laptop, can I use jtag to dump the sdram?
<_florent_>
don't know (never done that), why not over UDP?
<larsc>
is there built-in tftp server support?
<larsc>
or do I have to write something?
<_florent_>
I think Sebastien did something like that when he was debugging the DVI sampler
<ysionneau>
jboulder in your udev rule, you do matching by using operators like '==', but you can also do assignments with '=', for instance you can add : ..., NAME="some_name"
<ysionneau>
this way you enforce the name of a device matching the udev rule
<larsc>
I see arp requests from the board, but it doesn't seem to see the answer
* ysionneau
just received the XuLA2-LX9 fpga board
_whitelogger__ has joined #m-labs
<larsc>
ok, just ignore the crc check and network works...
_whitelogger_ has quit [*.net *.split]
<_florent_>
hmmm ok thanks, I will have a look at the CRC
<larsc>
yea! lots of raw dvi data
<_florent_>
:)
<larsc>
somethings still fishy with DMA, but that's good enough for today