• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: 1 ... 3 4 [5] 6 7 ... 19
61  Hardware and U-Boot firmware / U-Boot stuff / Re: unsetenv? How do you unset an env in UBoot? on: February 11, 2010, 09:36:33 PM
I think the command to re-establish the default environment is resetenv, possibly followed by a saveenv if you'd like to make that permanent.  However, the default environment is what was compiled into the Uboot command when it was built, and is not necessarily what you need to boot your particular configuration.

There is no unsetenv command.  To unset variablename, use "setenv variablename" without specifying a value for it.
62  Hardware and U-Boot firmware / Hardware / Re: GuruPlug versus SheevaPlug on: February 09, 2010, 08:24:10 PM
Looks like the Globalscale site is back up now, but it also looks like the GuruPlug Display (the one with the HDMI interface in it) just got a tad more expensive, and pre-ordering it no longer gets you a free JTAG!
63  Hardware and U-Boot firmware / U-Boot stuff / Re: Downgrade ext3 to ext2 on: February 05, 2010, 07:25:04 PM
By the way how can I see which partition is ext2 or ext3 from sd card or a usb drive with 2 partitions axt2 and ext3?
For instance, for an SDcard:
Code:
# file -s /dev/mmcblk0p?
64  Linux Stuff / Kernel / Re: 2.6.32.7 new release on: January 30, 2010, 03:38:37 PM
So, until now, you have been running on the kernel and associated file system that was delivered with your Plug?

If so, that is a very old kernel and FS.  Mine came with 2.6.22.18.  I'm not even sure if the newest kernel is compatible with that version of the FS.

The NAND on the Plug is divided into several partitions:  There are separate areas allocated for the Uboot, the Uboot environment, and the kernel.  The rest is normally allocated for the root file system.  The size and start points of each partition are indicated by the 'mdtparts' definition in the Uboot environment.  The kernel defines the /dev/mdt* entries based on this, and the kernel you tried to write was thus written to a specific part of the NAND based on what is defined in mdtparts.  I believe, at some point, the area allocated for the kernel was expanded, due to the new kernels requiring more space, with the extra space taken from the root file system.  This is probably why your new kernel didn't fit.

So, does it boot?  I would suspect not.  If not, my advice:  Grab the latest SheevaPlug Installer and get yourself back to a known-state bootable system.  The Installer will remap the NAND allocations to currently acceptable sizes.  It will also provide a later version of the root file system and a more recent kernel.  Once you do this, you can then upgrade your kernel to the latest one available if you desire.

If you have stuff in your root file system you need to save before running the installer, then you'll have to use an alternate method of booting your Plug -- either from an SDcard, or USB drive, or network boot -- to retrieve it first.  Once you run the Sheeva Installer, everything in the NAND will be overwritten with a fresh copy of the Uboot and OS.

Good luck!
65  Hardware and U-Boot firmware / Hardware / Re: Problem with system on sdhc-card on: January 29, 2010, 07:39:06 PM
running from a sdhc class6 from the very beginning (end of August 09) without any problems. Custom compiled kernel 2.6.30.
What brand? Maybe this is just one brand of cards that is causing people issues..
In my case it is a generic 16GB class 6 card purchased at MicroCenter.  Plugged it into my Plug last May and so far it has just worked, without any apparent problems - at least any problems that can be attributable to the card.
66  Linux Stuff / Kernel / Re: 2.6.32.5 new release on: January 23, 2010, 01:50:39 PM
Quote
The lack of init_nfsd is causing the nfs-kernel-server script in /etc/init.d to fail.  I'd really like to get this working on .32.  Any suggestions?

This would be one reason why that script probably shouldn't be relying on kernel symbols to decide whether nfs server support is running.  I don't have that particular script on my machine so I can't give you the "ideal" way.  The brute force approach would be to modprobe nfsd in the script and comment out the section that verifies the kernel has nfs server support running.
Well, duh, sometimes I don't see the forest for the trees!  Commenting out this check fixed the problem.  Thanks, cbxbiker61!
67  Linux Stuff / Kernel / Re: 2.6.32.5 new release on: January 23, 2010, 12:42:10 PM
FWIW, I just tried upgrading to the 2.6.32 kernel.  I had previously been running on a .31 kernel.  Apparently the .32 line (at least .32.2) does not have kernel support for NFS, which is a showstopper for me:
Code:
* Starting NFS common utilities                                          [ OK ]
* Not starting NFS kernel daemon: no support in current kernel.
(Or am I missing something obvious here?)

