> Yes, that is what I meant. Thanks for the information, guys. It explains why I didn't see a uboot-jiffy file!
I've borrowed a wiggler from socorro, and hopefully will be able to debug my bricked roach. John > > 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 >>> > >>> > >>> >>> >>> >>> >>> >> >
