• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1] 2
1  Linux Stuff / Linux distributions / Re: Saving / copying RFS (to move to another plug) on: September 15, 2010, 03:43:55 PM
Thanks, I understand.  cpio / tar it is!

Eric.
2  Linux Stuff / Linux distributions / Saving / copying RFS (to move to another plug) on: September 09, 2010, 03:40:22 PM
Okay, I'm thinking I know how to do this, but then again, maybe not Smiley

I have a rootfs on flash that I like (this is a guruplug, fwiw).  I now want to install it on other plugs.  How do I copy it off?

I did a nanddump -f rootfs.ubi.img /dev/mtd2 (to a USB stick), which created a ~512MB file.  But the original rootfs image was on the order of ~275MB, and I didn't add more than a few dozen MB.  I guess I don't mind copying the whole thing and flashing it to the new plug, but is there a way I can tell how big the current UBI fs is?  And just nanddump that?

Any help appreciated, I'm afraid of bricking another plug....
3  Linux Stuff / Kernel / Re: sheevaplug USB mount fails periodically (debian) on: September 09, 2010, 11:40:06 AM
That looks like either an actual disk failure (fsck'd it lately?) or perhaps it's spinning down and won't spin back up.  Some USB drives (notably the Seagate 1TB externals) are set to automatically spin down, and Linux doesn't know about it.  There are workarounds using sdparm.

Perhaps using sdparm periodically to check disk status would be useful?

4  Linux Stuff / Kernel / libertas driver -- utterly broken? on: September 08, 2010, 01:09:02 PM
I'm cross-posting this from another forum topic to see if anyone has a comment here.

There seems to be substantial evidence that the libertas/libertas_sdio driver is utterly broken, and crashes the kernel after a few minutes:

Read: http://www.newit.co.uk/forum/index.php?topic=455.0

I'm having exactly the same problems.  Random lockups and crashes of kernel code (not specifically from the driver, however) ONLY when I'm using wifi.  I have no, zero NONE problems using wired Ethernet, or using a rtl8187-based USB wifi dongle (as long as the libertas driver is unloaded).

I have both a 2.6.33 kernel as patched / built according to the instructions at:

http://plugcomputer.org/plugwiki/index.php/Re-building_the_kernel_and_U-Boot

as well as the original, as-shipped-from-Globalscale guru kernel (2.6.31 I think?), and they both exhibit the same problems when running as a wifi client.

Do other people have these problems?  Is anyone able to use wifi on the guru reliably?  AFAICT, wifi is utterly useless on the guru...
5  Hardware and U-Boot firmware / Hardware / Guruplug Wifi -- utterly broken? on: September 03, 2010, 09:48:41 AM
I know there are heat problems with the Guru.  But even without them, is the wifi driver / chip utterly broken?

Read: http://www.newit.co.uk/forum/index.php?topic=455.0

I'm having exactly the same problems.  Random lockups and crashes of kernel code (not specifically from the driver, however) ONLY when I'm using wifi.

Presumably the 8688 Marvell chip is widely-used enough that this isn't the problem.  Which means the driver is?

I have no, zero NONE problems using wired Ethernet, even on my very warm guru.

Anyone else?
6  Linux Stuff / Kernel / Re: GuruPlug, wireless: uap8xxx kernel module and the uaputl setup utility on: September 01, 2010, 04:35:50 PM
Still no luck with this? I think many people might need it, and it's not a crucial piece of software, most probably its release was just forgotten... no news from globalscale or marvell?

I'd like source out of principle, but the executable works across multiple kernels, so it doesn't seem like a big deal.
7  Linux Stuff / General Linux questions / Guruplug -- switch TO AP mode from client mode (wifi) on: August 26, 2010, 02:16:02 PM
Has anyone been able to switch the guruplug from wifi client mode <i>to</i> AP mode without rebooting?  I've tried many combinations of rmmod uap8xxx, moving firmware, replacing libertas_sdio modules, etc.

I can, of course, go into client mode no problem (and stay there on reboot).  But going into AP mode thus far requires a reboot (and removal of the firmware from /lib/firmware).

Anyone else even try this?

Eric.
8  Linux Stuff / Kernel / Re: Can't boot newly-built 2.6.22.18 kernel -- going quite insane [SOLVED!?] on: February 25, 2010, 10:16:36 PM
Okay, I got the 2.6.31.12 kernel.org kernel to work with eth0, somehow magically.

Sound and ethernet!  Yay!

9  Linux Stuff / Kernel / Re: Can't boot newly-built 2.6.22.18 kernel -- going quite insane. on: February 25, 2010, 09:26:17 PM
Yes, I've tried mainlineLinux no, and setenv arcNumber.  Fails at the same point.

Nothing else obvious there then?

I don't know why sometimes I'm supposed to load the kernel at 0x2000000 and other times at 0x800000; this makes no sense to me.  Still having trouble understanding u-boot and exactly how the kernel loads (obviously).

And yes, mundhra, I put the wrong mtd directive in there, should be orion_mtd -- but it never gets that far.

10  Linux Stuff / Kernel / Can't boot newly-built 2.6.22.18 kernel -- going quite insane [SOLVED!?] on: February 25, 2010, 04:32:58 PM
Okay.  I'm really tearing my hair out here.  Here's my saga.

I need a kernel with USB sound, and a few other things (tried cbxbiker61's, no joy w/USB sound despite modules loaded).  I decided to start with a fresh, kernel.org kernel: 2.6.31.12.  I got it running on the sheeva, but for some reason the ethernet driver finds TWO devices, neither of which are able to connect, even though they appear configured (dhcp fails, doesn't work with static IP). However, USB sound works great.  Couldn't find a fix for this, so went to the 2.6.22.18 kernel tree that I had from an OpenRD system, and built that.

I swear on my mother's grave that I got this thing to boot once, but now I can't get it past "Uncompressing Linux...." no matter how many uboot setenv's I try.  Here's my printenv:


Marvell>> printenv
baudrate=115200
loads_echo=0
ipaddr=10.4.50.165
rootpath=/mnt/ARM_FS/
netmask=255.255.255.0
console=a0000
e=ttyS0,115200 mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x1ff00000@0x100000(root)
CASset=min
MALLOC_len=1
ethprime=egiga0
bootargs_end=:::DB88FXX81:eth0:none
image_name=uImage
standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig);
ethmtu=1500
mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
usb0Mode=host
yuk_ethaddr=00:00:00:EE:51:81
nandEcc=1bit
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
autoload=no
ethact=egiga0
bootargs_root=ubi.mtd=1 root=ubi0:rootfs rootfstype=ubifs
mtdpartitions=mtdparts=orion_nand:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs)
ethaddr=00:50:43:01:c1:e6
real_bootcmd=setenv bootargs $(bootargs_console) $(mtdpartitions) $(bootargs_root); nand read.e 0x00800000 0x00100000 0x00400000; bootm 0x00800000
bootargs_console=console=ttyS0,115200
recover1=setenv mainlineLinux yes; setenv arcNumber 2097; setenv bootcmd run recover2; saveenv; reset
recover2=run recover3; setenv bootcmd $(real_bootcmd); saveenv; setenv bootargs $(bootargs_console) $(mtdpartitions) root=/dev/ram0 rw ramdisk=0x0110
recover3=run recover4; nand erase clean 0x00100000 0x00400000; nand write.e 0x00800000 0x00100000 0x00400000
recover4=usb start; fatload usb 0 0x00800000 uImage; fatload usb 0 0x01100000 initrd
arcNumber=2097
filesize=32D62A
bootcmd=setenv bootargs $(bootargs_console) $(mtdpartitions) $(bootargs_root); nand read.e 0x00800000 0x00100000 0x00400000; bootm 0x00800000
serverip=192.168.168.140
bootfile=uImage
stdin=serial
stdout=serial
stderr=serial
nandEnvBase=a0000
mainlineLinux=yes
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
netbsd_en=no
vxworks_en=no
bootdelay=3
disaMvPnp=no
enaAutoRecovery=yes
pcieTune=no

