> 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 > >
