• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: 1 2 [3] 4
31  General Category / General Discussion / Re: Is the window closing on Plug Computing? on: January 15, 2011, 06:32:17 PM
Spam is back.
32  Linux Stuff / Kernel / Re: [HELP] Guruplug bricked after kernel upgrade on: January 13, 2011, 05:02:55 PM
I had the same errors when booting from an external hard disk, before using rootwait in the bootargs.  But, since you are trying to boot from flash, this should not be a problem.

If you have not compiled your own kernel, then the one you are using should already support ubifs.  Your U-boot variables support it:

     x_bootargs_root=ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs
33  General Category / General Discussion / Re: [QUESTION] OS running from a sata drive? on: January 13, 2011, 12:45:00 PM
On this page, the author explains how to copy the file system from (HDD or SD) into flash.  If you install to some device other than the eSata drive, it might be possible to use the same technique.  Of course, you would also have to deal with the identifying the device in U-Boot.

Good Luck.
34  Linux Stuff / Kernel / Re: [HELP] Guruplug bricked after kernel upgrade on: January 13, 2011, 12:38:42 PM
Looks like the root file system has a problem.


"Burn the Rootfs image"
35  Linux Stuff / Kernel / Re: Help with File systems on my Sheva plug running ubuntu on: January 13, 2011, 12:32:41 PM
Would not call myself an expert, but I run all of my file system (Debian) on an external drive.  I have also kept the Ubuntu (upgraded, ubifs) in the flash.  One upgraded kernel is in nand flash and will boot for either distribution with a small change to U-Boot variables.

By the way, my external drive is a 64 GB SSD, power from the Plug.  The Plug's internal power supply was removed and replaced by a 5 V, switching, 2.5 A external unit.

My reasoning for this configuration:
  • The machine is to be used for a specific purpose, not just for testing -- Want it to last as long as possible.
  • Running an operating system in it, the internal nand flash will wear out over time.  The flash is difficult to replace.
  • The external drive can be replaced fairly easily.
  • Using the external drive for all the file system means the flash is only written to when upgrading the kernel or doing maintenance on the external drive.  With this little usage, it should last for years.
  • Using an SSD to reduce power consumption.  It is mounted as ext4, with the discard option, so TRIM will work.  The drive is also formatted as a single unit (/dev/sda not /dev/sda?) to keep the erase blocks aligned.
  • With that set-up, as long as there is plenty of free space on the drive, it should operate efficiently for a long time.
  • The SD card slot remains open to perform backups.
  • Had planned to us an SD Card as the device for the file system.  But with reports of problems and fears of accidentally harming the file system by bumping the card, rather only use the SD when doing maintenance.
36  Linux Stuff / Kernel / Re: [HELP] Guruplug bricked after kernel upgrade on: January 13, 2011, 01:17:31 AM
I read the forums for 4 days.  Tried four different ways to fix my kernel.  We are not the only ones.
37  Linux Stuff / Linux distributions / Re: The alternative Debian install method. on: January 12, 2011, 12:57:54 PM
Hi zwh114,

First thing -- unlike the Slug, the SheevaPlug is almost impossible to permanently brick.  It is just a matter of how much effort it will take to unbrick it.  As long as the bootloader is still intact, all the kernel stuff is relatively easy.  You will probably find you will need to get to know the guts of the Plug much more closely than the Slug.  Often, you may need to modify a list of instructions to fit your needs.

If you look through the wiki and these forum pages (for about 3 to 4 days), you will find about 3 to 4 different ways to upgrade the kernel.  They might all work fine for you, or you might try two or three that will fail before you finally find the one that works.  Patience and determination are needed.

With that said, before you even touch the kernel, I would recommend you first upgrade U-Boot.  The following page worked well and easily for me:


However, I would make one changes to the USB method:

   usb start
   fatload usb 0:1 0x0800000 uboot.bin
   nand erase 0x0 0xa0000
   nand write.e 0x0800000 0x0 0xa0000

Using write.e deals with any error blocks encountered.

About the SheevaPlug_Installer page -- some of the comments about the "latest" SheevaPlugs were in error:
  • Some of the Plugs shipped in the U.S. (maybe elsewhere) in December 2010 (and after?) use the older 1.2 GHz cpu with the new power supplies.  (Still replaced my with an external.)
  • Those same Plugs are using the older VID/PID.
  • The comment about the partition sizes is an error.  In U-Boot, do the command printenv.  If you have something like mtdparts=. . .0x400000@0x100000(uImage). . . , then you have no problem with those sizes.

In fact, it seems like small errors exist in most of the pages and documentation you might find (that happens when the hardware keeps changing).  Another reason to try to understand what the instructions are trying to do before marching into them blindly.

The other page you listed:  http://plugcomputer.org/plugforum/index.php?topic=3680.0   does, in fact, install the 2.6.36 kernel, and modules.  However, it does not change the file system (will leave Ubuntu).

You may save yourself some time if you first decide which distribution you want to use, and where you want your root file system.

I found these two pages to be helpful when deciding how to add a new kernel:


38  General Category / Application ideas and development Q/A / Re: SheevaPlug performance as web server? on: January 12, 2011, 12:24:48 PM
Tomcat is the reference implementation of a Java Web Server.  The performance may have improved since earlier days, but it was slow from the beginning.  I have not tried Resin (from caucho.com) on the Plug yet, but that would be my first try.
39  General Category / General Discussion / Re: Is the window closing on Plug Computing? on: January 11, 2011, 09:49:38 PM
To be fair, it appears that the spam on the wiki site stopped two days ago.  All of the spam pages, and the many bogus users are still there.  It does not seem that the user account creation has been secured, but maybe the Russian and Chinese servers were blocked.  Or, maybe after a week of purging the spam pages as they were created, the spammers realized they were getting no benefit.
40  Linux Stuff / Kernel / Re: where find modules for kernel ? on: January 11, 2011, 09:38:15 PM
A close match, if you want to take your chances with it (no recommendation, just an option):



