• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: 1 ... 15 16 [17] 18 19
241  Hardware and U-Boot firmware / Hardware / Re: Plug in SD card - system turns off on: June 27, 2009, 06:58:31 PM
You are plugging the SD card in face down, right?  (The contacts should be facing up as the card is inserted.)

Does another card cause the same symptoms?
242  Linux Stuff / Linux distributions / Re: Reinstallation problem - PLEASE HELP on: June 27, 2009, 06:54:27 PM
It found the thumb drive.  I'd check two things:

(1) Are you sure that all the contents of the installer directory are copied to the root directory of the thumb drive.  (It is incorrect to have an "installer" directory on the thumb drive and the contents in a subdirectory.)

(2) Are you sure the thumb drive is formatted with a FAT32 partition.  Often they come formatted with FAT16, which is claimed not to work, although I haven't tried it.

Keep at it.  I think you are getting close, and at this point the problem must be something simple.
243  Linux Stuff / Linux distributions / Re: Reinstallation problem - PLEASE HELP on: June 27, 2009, 12:46:36 PM
Well, looks like you were successful at installing the new Uboot and environment, but the Ubuntu install somehow failed.  This happened to me, too, and it turned out to be that the "usb start" command didn't seem to work if it had been run before since the Plug was initialized -- you get one shot at it.  What did work for me is to reset the Plug -- at the Marvell>> prompt, either type "reset" or stick a paperclip in the reset hole (which is what I did).  Then, hit a key several times to break to the Marvell>> prompt w/o letting it autoboot.

Next, make sure (1) you've edited the uboot-custom.txt file in the installer directory to reflect your Plug's MAC address, (2) got a pristine FAT32 formatted thumb drive, (3) copied everything in the installer directory to the thumb drive, and (4) plugged the thumb drive directly into the plug.

Now, rerun the installer.

Note: Leave the monitor (PuTTY or the minicom), which should still be at the Marvell>> prompt, up and running while the installer runs.  It will show what's happening during the OS-install phase, and this might prove helpful if it fails again.

Good luck.
244  Linux Stuff / Linux distributions / Re: Reinstallation problem - PLEASE HELP on: June 26, 2009, 11:19:06 PM
You don't really say what other computers you have lying around.  If you have a Linux box, and can get it to talk to your Plug via the mini-USB connector, you might try:

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

after carefully reading the thread:

http://plugcomputer.org/plugforum/index.php?topic=355.0

It's fairly straightforward and will load a very recent version of Ubuntu onto the NAND.

However, since you have a working Uboot, you have other options.  For instance, you might also want to take a look at:

http://computingplugs.com/index.php/Booting_entirely_off_an_external_USB_device

Good luck!
245  General Category / General Discussion / Re: Sheevaplug installer - alpha-6 release - Testers needed on: June 26, 2009, 10:03:27 PM
Addendum:  After copying the filesystem from the pristine Unix I loaded earlier to the SDcard, I changed the Uboot environment from:
Code:
bootargs_nand=ubi.mtd=1 root=ubi0:rootfs rootfstype=ubifs
to
Code:
bootargs_root=root=/dev/mmcblk0p1 rw,relatime
and successfully booted with the SDcard as my root FS.

I don't believe I can access the MTD root partition from Unix while running in this mode, as I don't think the UBI layer is present to allow it (right?), but that is not a problem for me at the current time.  However, if someone knows how to properly set up the UBIFS, while still running on the SDcard as root, I'd appreciate you filling in the details for me.
246  General Category / General Discussion / Re: Sheevaplug installer - alpha-6 release - Testers needed on: June 26, 2009, 08:11:39 PM
I just wanted to report, while the details are still fresh in my mind, that this afternoon I upgraded my Plug using the alpha-6 installer.  It was ultimately successful, and I am delighted with the results, but it took me a couple attempts to succeed, and I'd like to record the pitfalls in the hope that they might be of benefit to someone else.  BTW, thus far, I am similarly delighted to see that this version of the OS seems much fuller-featured.  It does seem to support loopback devices, and it does recognize my USB-to-serial cable -- something I intend to start testing with soon.