Environment size: 2086/131068 bytes


Then I do a:

setenv bootargs 'console=ttyS0,115200 mtdparts=orion_nand:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) rw ubi.mtd=1 root=ubi0:rootfs rootfstype=ubifs'


which is fine, this is what I use to boot all the other (working) kernels.  Then I give it 'dhcp' to do a tftp boot, then:

Marvell>> tftp 0x2000000
Using egiga0 device
TFTP from server 192.168.168.140; our IP address is 192.168.168.43
Filename 'uImage'.
Load address: 0x2000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################
done
Bytes transferred = 2082676 (1fc774 hex)
Marvell>> bootm 0x2000000
## Booting image at 02000000 ...
   Image Name:   Linux-2.6.22.18
   Created:      2010-02-25  21:36:54 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2082612 Bytes =  2 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux...................(hangs)


Then I thought there was something wrong with the load address (although it works for the 2.6.31.18 kernel I built), so I changed it:

Marvell>> tftp 0x800000
Using egiga0 device
TFTP from server 192.168.168.140; our IP address is 192.168.168.43
Filename 'uImage'.
Load address: 0x800000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################
done
Bytes transferred = 2082676 (1fc774 hex)
Marvell>> bootm 0x800000
## Booting image at 00800000 ...
   Image Name:   Linux-2.6.22.18
   Created:      2010-02-25  21:36:54 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2082612 Bytes =  2 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux...................(still hangs)


