<GitHub88>
[smoltcp] dlrobertson commented on issue #241: @squidarth since you've already done some work on the neighbor cache, this could be a good follow-up issue. It will be a good bit more work as the use of cache entries in `EthernetInterface` will need to be updated, but I think it is a reasonable next issue to work on, once #234 is merged. https://github.com/m-labs/smoltcp/issues/241#issuecomment-398254380
rohitksingh_wor1 has quit [Ping timeout: 245 seconds]
rohitksingh_wor1 has joined #m-labs
<sb0>
of course, the vivado/ultrascale trash is giving me BS for clocking the JESD transceivers from the Si5324
<sb0>
sigh
<sb0>
_florent_, how do I clock the transceivers with one clock and the rest of the fabric with another (both from the same oscillator) in the JESD core?
rohitksingh_work has quit [Ping timeout: 256 seconds]
<sb0>
_florent_, is it sufficient to give a refclk with one clock and a jesd clock domain with the other? do the elastic buffers take care of that?
<sb0>
"Since the IBUFDS connects to the GT in intelligent pin mode..."
<sb0>
they call it "intelligent pin mode"
<_florent_>
sb0: yes, if the clock you are using before the EBs is from the same oscillator than the clocks used for the transceiver, the elastic buffer will handle that
<sb0>
so I can provide any refclk and any jesd clock domains, as long as they're from the same oscillator?
<sb0>
to be explicit, I want to keep the current refclk from the hmc7043 (since vivado breaks otherwise) to clock the transceiver, and use the existing rtio clock domain (coming from the si5234) to drive the jesd domain
<_florent_>
in the current design, we use the clock from the hmc7043 as refclk to the transceiver, and also as clock for the core logic
<GitHub106>
[smoltcp] whitequark commented on issue #242: I'm not extremely enthusiastic about clippy and I believe that blindly following its suggestions can easily degrade code quality. r=me on every PR addressing its lints. https://github.com/m-labs/smoltcp/issues/242#issuecomment-398410312
<GitHub153>
[smoltcp] whitequark commented on issue #244: The `update` method is there so that any invariants on the internal `ManagedMap` can be enforced. But maybe we should not expose it at all, rather have an `add_route` method and such. https://github.com/m-labs/smoltcp/pull/244#issuecomment-398418763
<GitHub63>
[smoltcp] whitequark commented on issue #244: There is--if you just give away a `&mut` there is no way to maintain any internal invariants. There aren't any right now but that is likely wrong. https://github.com/m-labs/smoltcp/pull/244#issuecomment-398426745
<GitHub17>
[smoltcp] whitequark commented on issue #244: Not every route is legal. For example, no multicast addresses should be added to the route table. This isn't checked currently, but should be, and it can't be checked with `get_mut`. https://github.com/m-labs/smoltcp/pull/244#issuecomment-398429415
rohitksingh has quit [Read error: Connection reset by peer]
hartytp has joined #m-labs
<hartytp>
marmelada: did you get a chance to look at Sayma PI with SAWG?
rohitksingh has joined #m-labs
<hartytp>
sb0: did you see try commenting out the serwb + RTM init on Sayma?
<hartytp>
if so, does that still crash?
<hartytp>
it would be interesting to see if we can reproduce the crashes with the RTM physically disconnected (reduces the number of places for issues to hide)
<sb0>
hartytp, no, feel free to try
<hartytp>
I'm building gw to do that atm
<hartytp>
just wanted to check that I wasn't missing something
<sb0>
I don't think we can reproduce with the rtm disconnected, unfortunately; though if you want to try that, your best bet is the reboot loops
<hartytp>
why not?
<sb0>
the crash kernel needs a lot of things and resists attempts at minimizing it (the crashes disappear of you change the slightest thing)
<sb0>
*if
<hartytp>
hmmm o
<hartytp>
ok
<hartytp>
so, are you *sure* this is not a gw/fw bug?
<sb0>
so, for the reboot loops, what you can try is jesd_unreset() and physically disconnect the rtm
<sb0>
but first, see if you can reproduce my reboot loop results
<hartytp>
based on how quickly rjo was able to find a number of issues with artiq I wonder if the review process has been sufficient
<sb0>
there are also a lot of issues with the hardware
<hartytp>
some
<hartytp>
but there is no evidence so far that this is due to one
<sb0>
well, things basically break when a lot of things are running in the FPGA, that looks like PI to me
<hartytp>
or a missing timing constraint
<hartytp>
or one of a few other things
<hartytp>
I don't really understand the project management structure here
<sb0>
the main CPU crashing when a clock buffer in an unrelated clock domain is enabled doesn't look like timing
<hartytp>
which clock buffer was that again?
<sb0>
the jesd_unreset()
<hartytp>
are you sure you fixed the HMC7043 reset line?
<hartytp>
i.e. does keeping it high in fw kill the DACs?
<sb0>
no, and there can be other hardware problems, so this is why I asked for reproductions of those results on other boards
<hartytp>
I did that
<hartytp>
or, did I not do all the tests you wanted?