On the first attempt, the new Uboot and Uboot-environment installed fine from openocd (whew!), but the procedure errored-out while trying to invoke the installer software on the thumb drive.  After the failure, I got into the new Uboot and tried to manually investigate what was going on.  What I found was that the usb start command was failing -- 1 USB Device(s) found... 0 Storage Device(s) found.  After resetting the Plug, the command would succeed once -- 2 USB Device(s) found... 1 Storage Device(s) found -- and then fail on subsequent invocations until the Plug was again reset.

So, I reset the Plug, broke out of the Uboot boot sequence to the "Marvell>>" prompt, and then ran the installer again.  This time it worked beautifully.

I do have a couple questions:

+ What is the 2nd USB device that the usb start command finds (and I suppose this is the one that it finds all the time, even on its subsequent invocations)?

+ I changed the ethaddr in the uboot-custom.txt of the installer to my MAC address before running the install.  However, I elected not to change orion_nand to orion_mtd.  The way I read the comments, this change should have been made.  I did not do this because I figured if it needed to be changed, it would have been.  Is this comment wrong?

+ I did not change the bootargs_root even though I want to eventually utilize an SDcard for the root file system (and even boot off of this device at some point, now that I have the new Uboot that supports this).  I wasn't really sure what to change this argument to, so I elected to leave it alone.  Perhaps it would be better if there were commented-out bootargs_root examples for the SD card and USB stick options, so that we could simply uncomment the one we desired.

+ Now that I'm up and running on the new OS, how do I convert to using the SDcard?  Can I simply follow the wiki ( http://www.openplug.org/plugwiki/index.php/SD_Card_As_Root_File_System ) and copy the filesystem to the SDcard and then essentially change bootargs_root to "root=/dev/mmcblk0p1", like I did the last time?  (Do I still need to set up the ubifs if I do this, and if so, how do I do this -- perhaps "bootargs_root=ubi.mtd=1 root=/dev/mmcblk0p1"?  What happens if I want to access the mtd partitions while running from the SDcard?  I suppose I need an active ubifs to do so.)

+ Now that I have a Uboot that can boot from the SDcard, if I want to upgrade to the latest 2.6.30 kernel, can I do so by simply copying it onto the SDcard root partition and boot from there, thus bypassing the mtd/NAND entirely (and can someone provide the bootargs to do this)?

That's enough for now.  Again, my thanks to Rabeeh for all his hard work in producing this excellent installer, and thanks in advance to anyone who can give me some advice on the questions I've asked here.
247  Hardware and U-Boot firmware / Hardware / Re: Loose mini-USB connector on: June 26, 2009, 06:49:09 PM
Yes, I have this problem, too.  At first, I thought there was some sort of signaling problem, because my PuTTY session kept dying, but then I noticed it only happened when I did something that disturbed the cable (however slight).  Luckily, I have another mini-USB-cable with a stem on it that is a mm or two longer than the supplied one, and that one seems to fit acceptably.  But, you're right: the mini-USB connector on the plug is recessed enough that not just any cable will work reliably with it.
248  General Category / General Discussion / Re: Help! Sheevaplug inaccessible on: June 25, 2009, 10:38:02 PM
Just a few comments off the top of my head:

+ When I reset my Plug, the two LEDs go out for the duration of the microswitch being depressed, but there is also the tactile feel you talk about.  You might want to verify the LEDs extinguish, though.  BTW, I don't think simply hitting reset kills the PuTTY session on my Intel obx, but I'm not 100% sure.

+ Since you are seeing /dev/ttyUSB1, it appears your Intel box is correctly interpreting the Plug and setting up the devices.  That's good.

+ Since you have not successfully connected via the mini-USB before, you need to be especially careful that everything is set correctly, because you don't know if it is a bad Plug or a configuration problem.  In particular, are you sure the baud rate is correct?  See: http://www.openplug.org/plugwiki/index.php/Setting_up_Serial_Console_Under_Linux

