This works, i'm updating the wiki.

On Wed, Feb 17, 2010 at 6:35 AM, Jason Manley <jason_man...@hotmail.com>wrote:

> The new filesystem has an explicit remount read-only line in rcSimple. To
> quote zhiwei liu from an earlier email:
>
> To compare to the old filesystem, the /etc/rcSimple file in the new
> filesystem has a line like:
>
> mount -n -o remount, ro, noatime /
>
> I think that is the problem.  If you mark or delete this line, it will
> mount the filesystem writeable.
>
> Try this and let me know if you're still having trouble.
>
> Jason
>
>
> On 17 Feb 2010, at 06:15, Griffin Foster wrote:
>
>  I've been setting up ROACH boards using the new recommended linux kernel
>> and filesystem but I seem to be getting a problem about the NFS mount being
>> read only. My export file is set to rw and when I am using
>> filesystem_etch_2009_08_14.tar.bz2 with the same setting the mount works as
>> rw. I thought it might be some thing to do with the warning I get on the
>> serial, "warning: can't open /etc/mtab: No such file or directory" but both
>> of the filesystem have that same warning. The mtab for the etch_2009-11-30
>> has /dev/root / nfs ro,... while etch_2009_08_14 has /dev/root / nfs rw,...
>> . I don't know how this /proc/mount file is created, does anyone have an
>> idea about whats going on? Could this be caused by CPLD or uBoot not being
>> the latest versions?
>>
>> -Griffin
>>
>> On Dec 1, 2009, at 7:33 AM, Jason Manley wrote:
>>
>>  Hi CASPERites with ROACH boards...
>>>
>>> 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
>>>
>>>
>>>
>>
>>
>>
>
>

Reply via email to