I spits a number of warnings, and we are not simulating snmp anyways.
Better avoiding the warning than fixing

(thanks randconfig)

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Otherwise we get this:

  ppsi/arch-unix/unix-startup.c:35: multiple definition of `main'
  wrc_main_sim.c:193: first defined here

(thanks randconfig)

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

If we select a host build, we'll have the same assert from
ppsi::arch-unix, becauseI added a non-libc assert to ppsi while adding
it to wrpc-sw.  But ppsi doesn't build its own asser for arch-wrpc, so
the only proble is with host builds.

(thanks randconfig)

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This simplifies, in a way.  Otherwise, we'd need to make most
developer options depend on WR_NODE too.

(thanks randconfig)

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Otherwise we have build errors.

   wrc_main.c:172: undefined reference to `uart_init_hw'
   wrc_main.c:172: undefined reference to `uart_read_byte'
   ppsi/arch-wrpc/wrc_ptp_ppsi.c:103: undefined reference to `uart_init_hw'

If we want to make it optional, we can revert this commit
(thanks randconfig)

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This also include a ppsi commit. We must have both at the same time,
because each uses a feature of the other, to link sw-uart at build time.

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

We'd miss some symbols in wrs, besides missing the shell

   shell/cmd_diag.c:32:30: error: 'DIAG_RO_BANK' undeclared

(thanks randconfig)

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

We can't run such stuff in the switch:

(thanks randconfig)

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Otherwise, if we have syslog we fail building:

  lib/syslog.c:197:23: error: 'CONFIG_TEMP_HIGH_THRESHOLD' undeclared

(thanks randconfig)

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Keep assert enabled only for devel_build_test_defconfig

Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

We have experienced the problem when re-loading LM32 firmware many times when
WRPC synchronizes to WRS v4.2 (the latest WRS firmware is v5.0). Sometimes after
reprogramming LM32 WRS was reporting a bitslide value the same as for the
previously established link. This was resulting in wrong synchronization and
1-PPS skew off by the difference between the actual and reported WRS bitslide.
This problem is not new with this WRPC v4.0, we've managed to reproduce is also
with WRPC v3.0 and WRS v4.2. Testing WRPC v4.0 with WRS v5.0 did not reveal this
problem.

With this workaround we wait longer before re-enabling the link so that WRS v4.2
for sure notices link down and re-measures the bitslide.

Adam Wujek authored 8 years ago and Grzegorz Daniluk committed 8 years ago

Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Adam Wujek authored 8 years ago and Grzegorz Daniluk committed 8 years ago

Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Adam Wujek authored 8 years ago and Grzegorz Daniluk committed 8 years ago

Update dump-info accordingly

Signed-off-by: Adam Wujek <adam.wujek@cern.ch>