<sb0>
and with altera being bought by intel, who invent things like ME, SMM and ACPI, there is little hope
<larsc>
knowing how such large companies work on the inside I'm more supprised that anything works at all
<rjo>
sb0: i know. _florent_ wrote that code. either of us three can fix that.
<sb0>
I don't know what the solution is - I didn't touch JESD other than moving code around
<sb0>
I'm sending 1.2GHz to the sayma now, with the hmc830 bypassed (and the JESD reset commented out), the ad9154 SERDES PLL locks but then I get "no sync lock"
<sb0>
_florent_, are you generating sysref?
<sb0>
meh that's dumb
<sb0>
csr issue...
<sb0>
rjo, why did you add ad9154 to the mem_map?
<rjo>
did i do that recently? or was that forgotten when the spi busses csrs moved from kernel to comms cpu?
<rjo>
if you need the runtime fixed today you'll have to figure it out yourself or ask florent.
<whitequark>
sb0: releases just have to be free from known bugs and have reasonably complete APIs
<whitequark>
I don't want to have a half-working IPv6 implementation there
<sb0>
whitequark, yes, that sounds like something we'd want to base artiq releases on
<whitequark>
sb0: okay
<sb0>
whitequark, and artiq remains the main user and sponsor of smoltcp.
<sb0>
misoc/migen is also used in a few other things, by the way
<whitequark>
isn't that the litex fork?
<whitequark>
precisely because artiq drives misoc/migen development?
<sb0>
to put it bluntly, litex exists because _florent_ doesn't want to clean up code
<_florent_>
sb0: yes i'm using non integer ratios (8 /10 hdmi), but you don't need non-integer ratio, you can use different code in migen
<sb0>
I don't mind non-artiq patches and features into migen/misoc, as long as they're clean
<whitequark>
the reason I said that about smoltcp is because of how much code external contributors bring, like I expect that I wouldn't have to actually do much coding
<whitequark>
to get an IPv6 stack*
<sb0>
_florent_, why does hdmi need that?
<whitequark>
sb0: ack re litex
<_florent_>
whitequark, sb0: that's not the reason...
<sb0>
_florent_, well, you started litex after I removed a bunch of dirty code from migen/misoc
rohitksingh_work has quit [Read error: Connection reset by peer]
<_florent_>
sb0: i needed something that was convenient for me to work with and more open (I sometime need iterations to get clean code, i know you don't...)
<whitequark>
sb0: regarding eth switch fix, I'm doing some work on artiq_devtool that will let me do gateware modification much more easily
<whitequark>
I'll finish it soon, and then will just have to debug the gateware I already wrote
<whitequark>
sb0: btw shouldn't we add release-* branches to CI autobuild filter?
<sb0>
whitequark, yes, we can add those branches
<whitequark>
ok
<sb0>
_florent_, but are you willing to do those iterations?
<_florent_>
sb0; i was willing to, but you also have to understand that you have to give time to people to do that and explain a bit more what is clean for you
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
<GitHub-m-labs>
[buildbot-config] whitequark pushed 1 new commit to master: https://git.io/vbTDP
<GitHub-m-labs>
buildbot-config/master ff1e2b5 whitequark: Build changes not just on master branch but also release-\d+ ones.
<_florent_>
sb0: ad9154.rs is not up to date, i said it was not commited to avoid breaking compatibility with kc705
<_florent_>
sb0: that's probably not easy to have a common file, i'll probably create a ad9154_kc705.rs and ad9154_sayma.rs is we need to keep kc705 compatibility
<sb0>
_florent_, we don't need to keep kc705 compatibility
<sb0>
I don't think it's particularly hard to keep it, but not worth the effort either...
<_florent_>
sb0: ok thanks
<sb0>
_florent_, what needs to be changed?
<_florent_>
jesd parameters, ad9154 lane mapping, spi config, etc...
<_florent_>
I'm going to do a test and I'll commit things
<_florent_>
with the ad9154.rs you were using, it's normal to get no sync lock
<rjo>
sb0: just to check: there was no deliverable of DRTIO-syncing phaser to sayma?
<sb0>
rjo, no there wasn't
<rjo>
ok. fine with nixing it. i'd announce that.
<sb0>
_florent_, btw if JTAG doesn't work on Sayma that's likely because of the flaky 1.8V power supply
<sb0>
power cycle the boards with
<sb0>
echo > /dev/ttyACM0
<sb0>
and wait a few seconds
<_florent_>
ok
<sb0>
do NOT attempt to use JTAG while the board is powered off, this messes up the FTDI-chip and then it requires the USB cable to be physically unplugged and replugged
<sb0>
if you want to change the clock to the saymas, there is a SynthNV on /dev/ttyACM_synthnv
<rjo>
sb0: just fyi if anyone digs into that i looked at the schematics around the ftdi and i couldn't find a reason for that behavior. maybe something for alexander as well.
<sb0>
but the synthnv firmware is buggy as well, and it's easy to crash it till it requires a physical USB plug cycle ...