---  ---  ---

root#  cd

wget  http://sheeva.with-linux.com/sheeva/
md5sum  sheeva-
<< check against http://sheeva.with-linux.com/sheeva/ >>

wget  http://sheeva.with-linux.com/sheeva/
md5sum  sheeva-
<< check against http://sheeva.with-linux.com/sheeva/ >>

tar x -C / --overwrite -vzf sheeva-

cp  sheeva-  /boot

depmod -eF /boot/sheeva-

Can now remove the two files with rm.

41  Linux Stuff / Kernel / Re: [HELP] Guruplug bricked after kernel upgrade on: January 11, 2011, 09:17:48 PM
Check the U-Boot help, to check on the command syntax.  I've always used tftpboot.  It doesn't actually boot, the command only loads the image (some file) from the server into RAM as if it were going to boot.

setenv ipaddr  ?.?.?.?
setenv serverip ?.?.?.?

tftpboot 0x6400000 uImage

( Here, the 0x6400000 could be any address >= 0x800000 )

After that, you may want to check the image header

imi  0x6400000

Finally, you would need to write the image to Flash

nand errase 0x100000 0x400000
nand write.e  0x6400000  0x100000  0x400000

42  General Category / General Discussion / Re: Error with SheevaPlug installer on: January 11, 2011, 11:25:16 AM
In other discussion threads, some have given the opinion that the 64-bit OpenOCD will not work with the 32-bit FTDI drivers.  I do not know if this is correct, but I was never able to get OpenOCD to work on my 64-bit Windows host.

If you have serial access to U-Boot, you may want to consider manually replacing the kernel and file system (from TFTP server, USB or SD Card).  The same method might be used for the older U-Boot version, but with the limits on the earlier version, I would not do it.

This all brings up the question -- Why would you want to return to the factory default?  Are you planning to ship it back?
43  Linux Stuff / Kernel / Re: [HELP] Guruplug bricked after kernel upgrade on: January 11, 2011, 02:40:42 AM
Hey PacoLM,

You're too kind, I don't deserve any credit.  (Big sigh of relief over here, too.)

Okay, so it looks like that original script, with the "nandwrite" managed to trash your kernel.  I still don't know what happened to the U-Boot variables, but we got bootloader, so that makes things much easier.

We have not see the output of the script, but it seems as if it went to completion.  In that mode, the last thing the script does is "try" to reflash the kernel. . .  So, that means the modules for the new kernel were probably installed into your /lib directory.

I agree, the best bet seems to follow part of the instructions at http://www.plugcomputer.org/plugwiki/index.php/Reflashing_images_on_the_GuruPlug , but I would suggest only one part at at time.

1. I would first only "Burn the Kernel image"  and then try to reboot the system.
    (If you can't bring up a TFTP server, the same thing can be done from USB or SD Card.)

1.a. If the boot fails because of the file system, then follow the step "Burn the Rootfs image"

1.b. If the boot fails because of the kernel, then maybe the U-Boot must be updated ( http://www.plugcomputer.org/index.php/us/resources/downloads?func=select&id=15 )

Once the factory kernel is booting again, then we can reconsider options for a kernel upgrade.


There is something in your U-Boot variables and also on that page http://www.plugcomputer.org/plugwiki/index.php/Reflashing_images_on_the_GuruPlug  that is a curiosity.  It is this line:

x_bootcmd_kernel=nand read.e 0x6400000 0x100000 0x400000

This line seems to tell U-Boot to load the kernel from Flash into RAM address 0x6400000.  That is 100 MB from the base of the RAM.
This looks like someone used 0x6400000 as a location for a tftpboot command, and then mistakenly copied it into x_bootcmd_kernel and x_bootcmd.

The first few lines U-Boot prints after a reboot should say something about addresses  0x800000 - 0x0 being saved for U-Boot.  This means that the first 8 MB of memory is reserved for the bootloader, and nothing should be loaded into any address lower than 0x800000.  So, normally, the kernel is loaded into the next available address, 0x800000.

At least one person with a Guruplug is loading the kernel into this address: http://plugcomputer.org/plugforum/index.php?topic=1722.msg11467#msg11467 .

It is theoretically possible that the memory manager can handle empty RAM both below and above the kernel.  But, it would not be surprising if that 92 MB between the boot loader and the kernel was unavailable.

When you get into your system again, shortly after the boot, why don't you try the command   free  from the root login.

If the system memory seems unexpectedly low, it should be easy to fix and just as easy to back out if needed.

(If you change the one 0x6400000, then the second one must also be changed.)
44  Linux Stuff / Kernel / Re: [HELP] Guruplug bricked after kernel upgrade on: January 10, 2011, 06:05:59 PM
Doesn't look like it give a complete solution, but there's another thread on EICE failure:


and, another one where the problem seems to have been resolved:

http://plugcomputer.org/plugforum/index.php?topic=3901.0 . . . "What a frustrating little device."

This seems to be a problem with the Guruplug, any information you could provide on the sequence of events which lead to results might be helpful to others.  (Maybe even give a clue that someone might use to get the "final fix.")
45  Linux Stuff / Kernel / Re: [HELP] Guruplug bricked after kernel upgrade on: January 10, 2011, 12:08:13 PM
Agreeing with Richard's comments.  The runme.sh should, at the least, restore the serial connection and bootloader access.
Pages: 1 2 [3] 4