• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1]
1  Linux Stuff / Kernel / Re: SD card support on: May 11, 2009, 06:27:35 AM
rc5 still fails for me, I'm afraid:

mmc0: Timeout waiting for hardware interrupt.
mmc0: hw_state=0x53f3, intr_status=0x0415 intr_en=0x6000
mmcblk0: error -110 sending read/write command, response 0x900, card status 0xe00
mmcblk0: error -110 transferring data, sector 267104, nr 8, card status 0xc00

...followed by all the processes locking up one by one.

It's a Kingston 8GB class 4, I think, but as it's at home and I'm at work I don't have any more precise information (plus, my SheevaPlug has crashed).
2  Linux Stuff / Kernel / Re: 2.6.30-rc4 new release on: May 02, 2009, 03:28:07 AM
I don't think the SD card is bad; it's been rock solid on other platforms, and it was my root filesystem when I rebuilt the kernel on it on the SheevaPlug. But I'll give your kernel a try; it's entirely possible I misapplied the patch (I applied it *after* the 2.6.30-rc4 patch. It worked, with offsets, but patch isn't always reliable in these matters). It's an 8GB Kingston Class 6.

I see mention of a 'debug_quirks=1' option to be passed to the sdhci module. This isn't needed, is it?
3  General Category / General Discussion / Re: Let's cut to the chase: does the SheevaPlug have bad flash memory? on: May 02, 2009, 03:22:09 AM
That's not booting from SD --- that's using the SD card as a root filesystem. You're still booting the kernel from the NAND flash. What we really want is to be able to get u-boot to load the kernel from an SD card, which it currently doesn't support...
4  Linux Stuff / Linux distributions / Re: External disk enclosures on: May 01, 2009, 03:39:22 PM
I've been noticing rather dubious behaviour with high-bandwidth devices on USB on the SheevaPlug. I have a suspicion that the USB driver is a bit dodgy. Check for kernel messages (look to see if anything's coming out on the serial console when things go wrong), and see if it matches what people are describing in the 'Hardware/USB Hubs' thread here...
5  Linux Stuff / Linux distributions / Re: Debian running on the plug on: May 01, 2009, 03:37:07 PM
You don't need Debian to run debootstrap --- it's a standalone script that'll run on anything. You can trivially use debootstrap on a PC to set up a USB stick, then plug it into the SheevaPlug and boot from it.

However it's debatable whether it's a *real* Debian without also running a Debian kernel and initrd --- you can't, for example, upgrade your kernel using apt without this. Unfortunately they process of building a Debian kernel seems to be rather involved...

But provided you bear that in mind, the userland works rather well on top of the Marvell kernel. That's what I'm using...
6  Linux Stuff / Kernel / Re: 2.6.30-rc4 new release on: May 01, 2009, 02:32:05 PM
I haven't tried your update yet, but I did rebuild my kernel with ext3 and lots of modules --- BTW, *thank you* for posting the .config file, so many people forget to do this! --- and it worked!

...for about ten minutes. Then it died with the dreaded mmcblk0 -110 I/O error.

