• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: 1 ... 16 17 [18] 19
256  General Category / General Discussion / Re: Running ntpdate at boot on: June 17, 2009, 11:35:52 AM
Are you sure that the Sheeva doesn't have a battery backed-up RTC?  Take a look at:

http://www.globalscaletechnologies.com/t-sheevaplugdetails.aspx#component

This reference seems to indicate it has one.  Also, take a look at /etc/rcS.d/S08hwclockfirst.sh and /etc/rcS.d/S11hwclock.sh, which is where I believe the OS sets its TOD clock from.

FWIW, my Plug seemed to boot up the first time with some reasonable idea of what the time was, and has remained pretty much spot-on after I tweaked it -- I just checked it, and it was w/i 1/3 of a second of network time -- even after many reboots and being unplugged momentarily a couple of times.
257  General Category / General Discussion / Re: Sheevaplug installer - alpha-6 release - Testers needed on: June 16, 2009, 03:04:31 PM
I'm not ready to reflash my Plug yet, but I'd be interested in testing whether it is likely to work (i.e., whether openocd is able to talk to the Plug reliably) when I am indeed ready to do so.  I also know nothing about the openocd command, and am somewhat leery of fiddling with this somewhat dangerous appearing command without knowing what I'm doing.  If I go to the sheevaplug-installer-alpha-6 directory and execute something like:

Code:
../scripts-linux/openocd/openocd -f ../scripts-linux/openocd/config/board/sheevaplug.cfg -s ../scripts-linux/openocd/config/ -c init -c exit

is it likely to tell me if openocd is talking to the JTAG correctly... or will it brick my Plug?  Is there some way I can verify that everything is good to go, without actually committing to reflash my Uboot?
258  General Category / General Discussion / Re: Sheevaplug installer - alpha-6 release - Testers needed on: June 16, 2009, 11:53:12 AM
As others have said, the JTAG is just some hardware that allows direct access to the NAND memory (and perhaps some other functionality).  It's mainly used here to install a new Uboot program.  Think of it as a sophisticated equivalent to toggling in a boot program on the front console of one of your old mainframes.

The installer is like the CD you put in your optical drive to reload Windows on a PC.  Once you have a viable Uboot, you can tell it to boot off of an attached USB thumb drive, and what is there is an environment that installs a pristine Unix on either the NAND or on an SDcard.  You don't really need the JTAG for that function.  Once the installer is done, you can remove the thumb drive and the Plug then boots into whatever Unix you have installed.

Actually, I believe the JTAG board (which includes the SDcard interface IIRC), is part of the development kit for the Plug.  The intent of Marvell/Globalscale was to sell the development kits to allow people to develop their own products, and then sell them thousands of Plugs w/o the development kit (at about 1/2 the $99 price) for them to load with their apps and resell as blackbox plug and play systems.  I wonder how their strategy has worked in practice:  It seems most of us here are experimenters and hobbyists who intend to make use of the actual development kit, including at least the SDcard hardware, to put together one-zie and two-zie systems for ourselves.  Are we their main clientčle, or just one small facet of it?
259  Hardware and U-Boot firmware / Hardware / SD card as root FS on: June 15, 2009, 09:46:07 PM
There is probably a thread for this already, but I can't find it.  In any event, I'm taking my learning curve with the SheevaPlug slowly.  Today I bought an SD card and converted the Plug to using it for its root filesystem.  I followed the instructions found here:

http://www.openplug.org/plugwiki/index.php/SD_Card_As_Root_File_System

First, thanks to the author for compiling this useful article.  Unfortunately, I think there is a small problem with these instructions:  The original bootargs (the one that comes with the Plug) is:

Code:
setenv bootargs console=ttyS0,115200 mtdparts=nand_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) rw root=/dev/mtdblock1 rw ip=10.4.50.4:10.4.50.5:10.4.50.5:255.255.255.0:DB88FXX81:eth0:none

The Wiki suggests that the new bootargs be set as follows:

Code:
setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p1 rw ip=10.4.50.4:10.4.50.5:10.4.50.5:255.255.255.0:DB88FXX81:eth0:none

Specifically, in addition to changing the root device, the mdtparts parameter is dropped as no longer necessary.  However, although this appears to work, when I tried this, I observed the following differences during the boot sequence:

Code:
< 2 cmdlinepart partitions found on MTD device nand_mtd
< Using command line partition definition
< Creating 2 MTD partitions on "nand_mtd":
< 0x00100000-0x00500000 : "uImage"
< 0x00500000-0x20000000 : "rootfs"
---
> Using static partition definition
> Creating 3 MTD partitions on "nand_mtd":
> 0x00000000-0x00100000 : "u-boot"
> 0x00100000-0x00300000 : "uImage"
> 0x00300000-0x20000000 : "root"
...
>  * Loading hardware drivers...    end_request: I/O error, dev mtdblock0, sector 0
> Buffer I/O error on device mtdblock0, logical block 0
> end_request: I/O error, dev mtdblock0, sector 8
> Buffer I/O error on device mtdblock0, logical block 1
> end_request: I/O error, dev mtdblock0, sector 16
> Buffer I/O error on device mtdblock0, logical block 2
> end_request: I/O error, dev mtdblock0, sector 24
> Buffer I/O error on device mtdblock0, logical block 3
> end_request: I/O error, dev mtdblock0, sector 0
> Buffer I/O error on device mtdblock0, logical block 0