+ Can you communicate with the JTAG?  Download the SheevaPlug Installer.  Then see http://plugcomputer.org/plugforum/index.php?topic=355.msg2569#msg2569 and the following post to see if you can get a response from openocd.  Even with errors, it seemed to handle many of the reset commands for me.

+ If you've tried everything and it's still broke, why not try running the SheevaPlug Installer and see what happens?  What do you have you lose?

Good luck!
249  General Category / General Discussion / Re: Sheevaplug installer - alpha-6 release - Testers needed on: June 24, 2009, 07:19:42 PM
I'm wondering whether there are perhaps some config files, beyond those which were disseminated, that openocd needs in order to interact with our jtag.

Of those of you who were successful at running the installer, I'm curious: Did you have a version of openocd previously loaded on your Intel box?
250  General Category / General Discussion / Re: Sheevaplug installer - alpha-6 release - Testers needed on: June 23, 2009, 08:49:56 PM
Well, oops, perhaps I spoke too soon.  When I removed the final "-c exit" above, openocd remained up and "open".  I was then able to telnet to port 4444 and inject commands (I tried halt, sheevaplug_init, cpu, reset, version, reg) and aside from a running trail of error messages, most of the commands seemed to have the intended effect, although I'm not sure about that the commands like cpu or reg returned anything useful -- most of the registers seemed to be zero or 0xFFFFFFFF.

I'm still a bit reluctant to try reflashing the uboot, though, not knowing whether the observed errors are in fact significant, and as a result, whether I might be left with a bricked plug with no way to unbrick it.

Another oddity:  Even though the /dev/ttyUSB0 device disappeared when openocd was executed, it didn't seem to impede by ability to access the Plug with openocd.  I could even break out of the command and then reinvoke it.  (Is there a graceful way to tell openocd to exit?

Next question: If I do run the alpha-6 installer, I know it reflashes the Uboot and its environment.  After that succeeds, the Uboot's environment is set up to automagically load the new installer off a USB drive, which I suppose installs a release candidate kernel and associated Ubuntu system.  By default, I presume this installation is on the internal NAND, wiping out the load that was there before.  Since the new Uboot allegedly has the capability of booting a kernel directly off an SDcard, is it possible to instruct the installer to do the install to the SDcard as well?  If so, how do I go about this?

Finally, how can I find out what modules are included in this kernel, and what packages are included in the system, before installing them?  In particular, I'd like to know whether the new kernel supports loopback devices, and whether it is capable of mounting writable NTFS file systems.  It would also be nice to know if it has better USB recognition capabilities.  I have a USB-serial cable that my Ubuntu desktop seamlessly supports, but which the default SheevaPlug kernel doesn't seem to know how to handle.

Again, any comments or suggestions? (And, thanks in advance.)
251  General Category / General Discussion / Re: Sheevaplug installer - alpha-6 release - Testers needed on: June 23, 2009, 07:30:09 PM

Well, I've finally gotten around to trying to explore the use of openocd in preparation for perhaps attempting to upgrade my Plug using Rabeeh's alpha-6 installer.  Unfortunately, my pre-test seems to fail much like bpsbr_ernie experienced and documented earlier.  I tried the following command from the alpha-6's uboot subdirectory (as it would be executed had it been invoked from runme.sh, but w/o the actual commands to reflash the uboot):
Code:
../scripts-linux/openocd/openocd -f ../scripts-linux/openocd/config/board/sheevaplug.cfg -s ../scripts-linux/openocd/config/ -c init -c exit
And here are the results:
Code:
root@kevey:/home/res/SheevaPlug/sheevaplug-installer-alpha-6/uboot# ../scripts-linux/openocd/openocd -f ../scripts-linux/openocd/config/board/sheevaplug.cfg -s ../scripts-linux/openocd/config/ -c init -c exit
Open On-Chip Debugger 0.2.0-in-development (2009-05-17-10:32) svn:1800M


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
2000 kHz
dcc downloads are enabled
Error: JTAG communication failure, check connection, JTAG interface, target power etc.
Error: trying to validate configured JTAG chain anyway...
Error: Could not validate JTAG scan chain, IR mismatch, scan returned 0x00. tap=feroceon.cpu pos=0 expected 0x1 got 0
Warn : Could not validate JTAG chain, continuing anyway...
Warn : value captured during scan didn't pass the requested check:
Warn : captured: 0x00 check_value: 0x01 check_mask: 0x0F
Warn : no telnet port specified, using default port 4444
Warn : no gdb port specified, using default port 3333
Warn : no tcl port specified, using default port 6666
root@kevey:/home/res/SheevaPlug/sheevaplug-installer-alpha-6/uboot# echo $?
0
root@kevey:/home/res/SheevaPlug/sheevaplug-installer-alpha-6/uboot#
BTW, after executing this, the /dev/ttyUSB0 device is no longer present, and I have to unplug/replug the mini-USB to get it back.

