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
<sb0>
whitequark, with the current rtio::log implementation, the first word contains only one byte (since i == 0, then i % 4 is also 0). is that intended?
<whitequark>
sb0: no, unintentional, should be probably fixed
<whitequark>
not sure how our tests didn't catch that
<GitHub63>
[smoltcp] whitequark commented on pull request #67 3a28298: This code *asks* to be refactored into something like `icmpv4_reply` that would make the `Ipv4Repr` with the given `Icmpv4Repr`, and also have the condition for unicast addresses. https://git.io/vFmsT
<GitHub118>
[smoltcp] whitequark commented on pull request #67 3a28298: Just push the entire payload there, up to MTU. It's more useful when debugging networking issues anyway, and it's free for us because we don't allocate. https://git.io/vFmsU
<GitHub75>
[smoltcp] whitequark commented on pull request #67 3a28298: `use core::cmp` and then `cmp::min(...)`. https://git.io/vFmsJ
hobbes- has quit [Ping timeout: 248 seconds]
balrog_ has joined #m-labs
bunnie has quit [Ping timeout: 248 seconds]
balrog has quit [Ping timeout: 248 seconds]
bunnie has joined #m-labs
hobbes- has joined #m-labs
balrog_ is now known as balrog
hobbes- has quit [Ping timeout: 248 seconds]
hobbes- has joined #m-labs
rjo has quit [Ping timeout: 248 seconds]
rjo has joined #m-labs
<key2>
hi
<key2>
rjo: You've played with zynq and migen, right ?
<GitHub75>
[artiq] sbourdeauducq commented on pull request #842 436bb28: This is not clear. It sounds like both J44A and J41 are on the same board. And which "VHDCI board", the FMC/VHDCI or the VHDCI breakout? https://github.com/m-labs/artiq/pull/842#discussion_r148021799
<key2>
rjo: I generated a simple ledblink that I add in my boot.bif, generate a boot.bin that i place in a sdcard, then when I boot, the led does blink, but u-boot doesn't show up
<key2>
if I leave their .bit, uboot does show :/
<key2>
you might have a clue ?
<key2>
rjo: you have a working repo ?
<rjo>
key2: github.com/jordens/redpid
<key2>
I didn't see the linux part in it
<shuffle2>
i use arch linux on zedboard, i think they use some preexisting uboot
<shuffle2>
however it's configured to not load .bit. i prefer it that way since you can easily reload bitstream from linux dynamically
<shuffle2>
also i noticed you dont need the byteswap hack (so i guess the kernel is recent enough to have useful fixes)
<key2>
shuffle2: how do you load a .bit directly from linux ?
<shuffle2>
no i'm still working on my first thing :) i've been looking at redpid
<GitHub3>
[artiq] jordens commented on pull request #842 436bb28: "Name ambiguity due to encoding metadata in the name" strikes again. Nice indication that opaque code names are the way to go and that any approach to make names "intuitive" leads to actual issues with inconsistency, misunderstanding that are way more tangible and hard to relevant than merely complaints *à la* "can't remember the name". https://github.com/m-labs/artiq/pull/842#discussio
<key2>
I have /sys/devices/soc0/amba/f8007000.devcfg/ but not is_partial_bitstream
<shuffle2>
it probably means your kernel is ancient
<larsc>
be aware that xdevcfg is broken in the latest Xilinx kernel
<shuffle2>
you could just try to write to xdevcfg. if you need is_partial_bitstream, the failure mode is that writing xdevcfg will halt the arm cores (your linux will die)
<key2>
yep it does die
<key2>
shuffle2: I was using the linux in the digilent tree
<shuffle2>
i'd guess it's probably not too hard to make the above work with any zynq
<key2>
shuffle2: so if I get it right, you never recompiled the linux/iboot, you just generate a .bit file with migen and directly write it to /dev/xdevcfg
<key2>
so it looks like my kernel had partial bitstream support
<key2>
but the /sys/devices/soc0/amba/f8007000.devcfg/is_partial_bitstream is not there
<key2>
ha I found out, the kernel driver was not there :/
<key2>
so now, when I flash a bitstream to the /dev/xdevcfg, it does blink, but I lose my hand on the prompt, like it freezes
<shuffle2>
need to poke is_partial_bitstream
<key2>
I did
<key2>
in fact, if I set it to 1
<key2>
the .bit I write to it doesnt do anything
<key2>
when I just do a cat blinky.bit > /dev/xdevcfg it did blink
<key2>
so is there a special way to generate partial bitstream files ?
<shuffle2>
i'm not actually using partial bitstreams, it's just that the driver uses that flag to manage power states (at least in my case)
<key2>
so what do you use ?
<shuffle2>
just the the normal bitstream
<key2>
so you generate normal bitstream
<key2>
set the is_partial_bitstream to 1
<key2>
and cat the normal bitstream
<key2>
in a .bit (and not .bin) right ?
<shuffle2>
yea
<key2>
ha, if I do that it won't even blink
<key2>
it only blinks if I leave the is_partial_bitstream
<key2>
that's weird
<shuffle2>
but on older kernels you supposedly had to byteswap the bitstream? (that's what people seem to refer to as the ".bin")....you could try that i guess
<key2>
how do you byteswap ?
<key2>
also, if it was the case, why would it blink ?