In any event, thanks for providing 2.6.31.9, which is running in my plug now.

YMMV.

I just configured an nsf4 server setup on my plug with 2.6.32.2.  Seems to work fine.

I'd have to wonder if your nfsd module was getting loaded in, or before, nfs-common runs.  Not sure why your config would work with .31.9 and not with .32.2.  With regard to nfs, the .32.2 is configured the same way .31.9 is.
This is a continuation of the thread from the 2.6.32.2 topic.  I'm still not able to export NFS file systems under the 2.6.32.5 kernel.  the nfsd module seems to be getting loaded, but the init_nfsd symbol is not appearing in /proc/kallsyms:

2.6.31.9:
Code:
$ lsmod
Module                  Size  Used by
nfsd                  262372  9
exportfs                4400  1 nfsd
dm_crypt               14460  0
dm_mod                 70788  1 dm_crypt
pl2303                 18916  1
usbserial              36752  3 pl2303

$ grep init_nf /proc/kallsyms
c0015e58 t init_nfs_fs
c0016048 T nfs_init_nfspagecache
c0025e0c t __initcall_init_nfs_fs6
bf07f000 t init_nfsd    [nfsd]
$

2.6.32.5:
Code:
$ lsmod
Module                  Size  Used by
nfsd                  238440  2
exportfs                3096  1 nfsd
dm_crypt               11154  0
dm_mod                 55672  1 dm_crypt
pl2303                 14876  1
usbserial              28308  3 pl2303
mv_cesa                 4714  0

$ grep init_nf /proc/kallsyms
c0015718 t init_nfs_fs
c00158ec T nfs_init_nfspagecache
c0025288 t __initcall_init_nfs_fs6
$

The lack of init_nfsd is causing the nfs-kernel-server script in /etc/init.d to fail.  I'd really like to get this working on .32.  Any suggestions?
68  Linux Stuff / General Linux questions / Re: Replicate SD card on: January 13, 2010, 03:40:02 PM
Multiple partitions shouldn't be a showstopper; you just have to deal with them one at a time.  Obviously, you'll have to format the target card so it is laid out similarly to the source card before you begin.

If you copy the partition file-by-file (or drag and drop), you'll have to mount the partitions first.  My SDcard has three partitions and an "ls" shows the following:
Code:
$ ls -l /dev/mmc*
brw-rw---- 1 root disk 179, 0 2010-01-05 01:28 /dev/mmcblk0
brw-rw---- 1 root disk 179, 1 2010-01-05 01:28 /dev/mmcblk0p1
brw-rw---- 1 root disk 179, 2 2010-01-05 01:28 /dev/mmcblk0p2
brw-rw---- 1 root disk 179, 3 2010-01-05 01:28 /dev/mmcblk0p3
$

The first entry refers to the card's partition block.  The next three are the partitions as defined in the partition table.

If you "dd" the raw partition from one card to the other, remember that the target partition must be the same size (or bigger) than the source.
Frankly, I've had good luck reading raw partitions off an SDcard from the Plug.  I've had less success dding to a raw partition, for reasons I have never been fully able to understand.  It appears the writes, which are much slower than the reads, become increasingly backlogged, to the point where the copy grinds to a halt and never succeeds.  But, that was trying to copy one of the partitions to another on the same card.  Try it and see how it works on your system.  YMMV.

Good luck.
69  Linux Stuff / General Linux questions / Re: Replicate SD card on: January 12, 2010, 09:02:43 PM
Unless I misunderstand what you are suggesting, I'd think that the ownership permissions would not be correct after a drag-and-drop, unless perhaps you ran the desktop as root, something I'd guess would not be recommended.
70  Linux Stuff / General Linux questions / Re: Replicate SD card on: January 12, 2010, 12:58:54 PM
FWIW, here's a pointer to a post I wrote some time ago describing how I back up my SD card:

http://plugcomputer.org/plugforum/index.php?topic=865.msg5515#msg5515

