There were a number of NTP problems that I was having that got
discussed on the list. To resolve them, you should not use the
uBoot listed here, but instead one labeled "jiffy" in the SVN
repository.
I can't say if that version is otherwise "recommended," but if NTP
is something you need, then the version below won't help you. I
also don't think this result was cross-posted to the list, so now it
is.
Also for posterity, if you need NTP working on the ROACH board it is
very important to have the driftfile enabled in /etc/ntp.conf and to
verify that NTP is modifying it once an hour or more. The driftfile
measures the ppm difference between the frequency your clock is
listed at and actually running at. Mine ends up being on the order
of a few 10s of ppm (not that different from my desktop in
magnitude, but I suspect a little more fluctuations with
temperature). NTP will start with a jitter performance of a 10-20
ms because the clock drift is initially 0, but can eventually get
down to 100 us jitter with your stratum 1 sources. It might get
better than that with time, but I haven't left the board on long
enough.
Tom
On Mon, Feb 8, 2010 at 12:17 PM, John Ford <jf...@nrao.edu> wrote:
> Hi CASPERites with ROACH boards...
Hi all. I wonder if these are still the recommended versions of
everything.
John
>
> Firmware and Software:
> ======================
> You might consider applying the following updates. These versions
are
> considered "stable" and are currently in use by KAT. In order of
> priority:
>
> * Update your base-system Simulink SVN repository:
> There have been numerous library fixes, including DRAM and
10GbE.
> Bus access also changed back in August and you will need the
> corresponding updated CPLD image to maintain compatibility. The
open-
> source XAUI core has a problem and is disabled at the moment. If
using
> 10GbEv2, it will need to use Xilinx's XAUI core for now. Likewise
with
> the XAUI block itself.
>
> * CPLD:
>
http://casper.berkeley.edu/svn/trunk/roach/gw/binaries/roach_cpld/roach_cpld_8_0_1588.jed
> Major change fixed a bus contention issue. To work reliably,
all
> bof files compiled with CASPER SVN libraries later than August 18th
> will require this update. Bof files generated prior to that date are
> incompatible and should be recompiled with an updated SVN checkout.
> This updated CPLD image is also needed to enable MMC/SD card
support.
>
> * Uboot:
>
http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/uboot/uboot-clkfix-20091113.bin
> Various bus fixes and clock speed corrections. Onboard FPU test
> disabled. If you're recompiling uboot from source, it may not work
as
> expected (it hangs after unpacking the Linux kernel). A bug
appears to
> have crept-in the Uboot source-code of SVN head revision. We're
trying
> to track it down, but until then, use this provided binary.
>
> * Linux Kernel:
>
http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/uImage-20091006-mmcfix
> Various fixes, primarily:
> *) SD/MMC support.
> *) Fixes to system clock timekeeping.
> *) Support for RTC and monitoring system health through
> lmsensors and /proc filesystem entries.
> *) Shutdown support (when you press ROACH's power button,
> system will cleanly shutdown, just like your computer).
>
> * Linux Root filesystem:
>
http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/filesystem/filesystem_etch_2009-11-30.tar.bz
> Various fixes, primarily:
> *) added SD/MMC node;
> *) added devicefile for RTC;
> *) added support for monitoring system health through new
> lmsensors (libsensors 3 or 4) and /proc filesystem entries with
> included sensors.conf
> *) and new tcpborphserver (KATCP server) with ability to
open
> more than one instance of a tgtap driver. Please note that there is
> currently a bug in the 10GbE cores that is causing trouble with the
> CPU access to the 10GbE interfaces. Tcpborphserver also does not
> correctly shutdown tgtap instances when reprogramming the FPGA, so
> YMMV. Please note that the tcpborphserver source code in SVN is
> currently outdated. There is a rewrite, tcpborphserver2 on the way.
>
> * Roach monitor (Actel Fusion):
>
http://casper.berkeley.edu/svn/trunk/roach/gw/binaries/roach_monitor/roach_monitor_8_3_1698.stp
> and
>
http://casper.berkeley.edu/svn/trunk/roach/gw/binaries/roach_monitor/roach_monitor_8_3_1698.ufc
> Minor changes to LED flashing/signalling.
>
> Real Time Clock
> ===============
> The hardware RTC is not very accurate. It uses the Actel Fusion to
> keep time while the PPC is powered-down. It doesn't work when AC is
> removed, because then the Fusion loses power and there is no battery
> backup. It's simply there to get you into the right ballpark when
> powering-up a ROACH board so you can use ntpd to correct time at
> startup.
>
>
> Reliability concerns and PPC DRAM issues:
> =========================================
> ROACH boards were shipped in bootstrap configuration H (configured
for
> 500MHz CPU, 166MHz DRAM, 83MHz bus), which we have found to be
> unreliable on some boards. If you are having memory problems or your
> board crashes occasionally, please change to configuration C (533MHz
> CPU, 133MHz RAM, 66MHz bus). This can be done in multiple ways:
> 1) By simply toggling the first "ConfigDIP" switch to "on" or,
> 2) If you don't have local access to the board or it's in a
rack,
> you can also do it remotely by toggling a bit in the onboard
> monitoring chip (Actel Fusion); easiest to use menu-driven python
> frontend
> http://casper.berkeley.edu/svn/trunk/roach/sw/roach_monitor/roach_monitor.py
> and then hard-restart the board.
>
> If you've got a serial port plugged-in, Uboot will report these
speeds
> in its boot messages.
>
> If you are still having trouble, consider replacing the PPC's
standard
> memory module with a registered DIMM, exactly like the one in the
> FPGA's DRAM slot. There is a single clock line on the PPC's DRAM
> interface which was routed poorly (it is out of spec), but is only
> used by unregistered modules so inserting a registered DIMM should
> definitely work.
>
> Jason
>
>