This doesn't look like it is working correctly to me.  Any ideas?
252  General Category / General Discussion / Re: Recommendable SD(HC) cards/USB sticks for the Sheevaplug on: June 23, 2009, 06:13:11 PM
You did insert the card face-down -- top of card oriented towards the Plug's electrical plug and contacts facing you -- right?  (It fooled me at first.)
253  Hardware and U-Boot firmware / Hardware / Re: SheevaPlug v2 - Hardware Requests on: June 23, 2009, 08:03:31 AM
A couple of us SheevaPlug owners were discussing the Plug over lunch yesterday, and I made the same comment -- that a Gig of memory would be nice.  One of the other guys pointed out that he thought the Marvel chip only brought out 30 bits of address:  30 bits == 1 GB of addressable memory, so with 1/2 GB of RAM and 1/2 GB of NAND, they appear to be maxed out.

(E-)Sata would be nice, though.
254  General Category / General Discussion / Re: Help! Sheevaplug inaccessible on: June 21, 2009, 08:51:12 PM
Have you tried resetting the Plug?  There is a reset button recessed behind a small hole on the side of the unit opposite the SDcard slot.  With the unit powered on, stick a toothpick or paperclip in the hole and depress the reset button for a second.  This has worked for me.

(You also don't say whether you've ever successfully talked to the Plug in the past over the mini-USB cable, so it's hard to know if the problem is with the Plug or the connectivity to it.  Are you using a Linux or Windows box to connect?  If Linux, are you seeing /dev/ttyUSB0 and /dev/ttyUSB1?  If so, is Putty successful in connecting to /dev/ttyUSB1, but just nothing coming out?)
255  General Category / General Discussion / Re: Saving rootfs changes on: June 21, 2009, 07:50:19 PM
I used the following technique to get the root filesystem off the sheevaplug, although I am operating with an SDcard rather than the internal NAND, and I frankly must admit I haven't tried this with the NAND.  I used 'nc':  On a remote linux box on my local LAN, (let's say it's at address 192.168.0.100) I ran the command
Code:
nc -l -p 2345 >mmcblk0p1
Then on the SheevaPlug, I ran the command
Code:
nc 192.168.0.100 2345 </dev/mmcblk0p1
This transferred the entire root fs image to the remote box, and it did it rather speedily at that.  I could then "mount -o loop mmcblk0p1 /mnt/sheevaroot", make any changes (or do a quick tar+gzip), "umount /mnt/sheevaroot", and have a fs image for backup or to put wherever I wanted for installation elsewhere.  The other advantage to this approach is that you get the true contents of the root fs, including the files that underlie the mount points, instead of all the various /proc and /var temp files from the pseudo-fs's that are overlayed on it.   YMMV, but you might try substituting /dev/mtdblock1 for /dev/mmcblk0p1.  Of course, what you'll get will be a jffs2 image instead of the (in my case) ext2.

I will mention that I also tried it the other way, too -- dd'ing and nc'ing an ext2 fs to a spare partition on my SDcard -- and it failed miserably.  I don't know why, but it quickly ground to a halt, making essentially no progress after the first few 100k.

Pages: 1 ... 15 16 [17] 18 19