Yes, that is what I meant. Tom
On Thu, Feb 11, 2010 at 4:36 PM, Jason Manley <[email protected]>wrote: > Tom, I think you mean the kernel is "jiffy": > http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/uImage-jiffy-20091110 > > The recommended Uboot version is still > http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/uboot/uboot-clkfix-20091113.bin > Although > there is a later version in SVN ( > http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/uboot/20091125-r2482-uboot-twt2.bin) > you might find it causes Linux to fail after unpacking the kernel. I do not > recommend you use this one. > > To answer John's question, with the exception of an updated kernel, these > are still the recommended versions. > > Jason > > > On 08 Feb 2010, at 12:41, Tom Downes wrote: > > 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 <[email protected]> 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 >> > >> > >> >> >> >> >> >
