<cr1901_modern>
"magical mmio?" Misoc has code to automatically create CSR registers attached to a CSR bus. The CSR bus is then connected to the wishbone bus
<shuffle2>
redpid apparently just uses axi
<shuffle2>
i believe i have the CSRs "hooked up", i'm just wondering how to actually access them from arm side of zynq
<shuffle2>
axi has some mmio region, maybe?
<cr1901_modern>
Oh I've no experience using a hard CPU w/ misoc. I have no idea how the arm CPU is exposed to the FPGA
<shuffle2>
its just 0x40000000 i think, but kernel doesnt seem to want to map it via /dev/mem (need dtb entry or something i guess...gross)
mumptai_ has joined #m-labs
mumptai has quit [Ping timeout: 255 seconds]
balrog has quit [Ping timeout: 264 seconds]
balrog has joined #m-labs
<whitequark>
sb0: pong
<whitequark>
sb0: the ARP issue is a known issue with smoltcp
<whitequark>
though I haven't expected it to manifest in passive mode
<whitequark>
but yeah, doing massive ARP scans would do that alright
<sb0>
is it quick to fix?
<whitequark>
fairly
<whitequark>
I actually started fixing it during the flight
<whitequark>
so I'm halfway done
<GitHub36>
[smoltcp] whitequark pushed 1 new commit to master: https://git.io/vFOCS
<GitHub36>
smoltcp/master 0091191 whitequark: Rework TcpSocket::{send,recv} to remove need for precomputing size....
<whitequark>
(the above is unrelated)
<whitequark>
(but it lets you do streaming parsing in ionpak I guess)
<sb0>
well the current solution in ionpak is good enough
<sb0>
the artiq bugs, however, are obnoxious
<whitequark>
I was stuck without internet and had nothing better to do, sorry
<GitHub23>
[smoltcp] whitequark closed pull request #67: Do not send ICMPv4 responses to broadcasts (master...improve_dst_unreachable) https://git.io/vFqBj
<GitHub161>
[smoltcp] whitequark pushed 1 new commit to master: https://git.io/vFOCp
<GitHub81>
[smoltcp] whitequark commented on issue #67: Thanks! https://git.io/vFOCh
<GitHub161>
smoltcp/master d1d80ca Dan Robertson: Do not send ICMPv4 responses to broadcasts...
<travis-ci>
m-labs/smoltcp#361 (master - 0091191 : whitequark): The build passed.
<sb0>
is there any correspondence between ID_PATH, which udev uses, and the output of lsusb -t, which openocd uses?
<sb0>
except for the USB interface number they seem completely different. sigh!
<whitequark>
try DEVPATH
<whitequark>
I think that's what you're looking for
<rjo>
shuffle2: to implement the api for the redpitaya host side software. yes, max(2, n) is fine. it will be optimized away. and yes. the CSRs appear on mmio. see the little script that sets a bunch of them.
<sb0>
then 3-10 (-> 3:10) is the location that openocd wants
<sb0>
the devnodes I made udev create correspond to the UART (non-JTAG) channels only
<sb0>
rjo, is the openocd installed in /usr/local/bin up-to-date and able to flash saymas?
<shuffle2>
rjo: i really dont understand why the dummy stuff is required :( it seems that also requires adding the CRG module...is that really another PS-required component?
<sb0>
also I'm going to put all three boards on the relay, since there is the 1V8 bug and others
<sb0>
whitequark, what did you use to program that small arduino-like board? do you still have the source and instructions somewhere?
<sb0>
is it 5V compatible? we can just hook it up to the ATX control pin if so
<rjo>
sb0: i didn't install that. no idea.
<rjo>
shuffle2: the redpitaya software axpected things at certain mmio segments. the dummy things provide the offsets.
<rjo>
shuffle2: take a look at the redpitaya software and gateware (from that time)
<whitequark>
sb0: amazingly, yes
<whitequark>
I do have the source, I thought about throwing it out no later than two days ago
<whitequark>
it's Maple IDE
<sb0>
and 5v?
<whitequark>
let me just zip everything up
<whitequark>
just configure it as open drain
<whitequark>
I'm not sure if the pin is 5V tolerant, sec
<sb0>
you can still blow an open drain pin if you exceed the maximum voltage
<whitequark>
save it as whatever.pde and put into ~/sketchbook/whatever/
<whitequark>
pins D5-D9 and D14 are 5V tolerant
<whitequark>
the sketch uses D13 and D14 now
<whitequark>
one of them is a LED I think
<whitequark>
yeah LED is D13
<whitequark>
so you can connect your thing to D14
<shuffle2>
rjo: ok...so the hk(housekeeping) region should be at offset 0, ie 0x40000000. however the other region is at 0x40300000. im not following where this huge offset comes from. the redpid scripts to deal with csr maps seem to indicate the bank size is only 0x800
<shuffle2>
in any case, since i only have 1 bank, i should be able to expect it at 0x40000000 afaict
key2_ has joined #m-labs
<shuffle2>
i'm suspecting there is something else going on. any access to any part of this region just hangs
<GitHub134>
[smoltcp] dlrobertson commented on issue #66: After a rebase, tests should pass here. https://git.io/vFOye
<GitHub102>
[artiq] sbourdeauducq commented on pull request #842 2cf530c: The FMC breakout board does not have a "J44A" marking on its silkscreen and even less on its future front panel, so referencing it does not make the reader's life easier. You should write this documentation for someone who is setting up their boards the first time, and you should have said the *bottom* connector. https://github.com/m-labs/artiq/pull/842#discussion_r148244915
<GitHub5>
[artiq] sbourdeauducq commented on pull request #842 2cf530c: The VHDCI breakout board does not have a "J44A" marking on its silkscreen and even less on its future front panel, so referencing it does not make the reader's life easier. You should write this documentation for someone who is setting up their boards the first time, and you should have said the *bottom* connector. https://github.com/m-labs/artiq/pull/842#discussion_r148244915
<GitHub95>
[smoltcp] klickverbot commented on issue #68: We saw a similar issue in our network a couple of weeks ago (ARP requests for the same address more than once every millisecond, from a nominally idle KC705), but it was late at night trying to get some actual data, so we just restarted the core device and it was gone. Unfortunately, I can't seem to find the dump right now, but reproducing this might definitely be a bit non-straightforward, as the probl
<sb0>
oh, and sayma1 just died. won't power up anymore and only the 12V LED is on.
<sb0>
perfect!
<sb0>
just a power cycle did that
key2 has quit [Quit: Page closed]
<sb0>
relay and RTMs are on the survivors ...
<sb0>
fixed the board. one of the solders was flaky.
<sb0>
ok removing data/dqs/dm pins from ddram_64 in migen works around the bug
<sb0>
now the rtm bridge doesn't work
<sb0>
not reliably
<sb0>
well not at all; reading on the other side of the bridge just locks up the bus ...
<sb0>
_florent_, ^^^
<sb0>
which is also what i remember from the tests in maryland
<sb0>
_florent_, didn't we also agree that the bus shall never lock up but instead bus errors should be reported?
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
<GitHub72>
[smoltcp] sbourdeauducq commented on issue #3: Does anyone want to contribute funds to this? https://git.io/vF3RQ
rohitksingh1 has quit [Quit: Leaving.]
Gurty has quit [Ping timeout: 240 seconds]
Gurty has joined #m-labs
Gurty has quit [Changing host]
Gurty has joined #m-labs
<whitequark>
sb0: regarding the leafmaple board, I remember now
<whitequark>
there is an obnoxious USB DFU bug
<whitequark>
sb0: aha right. a) you need dfu-util 0.6 or later, and I think their IDE doesn't ship that one
<whitequark>
b) how I flashed it is, I put it into "perpetual bootloader mode" (hold BOOT and release RESET)
<whitequark>
then tried to flash it via the IDE, which failed, but gave me the built firmware somewhere in /tmp
<whitequark>
then manually flashed it via system dfu-util
<whitequark>
standard embedded device fare...
<GitHub62>
[smoltcp] whitequark commented on issue #3: I know @edef1c had some code they wanted to contribute to smoltcp. That would actually go a long way towards IPv6 support. https://git.io/vF3pT
<GitHub158>
[smoltcp] whitequark commented on issue #68: This is the exact same issue as #25.... https://git.io/vF3pn
<GitHub53>
[smoltcp] whitequark commented on pull request #65 700ddd0: No no no, this is very intentional! Sequence numbers are **not** totally ordered! They wrap! https://git.io/vF3hT
<GitHub42>
[smoltcp] whitequark commented on issue #65: I'll need to take a closer look at these changes. I'm not yet completely convinced they're correct. But, they do seem to go in the right direction. https://git.io/vF3hY
<GitHub80>
[smoltcp] whitequark commented on issue #57: Can you please rebase again? https://git.io/vF3h8