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
<GitHub11>
[sinara] gkasprow pushed 1 new commit to master: https://git.io/vNOgx
<GitHub11>
sinara/master 05988c7 Greg: fixed #377
<GitHub5>
[artiq] philipkent commented on issue #888: It was present. `llvm-config` did get installed to `/usr/local/llvm-or1k/bin`, it was just that `/usr/local/llvm-or1k/bin` wasn't on the system path. After adding `/usr/local/llvm-or1k/bin` to my path variable `make install` ran without errors and I get the "Rust ready to roll" message at the end. https://github.com/m-labs/artiq/issues/888#issuecomment-356784666
<sb0>
re. yesterday's sayma bug: it's not the FTDI-chip that became borked, it's the MMC
<sb0>
something (USB reenumeration?) put all 3 boards into the LPC bootloader mode until the cables were unplugged and re-plugged
<sb0>
the gibberish characters I was getting back were the bootloader replies
<sb0>
iirc Greg is aware of this problem ...
<sb0>
in bootloader mode, most of the power supplies do not start and the FPGA doesn't work
<GitHub72>
[artiq] sbourdeauducq commented on issue #854: @gkasprow Your MMC firmware is buggy. It needs a PHY register dump (E) before it actually initializes the PHY. After I do it then my media converter detects a carrier. I don't know yet if it's the correct MII mode, though. https://github.com/m-labs/artiq/issues/854#issuecomment-356837141
<davidc__>
sb0: once (several years ago) I had a board with the same issue - couldn't get timing closure for an RGMII link . In my case it was a phy that didn't support the clock/data skew that the datasheet claimed it did. But anyways, solution on the prototype was a ~1ft length of wire coiled up above the PCB to add sufficient delay to the clock. But hey, it worked.
<sb0>
yeah, we're using MII now to avoid this sort of issue
<sb0>
on our board, this is compounded by non-cc pins on the FPGA that would make timing less reproducible...
<davidc__>
sb0: which phy are you using?
<sb0>
max24287
<davidc__>
ah. MII would put you in 10/100 land, and IIRC you end up with some irritating compat issues with other systems
<davidc__>
but I'm not sure if thats a concern for your design
<sb0>
the PHY we have is a beast and does rate conversion
<GitHub10>
[artiq] sbourdeauducq commented on issue #854: The command needs to be issued at a special time during MMC startup, though. And when the PHY is correctly initialized, then JTAG is broken. Please make fixing those MMC bugs a priority. https://github.com/m-labs/artiq/issues/854#issuecomment-356841163
<davidc__>
sure - its more on the other end of the link: I've found autonegotiation of 100M to be... twitchy... on certain host adapters
<sb0>
yes, the MAX24287 would always give 1Gbps on the other end, even if the interface with the FPGA is MII
<davidc__>
sb0: my understanding is that the way that works is each byte is stuffed on the wire 10X
<davidc__>
or at least, in certain modes thats the way it works
<sb0>
that Sayma MMC is even buggier than I thought it would be, and I had been very skeptical about it...
<sb0>
davidc__, there's a lot of bling-bling inside this chip, including large buffers
<davidc__>
eh, I don't see it in the datasheet, but I believe you! I just wanted to give you the heads up because it was an issue that I'd run into before :)
<sb0>
with a DMM I have 11.3-11.4V at the connectors...
<sb0>
whitequark, how do I log from libboard?
<sb0>
sigh this is complicated
<sb0>
I just want to dump raw ethernet packets, it used to be easy before
<sb0>
whitequark, missing macro_use for uart_console in lib.rs?
<sb0>
well that doesn't work. sigh!
<sb0>
nothing gets printed with println! in libboard
<sb0>
ah, no I'm doing it wrong ...
<GitHub0>
[artiq] sbourdeauducq commented on issue #854: The command needs to be issued at a special time during MMC startup, though. And when the PHY is (seemingly) correctly initialized, then JTAG is broken. Please make fixing those MMC bugs a priority. https://github.com/m-labs/artiq/issues/854#issuecomment-356841163
<GitHub69>
[artiq] sbourdeauducq commented on issue #854: Data remains thoroughly corrupted in this mode, though I don't know if the PHY is really in MII, or if I'm just exploiting some MMC firmware bug that puts the PHY in another mode.... https://github.com/m-labs/artiq/issues/854#issuecomment-356854471
<GitHub17>
[artiq] sbourdeauducq commented on issue #854: Data remains thoroughly corrupted in this mode, though I don't know if the PHY is really in MII, or if I'm just exploiting some MMC firmware bug that puts the PHY in another mode.... https://github.com/m-labs/artiq/issues/854#issuecomment-356854471
<GitHub64>
[artiq] sbourdeauducq commented on issue #854: The E command needs to be issued at a special time during MMC startup, though: after "Net up" and before "GMIICR mod 18 0xffff PHY init done". And when the PHY is (seemingly) correctly initialized in MII (?), then JTAG is broken. Please make fixing those MMC bugs a priority. https://github.com/m-labs/artiq/issues/854#issuecomment-356841163
<GitHub92>
[artiq] sbourdeauducq commented on issue #854: Can you put together a simpler MMC firmware that sets the PHY in MII mode, gives it to the FPGA immediately regardless of whether the FPGA is configured or not, and doesn't touch it again? https://github.com/m-labs/artiq/issues/854#issuecomment-356889993
<GitHub156>
[artiq] sbourdeauducq commented on issue #854: Can you put together a simpler MMC firmware that sets the PHY in MII mode (correctly, please double-check that links are detected by media converters etc.), gives it to the FPGA immediately regardless of whether the FPGA is configured or not, and doesn't touch it again? https://github.com/m-labs/artiq/issues/854#issuecomment-356889993
<GitHub6>
[artiq] sbourdeauducq commented on issue #854: Can you put together a simpler MMC firmware that sets the PHY in MII mode (correctly, please double-check that links are detected by media converters, and that the PHY outputs both TX and RX clocks at 25MHz at all times, etc.), gives it to the FPGA immediately regardless of whether the FPGA is configured or not, and doesn't touch it again? https://github.com/m-labs/arti
<sb0>
on sayma, even basic plans like triggering power supply diagnostics from the UART go wrong, because writing on the UART trigger the LPC bootloader bug after the board is power-cycled. amazing...
<hartytp>
sd0: I'm setting up to look at 1v8 and HMC830 issues atm
<hartytp>
sb0
<hartytp>
are you using the sayma_amc_standalone target?
rohitksingh_work has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
rohitksingh1 has joined #m-labs
<sb0>
hartytp, ah, excellent news!
<sb0>
yes
rohitksingh has quit [Ping timeout: 276 seconds]
<sb0>
there are conda packages too
<hartytp>
do you see the issue with just the AMC, or the RTM as well?
<hartytp>
(or, rather, do you need the RTM to reproduce the issue?)
<hartytp>
also, how do I flash the RTM? Looks like the AMC can be done easily with artiq_flash, but I lost track of the situation with the rtm
<sb0>
the 1V8? it happens with and without the RTM. it seems more frequent when the RTM is there, though it could be a false impression or just a coincidence that the AMC board on which I don't have a RTM is less affected by the bug
<sb0>
you cannot flash the RTM. load the RTM FPGA from JTAG directly
<sb0>
didn't I email you the corresponding OpenOCD script?
<hartytp>
okay, thanks. You probably did and I just forgot. Will check and let you know if I have any problems
<hartytp>
in that case, I'll start with only the amc
<sb0>
ARTIQ boot won't go far without the RTM though
<sb0>
the runtime requests the RTM quite early
<sb0>
the DRTIO targets don't need a RTM at all, on the other hand
<sb0>
also, you need to tweak artiq_flash (remove the RTM FPGA detection and fix the PLD numbers) to be able to flash when the RTM is not connected
<sb0>
plus you need to update the MMC firmware, otherwise JTAG is unreliable without a RTM
<hartytp>
okay. I'll add the rtm then
<whitequark>
sb0: did you figure out the issues with libboard?
<sb0>
whitequark, yes. but I think a macro_use should be added into the code
<sb0>
+#[macro_use]
<sb0>
pub mod uart_console;
<whitequark>
hm
<sb0>
we definitely need some form of easy logging in libboard for debugging
<hartytp>
sb0: fwiw, using the gateware that greg loaded onto my Sayma, the 1v8 seems good so far (10 power cycles, and left on for an hour)
<hartytp>
what artiq_flash command are you using with the amc?
<whitequark>
sb0: ok, maybe we can add a liblog dependency in libboard
<whitequark>
*log crate
<whitequark>
it's not expensive
<hartytp>
"artiq_flash -t sayma" didn't work for me when using the artiq-sayma_amc-standalone conda package. artiq_flash was looking for binaries in "sayma_standalone" not "sayma-amc_standalone" renaming the folder fixed that...
<sb0>
hartytp, can you file an issue so I remember to fix that?
<hartytp>
will do
<sb0>
I've only used --srcbuild which doesn't have the problem
<hartytp>
is there any particular magic dance I have to do to flash sayma amc?
<sb0>
though you have "all zeros" and I was seeing "all ones" ...
<hartytp>
aah, missed that one.
<sb0>
hartytp, okay, now load the RTM FPGA
<hartytp>
was planning to do some power supply tests (power cycle a few times and also wait a bit) while leaving the RTM with whatever firmware greg put on it.
<hartytp>
nb also haven't updated the mmc firmware yet
<sb0>
hartytp, there is no firmware in the RTM
<hartytp>
sorry, gateware
<sb0>
neither. it will be loaded from AMC.
<GitHub164>
[artiq] whitequark commented on issue #888: > After adding /usr/local/llvm-or1k/bin to my path variable make install ran without errors and I get the "Rust ready to roll" message at the end.... https://github.com/m-labs/artiq/issues/888#issuecomment-356956959
<sb0>
hartytp, so if you load the RTM FPGA with JTAG it won't permanently affect your board
<sb0>
and I'm curious whether serwb etc. work well for you
<hartytp>
ack. I forgot that we weren't using RTM flash
<hartytp>
sb0: can you send me the openocd script again, please?
<hartytp>
Had something odd with the JTAG not working, but couldn't reproduce (suddenly started working properly). Will look into it further if it comes back
<hartytp>
remind me which steps I should take to try to reproduce your 1V8 issue.
<hartytp>
Is it enough to have the RTM plugged in but not configured? Can I just power cycle the board ~20 times and look at the the 1V8 LED (giving it say 10 seconds each time to die)?
<sb0>
you can just leave it running for hours/days
<sb0>
and yes.
<sb0>
hartytp, so serwb seems reliable for you? interesting...
<GitHub194>
[smoltcp] dlrobertson commented on pull request #116 e0af4d3: IMO at a first glance, I'd say the parsing of the ipv4 address should be a match arm here if the number is is `0xffff` and `*head_idx == 6 || use_tail && *tail_idx == 1`. This would also increase readability in my opinion. https://github.com/m-labs/smoltcp/pull/116#discussion_r160997088
<sb0>
hartytp, can you connect a 100MHz clock and see if it goes further?
<sb0>
it should init the 7043, the dacs, and start producing waveforms
<hartytp>
will do
<hartytp>
but, I was going to look at the 1V8 first
<hartytp>
okay, getting a 100MHz source
<sb0>
if you have a balun and smps, you should be able to see it (allaki has some loose screws still)
<hartytp>
I don't, but I can jab a scope in there :)
<sb0>
differential?
<sb0>
well I guess you should see something even with a single ended probe
<GitHub59>
[smoltcp] dlrobertson commented on pull request #116 e0af4d3: I *think* `::1:fff:192.168.1.1` would also be accepted as a valid IPv4 mapped IPv6 address under the current parsing rules. https://github.com/m-labs/smoltcp/pull/116#discussion_r160999305
<sb0>
hartytp, just keep using the board. the 1v8 bug will hit you regularly, if it's as bad as it is here...
<hartytp>
"[ 0.028259s] INFO(board_artiq::serwb): waiting for AMC/RTM serwb bridge to be ready..."
<sb0>
did it block here?
<hartytp>
it did until we reflashed the RTM
<hartytp>
so either it was just very slow and we didn't wait long enough
<hartytp>
or there was some issue that reflashing the rtm fixed
<hartytp>
not sure
<hartytp>
either way, no HMC lock, but I'll look at that now...
<sb0>
the RTM is not "flashed". JTAG loads the bitstream into volatile memory and it is lost when the board is power cycled.
<sb0>
if you just power up a sayma and serwb init fails until you load the rtm via jtag, this is expected
<sb0>
if it keeps failing after you've loaded the rtm it's a bug
<hartytp>
sorry, meant load not flash
<hartytp>
anyway, loading the rtm makes everything work. Subsequently running artiq_flash -t sayma start just waits on the ser-wb connection
hartytp has quit [Ping timeout: 260 seconds]
<sb0>
with a single rtm load, reliably?
key2 has quit [Ping timeout: 260 seconds]
<GitHub173>
[artiq] gkasprow commented on issue #854: I changed a bit the init sequence. It does full reinit of the PHY chip including pin strapping once the FPGA config is done. Then it keeps the PHY disconnected from MMC.... https://github.com/m-labs/artiq/issues/854#issuecomment-356993707
<_florent_>
hartytp: good that you are also doing some tests. In addition of the 1.8v test, it would be very interesting to see if serwb init is reliable with your boards. To test that, you just need to power off/on the board, reload rtm and see if serwb is working correctly.
<ohsix>
whitequark: i can help with the re question, would be a lot of chatter on twitter tho
<cjbe>
_florent_: some more statistics: just reconfiguring the board (no power cycling), I saw 36/216 memory tests fail. Read/write leveling msgs for failing attempts here: https://hastebin.com/juguqunogu.bash
<ohsix>
technically i have ida, i could get hex-rays to dump the pseudocode
<_florent_>
cjbe: thanks, i think this is more related to software than hardware
<_florent_>
cjbe: each time there is an error, we see that one module has an interval of 8 on the read delays
<cjbe>
_florent_: good news, I guess!
<_florent_>
cjbe: could you do some test by changing this from 8 to 16 or 32? :
<whitequark>
it does use the bus that would on different motherboards be exposed as DDC
<ohsix>
k
<ohsix>
there's another avenue you can come at this with later, panelook is a huge market for lcd trade, and they have grey market datasheets; sometimes there is enough information to find the datasheet outright on the internet
<ohsix>
oh dear this is the delphi thing
<whitequark>
yes. this is the delphi thing
<ohsix>
does this tool work with just the gpu in one model or does it work across a few that have intel/nv/amd gpus in them
<whitequark>
the latter
<whitequark>
look at the library
<whitequark>
the library dispatches to intel/nv/ati
mumptai has joined #m-labs
<ohsix>
yea just did, sry, was getting edp/dcpd info
<ohsix>
the actual addresses that matter over dpdc might be in the ini files, will look more after lunch; if you can just use the drm api for aux/dpcd then you can just go do it, or base the tool on the linux code
<cjbe>
_florent_: moving 16 LSBs into the window rather than 8 solves the memory issue for me (0 errors in 132 attempts)
<cjbe>
_florent_: I assume this should universally be a safe thing to do, as the valid window should always be around an order of magnitude larger than 16 LSB?
mumptai has quit [Remote host closed the connection]
<GitHub45>
[artiq] cjbe opened pull request #889: firmware: make read leveling robust for KUS SDRAM (master...robust-kus-read-leveling) https://github.com/m-labs/artiq/pull/889