- 03 Jul, 2017 4 commits
-
-
Grzegorz Daniluk authored
-
Grzegorz Daniluk authored
-
Adam Wujek authored
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>
-
Grzegorz Daniluk authored
-
- 30 Jun, 2017 9 commits
-
-
Grzegorz Daniluk authored
-
Grzegorz Daniluk authored
-
Adam Wujek authored
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>
-
Alessandro Rubini authored
This introduces "mode abscal", that forces a gm-lookalike mode in the node, to send sync once per second. See "absolute calibration" document by Peter Jansweijer from nikhef. The option is Kconfig'd, but on by default. Signed-off-by: Alessandro Rubini <rubini@gnudd.com> Conflicts: ppsi
-
Alessandro Rubini authored
both "sec" and "hwrs->sec" are 64 bits wide: don't forcibly trim to 31 bit the value being assigned. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
This is a logic &, not an aritmetic one. So "&&" not "&". The change has no effect, because the two operands are verified to always be 0 or 1, but what we had was conceptually wrong and forced me to verify. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Adam Wujek authored
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>
-
Grzegorz Daniluk authored
-
Grzegorz Daniluk authored
-
- 27 Jun, 2017 2 commits
-
-
Grzegorz Daniluk authored
-
Grzegorz Daniluk authored
-
- 26 Jun, 2017 10 commits
-
-
Adam Wujek authored
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>
-
Grzegorz Daniluk authored
-
Maciej Lipinski authored
-
Maciej Lipinski authored
-
Maciej Lipinski authored
-
Maciej Lipinski authored
the configuration written to WB registers using commands in the wr-streamers tools is used to override the default configuration set with generics. one can enable/disable this overriding, meaning that the original default configuration can be effective again. this functions enables/disables overriding.
-
Maciej Lipinski authored
-
Maciej Lipinski authored
- for the qtag configuration to be effective, an appropriate override bit needs to be set, this was missing, fixed - the function was first enabling the qtag-ing and then configuring it, this is not a good behavior, it is better to be enabled later (when the configuration is set, otherwise it will start sending frames tagged with some random config), fixed
-
Maciej Lipinski authored
these commands are not critical for the current release, the fix will take some time, the codebase is good. let's make it work later
-
Adam Wujek authored
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>
-
- 23 Jun, 2017 1 commit
-
-
Grzegorz Daniluk authored
-
- 22 Jun, 2017 14 commits
-
-
Grzegorz Daniluk authored
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
This commit adds a tool to send out, through ethernet, a complete log of DAC values for the main oscillator. It allows to see if there are oscillations (and there currently are) and what happens when tracking is lost and recovered. To activate the feature * add CONFIG_DAC_LOG (depends on CONFIG_DEVELOPER) * activate on the console: "daclog <ipaddr> <macaddr>" * collect data on your target host netcat -u -l -p 1050 | od -An -t u2 -v -w2 --endian=big > daclog.txt * stop it when done, on the console: "daclog off" Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Under frame loss, most track-lost are just because of ptp timeouts. But since the underlying pll is unaffected, and the RTT is almost constant, we can tell in the logs whether the lost/resync was actually a time jump or not. This is what happens with moderate frame loss (fhe first track-lost is real, due to a ptp restart, the following ones are not and max delta between calculated setpoint and current setpoint is reported): Jan 1 00:00:02 192.168.128.84 (00: 26:7b:00:04:27) Node up since 1 seconds Jun 12 14:16:06 192.168.128.84 Tracking after 19.141 s Jun 12 14:17:14 192.168.128.84 Lost track Jun 12 14:17:20 192.168.128.84 2-th re-rtrack after 6.119 s Jun 12 14:17:43 192.168.128.84 Lost track Jun 12 14:17:46 192.168.128.84 3-th re-rtrack after 3.287 s (max delta 2 ps) Jun 12 14:18:48 192.168.128.84 Lost track Jun 12 14:19:00 192.168.128.84 4-th re-rtrack after 12.388 s (max delta 0 ps) Jun 12 14:19:14 192.168.128.84 Lost track Jun 12 14:19:18 192.168.128.84 5-th re-rtrack after 4.126 s (max delta 3 ps) Jun 12 14:19:25 192.168.128.84 Lost track Jun 12 14:19:31 192.168.128.84 6-th re-rtrack after 6.022 s (max delta 4 ps) Jun 12 14:19:36 192.168.128.84 Lost track Jun 12 14:19:38 192.168.128.84 7-th re-rtrack after 2.229 s (max delta 1 ps) Jun 12 14:19:52 192.168.128.84 Lost track Jun 12 14:20:03 192.168.128.84 8-th re-rtrack after 10.997 s (max delta 1 ps) Jun 12 14:21:02 192.168.128.84 Lost track Jun 12 14:21:21 192.168.128.84 9-th re-rtrack after 18.906 s (max delta 2 ps) Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
This is my own fault introduced here: 765443c7 udp: bugfix for checksum generation It made no harm, because all send frames were oversized, but I'm now using fixed-size buffers, and this overwrites the own IP address thus corrupting the checksum and so on. Pity me. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-