So now I'm completely nuts.

What am I doing wrong?  Am I really imagining that I booted this kernel at least once?
11  Linux Stuff / Kernel / Re: Problems with ethernet on 2.6.32 (mainline) kernel on: February 25, 2010, 12:05:57 PM
correction, my kernel has the same problem on the openrd board, oops.
12  Linux Stuff / Kernel / Problems with ethernet on 2.6.32 (mainline) kernel on: February 25, 2010, 11:57:06 AM
I'm having trouble getting the ethernet iface to work with the 2.6.32.12 (kernel.org) kernel.

The interface comes up, ifconfig sees it, I can set an static IP address, everything seems great -- except no actual connection.  DHCP times out.

There's a curious message from the kernel when booting:
MV-643xx 10/100/1000 ethernet driver version 1.4
mv643xx_eth smi: probed
net eth0: port 0 with MAC address 00:50:43:01:c1:e6
net eth1: port 0 with MAC address 00:00:00:00:00:00

And sure enough, ifconfig eth1 shows an eth1!  Dunno why.  I also note that the mv643xx_eth.c driver in this kernel is substantially different than one from 2.6.22 through 30 (and of course, it won't go backwards and compile).

I've also got an OpenRD board here, and my kernel runs fine there (finds both ethernet ifaces and dhcp works with both).

Wha?  Anybody got a clue?
13  General Category / General Discussion / Re: FTDI driver / Linux -- how to keep ttyUSB0 persistent when sheeva is repowered? on: February 24, 2010, 03:59:36 PM
Ouch!

Thanks!

14  General Category / General Discussion / FTDI driver / Linux -- how to keep ttyUSB0 persistent when sheeva is repowered? on: February 24, 2010, 01:04:03 PM
I know this subject has been beaten to death here, but I can't seem to find this specific answer.

I have no trouble connecting to sheeva with ttyUSB0, but when I need to reboot the plug, I have to pull the cord -- and away goes ttyUSB0!  It often doesn't come back fast enough to catch the next boot.

This is some udev thing, and I don't know how to deal with it.  What I'd like is to manually load the ftdi_sio driver into the kernel (I already do), have a hard /dev entry for ttyUSB0, and have udev ignore this particular device.

Anybody know how to do this, or have another solution?

Failing that, does the sheeva have an internal reset switch so I can keep it powered up while rebooting?
15  Linux Stuff / General Linux questions / NFS boot - works about 1 out of 3 tries, anyone seen this? on: February 23, 2010, 09:32:47 AM
I've been booting an NFS-mounted Fedora for some time, but it fails about every other boot.  It's very weird: It starts the boot sequence (and, therefore, has already attached the NFS mount), but fails somewhere around "udev settle" in the start_udev script.  It just hangs there, not going forward.  Then about 1 of 3 times, it just runs through it fine!

When I try and boot 9.04/Jaunty, it fails in a similar place, usually spitting out a message about not reaching the nfs server.  I can't get it to boot Jaunty all the way ever.

I think this has something to do with udev, not really nfs.  In both cases, it's getting to scripts that are definitely on the nfs share, so I don't understand how nfs can be the problem.  I've tried it on a couple of different versions of nfs on the server, and get the same problem.

Has anyone seen this, and does anyone know more about the wretched udev that could help?  It's driving me crazy to boot three times in order to get one working boot!
Pages: [1] 2