I did apply the two patches you distribute on your website --- is this bug supposed to be fixed by now (in which case I've probably just cocked things up), or have Marvell's changes not made their way into the patchset using in rc4 yet?

BTW: I'm using the Debian userland, and the two packages you need for a complete reflashing kit are uboot-mkimage and mtd-utils. No need to build your own mkimage. I'd be very surprised if that wasn't also in Ubuntu.
7  Hardware and U-Boot firmware / Hardware / Re: USB Hubs on: May 01, 2009, 04:03:31 AM
Yup, I'm getting these problems as well. Glad it's not just me!

I've tried three hubs; a shiny new D-Link 7-port hub that I bought specifically to use on the SheevaPlug and two cheapo unbranded 4-port hubs from Scan. One of the unbranded hubs appears to be reliable. The other unbranded hub causes I/O errors on high bandwidth stuff. The D-Link hub does USB resets, randomly disconnects and reconnects devices, and occasionally --- when plugging or unplugging it from the machine --- crashes the SheevaPlug.

This is the kind of error I get:

May  1 10:09:25 chur kernel: end_request: I/O error, dev sda, sector 3839
May  1 10:09:25 chur kernel: sd 33:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00

I'm doing RAID via USB, which means I'm way stressing the hubs; but they should still work. They *appear* to be reliable when plugged into a desktop PC, but I haven't done proper testing yet. I'm using the stock Marvell kernel, and I gather that some USB bugfixes have gone into the mainstream kernel since then, so I'm now in the process of upgrading my kernel.
8  Linux Stuff / Kernel / Re: 2.6.30-rc4 new release on: May 01, 2009, 03:47:55 AM
I'm another ext3 user, I'm afraid... (although I'd really prefer to use JFS. I'm currently using ext3 because that's all the stock Marvell kernel provides.) So I'm going to have to try rebuilding this.

I'm also a big fan of Debian-esque initrds; the allow lightweight generic kernels that support complex boot procedures like NFS boot, RAID boot, exotic filesystems, boot processes with user process interventian, etc without rebuilding the kernel. I'll have to do some investigating once I get this working.
9  Linux Stuff / Kernel / Force reboot via serial console? on: April 24, 2009, 06:33:56 AM
So my Plug has just died --- the USB system seems to have gone funny on bootup and it's hung.

The problem is, I'm at work, and the Plug is several miles away at home. I'm working remotely via the serial console and I can't reach the reset switch from here.

Is there any way of forcing the plug to reboot remotely given that I can't log in to it?

According to the kernel docs, I should be able to use the 'magic SysRq key' feature to do this by sending BREAK, b over the console. However, this needs to be enabled in the kernel. Obviously, I can't log in to check this right now, but trying it doesn't work.

Does anyone know anything about this?
10  General Category / General Discussion / Re: Performance on: April 24, 2009, 06:17:40 AM
I've done some testing with nbench; the full writeup's here: http://www.cowlark.com/2009-04-15-sheevaplug

To summarise: for integer stuff, the SheevaPlug appears to be about the same speed as an AMD Athlon at 1GHz. For floating point stuff, it's slower than a P90 (to nobody's particular surprise). It's approximately 1/3 to 1/2 the speed of my current server, which is a 1.6GHz Athlon.
11  General Category / Success stories / Re: Sound anyone? on: April 24, 2009, 06:13:24 AM
I've noticed that the default kernel on the SheevaPlug finds sound hardware and loads a driver for a mv88fx_snd. It doesn't seem to be entirely happy, though... does anyone know what sound hardware the SheevaPlug actually has? Would it be possible, for example, to solder on a wire, connect up a preamp, and get sound output, or is there stuff missing like an ADC?
12  General Category / General Discussion / Re: SD root filesystem flies! on: April 24, 2009, 06:07:02 AM
The SD card is actually quite slow --- I get 8MB/s read off a Kingston Class 6 SD card. USB is a lot faster; anthing from 15 to 30MB/s, and I'm working on an experimental technique for getting 40MB/s!
13  Hardware and U-Boot firmware / Hardware / Re: Is Flash memory NOT used in running system - Always run out of DDR2 ? on: April 19, 2009, 11:35:46 AM
What you're looking for is the ability to map the flash into the CPU's address space, which allows you to run code directly out of flash. While you can do this with NOR flash, you can't do this with NAND flash --- it just doesn't work like that. All you can use NAND flash for is as a filesystem, which means you've got to copy the data out of it and into RAM before you can run it.

This is typically what you want anyway, because flash is very slow compared to DRAM and will slow execution down considerably.

I don't know for sure how the SheevaPlug works, but other systems like it I've seen typically have a small amount of NOR flash that's used for booting --- NOR flash can be mapped and works just like ROM. This then contains the code necessary to read uBoot out of the NAND flash and run it.
14  Linux Stuff / Kernel / Re: Problems reflashing UImage, bad blocks on: April 18, 2009, 11:42:22 AM
The occasional delay on boot is JFFS scanning the filesystem --- if it's not unmounted cleanly, it has to scan every block to see whether there's data in it. Which takes ages.

JFFS is unfortunately not a good choice for the SheevaPlug. It works very well, and it compresses data, but it doesn't scale to filesystems this big. YAFFS would be more appropriate. (JFFS also doesn't support writeable mmap(), which is why /var/cache/apt is a tmpfs volume; apt-get uses writeable mmap() to maintain its database.)
Pages: [1]