Apparently, the kernel still needs to visit the original partition to load some drivers, and the default mapping directs the kernel to the wrong place.  I'm not sure what the effect of these errors are, but I elected to re-add the mtdparts information to the bootargs, and thereafter got a clean boot.

BTW, the Wiki author also ponders why the bootargs_root variable has no effect.  I believe this is likely because it is overridden by the root parameter in the bootargs argument list.
260  Linux Stuff / General Linux questions / Re: Can't su to root on: June 15, 2009, 08:50:35 PM
I also noticed the inability to su to root a few days ago when my SheevaPlug arrived.  A simple:

# chmod 4755 /bin/su

cured it.

Don't have any idea why they shipped it with /bin/su not privileged, but they did.
261  General Category / General Discussion / Re: Recommendable SD(HC) cards/USB sticks for the Sheevaplug on: June 15, 2009, 08:45:24 PM
Just another data point:  I picked up a 16GB class 6 Microcenter branded SD card today at (you guessed it) Microcenter.  Am running the root FS on it now, and intend to add a swap partition to it soon.  YMMV, but so far, it seems to be working.
262  General Category / General Discussion / Re: Can't interrupt autoboot on: June 15, 2009, 08:39:16 PM
I've heard -- vaguely remember someone mentioning it here in this forum -- that this is sometimes a problem with minicom.  Does Fedora have a PuTTY package (something like "yum install putty")?  I don't run a Fedora box here, and don't see the Putty package on CentOS, but Putty is what I use on Ubuntu (and Windows) and it seems to work very well with the SheevaPlug.

Good luck!
263  General Category / General Discussion / Re: Sheevaplug installer - alpha-6 release - Testers needed on: June 15, 2009, 02:52:04 PM
Would it be better that I connect this to a Linux box (I have an Ubuntu install here).  What difference will it make to term to the Sheeva?
Unless you want to play around with loading a Unix environment like cygwin (to execute the scripts) under Windows and compiling your own copy of OpenOCD (to access the JTAG, and even then it's anyone's guess whether it would work), I'd suggest trying it with your Ubuntu.

The following instructions are pretty good:

http://www.openplug.org/plugwiki/index.php/Setting_up_Serial_Console_Under_Linux
264  General Category / General Discussion / Re: Sheevaplug installer - alpha-6 release - Testers needed on: June 15, 2009, 12:08:40 PM
I'm a novice with respect to the Sheeva, too, but here is my assessment:

The micro USB port actually presents two devices to the host computer:  One is the Sheeva console (this is actually the second device -- typically /dev/ttyUSB1 on a Linux host), and the other is a device (/dev/ttyUSB0) that interfaces with the JTAG on the Sheeva.  The runme.sh script uses OpenOCD to talk to the JTAG, and OpenOCD uses the JTAG device.

If you connect the micro USB to a Windows box, the JTAG interface will also be on the Windows box, and you'd have to have a rather complete Unix environment plus an OpenOCD that runs on Windows to execute the runme.sh script successfully.

Bear in mind that the installer attempts to install everything from scratch, including a new pristine Uboot and its environment, and it needs the JTAG interface to do this.  If you only want to install an OS, you can probably accomplish this from a Windows box with the proper install script on a USB drive attached to the Sheeva.  You'd have to break out to the Uboot and set up the proper environment manually.
265  General Category / General Discussion / Re: Sheevaplug installer - alpha-6 release - Testers needed on: June 14, 2009, 09:28:04 PM
Why is it necessary to be root in order to run runme.sh?  Is it only to access the /dev/ttyUSB0 device, or is it needed for some other reason?
266  Hardware and U-Boot firmware / Hardware / Re: Recommend a USB to RS-232 serial port adapter? on: June 14, 2009, 03:17:34 PM
I've been told this one works, although I do not own one nor have I tried it.  (If anyone can confirm, I'd appreciate it, because with luck I'll also be needing to hang a couple serial ports off my Sheevaplug eventually.)

http://www.saelig.com/miva/merchant.mvc?Screen=PROD&Product_Code=U004
267  General Category / General Discussion / Re: External mass storage on USB stick, SD or Ethernet? on: June 14, 2009, 01:00:37 PM
How about allowing multiple selections.  I intend to use all of these options eventually.
268  General Category / General Discussion / Re: Windows version for the Sheevaplug installer on: June 01, 2009, 12:10:17 PM
The poll option I was looking for is "A Linux installer, or both a Linux installer and a Windows installer".  The latter might be useful, but the former is essential.
269  Hardware and U-Boot firmware / Hardware / Re: Unstable USB on: May 28, 2009, 01:14:26 PM
I'd be curious to understand whether the problems you were experiencing that were ameliorated by the powered hub were caused by the hub being able to provide more power to the devices, or whether it was the forcing of the USB connection to USB1 speeds that resolved them.  (If it is the latter, that is not necessarily a good sign.)
270  Hardware and U-Boot firmware / Hardware / Re: Unstable USB on: May 27, 2009, 11:18:45 PM
Super.  Hope your new USB hub proves reliable.  Have you tested it against the microwave and your recalcitrant light yet?

FWIW, a variac is a device -- an autotransformer wound around an iron toroid with a slider that serves as a tap -- which allows you to vary the AC line voltage, from zero to typically around 140V for a nominal 120V feed.  It's what they used to use before the advent of large power solid state devices to control/dim stage lighting, etc., and it can be mighty useful in diagnosing a shorted piece of electronics as well as for analyzing problems having to do with line voltage.
Pages: 1 ... 16 17 [18] 19