After you get the card's contents on your backup box, you can plug an SDcard into it, format it, and populate it.
71  Hardware and U-Boot firmware / Hardware / Re: Powering it On and Off on: January 07, 2010, 05:48:12 PM
It would seem to me you have a few options.  If you are only concerned about a random power failure causing file system damage, you could always log into your Plug remotely and (as root) run "shutdown now".  This would cause the Plug to terminate Linux under controlled conditions and go to a quiescent state, but it will not power down.  Indeed, from this state, you'd then have to power cycle it (or physically hit the internal reset switch) to cause it to come back up.

If you want to actually power down the Plug, you'll have to be more imaginative:  Solutions like X-10 come to mind, but of course that would require another means (secondary to simple ethernet access) of control at the physical location of the Plug.  I understand there are dead-man switches available on the internet that cycle the power if they are not hit by a watchdog reset every so often -- say from a serial port.  Perhaps some variant of something like that could be pressed into service to do what you want.  YMMV.
72  Linux Stuff / Kernel / Re: 2.6.32.2 new release on: January 04, 2010, 11:33:27 PM
FWIW, I just tried upgrading to the 2.6.32 kernel.  I had previously been running on a .31 kernel.  Apparently the .32 line (at least .32.2) does not have kernel support for NFS, which is a showstopper for me:
Code:
* Starting NFS common utilities                                          [ OK ]
* Not starting NFS kernel daemon: no support in current kernel.
(Or am I missing something obvious here?)

In any event, thanks for providing 2.6.31.9, which is running in my plug now.

YMMV.
73  Hardware and U-Boot firmware / U-Boot stuff / Re: new uboot version 3.4.25 on: January 01, 2010, 10:51:51 PM
superpat, your problem sounds similar to what I have experienced on my plug.  I am running the uBoot from the alpha-6 installer (3.4.16).  I'm also running an ext2fs on an SDcard here, and booting from the card.  What I discovered is that the uBoot is unable to read about one out of every ten files on the SDcard's file system.  You can use the ext2ls command to determine if a particular file is readable or not:  The file will show up as zero length when it should not be if uBoot cannot read it.

My workaround is to copy the currently bootable kernels (uImage files) to the root of the FS, and retain the old images until I can verify that the uBoot is happy with the new ones.  Then I boot directly from /uImage.  In the rare event that the uBoot can't load the image, I boot back to one of the old kernels temporarily, and then simply make a new copy of the "bad" image:

Code:
# mv /uImage /uImage.bad
# cp /uImage.bad /uImage

and try booting from the new kernel again, which almost always works.  The readability problem is consistent:  Once the uBoot can successfully load the uImage, it appears to consistently be able to do so.

I'm fairly sure the underlying problem is a bug in the ext2 code in the uBoot, one that I hoped had been corrected in one of the more recent loads, but which apparently has not been.  It may depend on the type of SDcard -- maybe some work better than others -- I don't have enough data points to know.  In any event, I view it as a nuisance item that only comes into play when upgrading kernels, and which may be worked-around by copying the "bad" uImage to another file.

One final comment:  If it is the /boot directory that is itself unreadable, you'll never be able to boot from any uImage therein.  I suspect you could create another directory, copy the contents from the old /boot to the new one, remove the old /boot, and then rename the new one to be /boot.

Good luck!
74  Hardware and U-Boot firmware / U-Boot stuff / Re: [Help] More U-boot sdhc problems. on: December 22, 2009, 07:12:44 PM
Do you want me to try this with bootcmd or real_bootcmd ?
Given the Environment you posted above, I'd add another mmcinit to bootcmd.  I think real_bootcmd is some leftover cruft from when the installer was run.
75  Hardware and U-Boot firmware / U-Boot stuff / Re: [Help] More U-boot sdhc problems. on: December 22, 2009, 09:34:38 AM
I suspect have the same problem on an occasional basis:  The Plug sometimes won't boot after the power has been removed and when I attach to the console to investigate, I'm left at a prompt asking me to provide the root password for maintenance, but with no history.  Unfortunately, if I reboot it again, it then comes up uneventfully.  I've heard rumors that invoking "mmcinit" twice in the boot_cmd sequence will correct this.  Could you try this and let us know if it works?
Pages: 1 ... 3 4 [5] 6 7 ... 19