2.6.30-rc8 new release

[cbxbiker61]

Release candidate 8 is now available.

Kernel and modules are available from the following locations:

IPV4: http://sheeva.with-linux.com/sheeva/

IPV6: http://sheeva6.with-linux.com/sheeva/

Features IPV6, CIFS, NFS4, EXT3, EXT4, JFS, XFS, FUSE(for ntfs-3g), UBIFS, usb-serial, uvcvideo, iptables, appletalk. (and all additions made to rc7)

[tmcnulty1982]

I just tried to boot this over NFS and experienced a hang after Uncompressing Linux........

My u-boot config is as follows:

Code:

set mainlineLinux yes
set arcNumber 2097
set ipaddr 192.168.1.205
set serverip 192.168.1.228
set rootpath '/sheevaplug/root'
set image_name sheeva-2.6.30-rc8-uImage
set console 'console=ttyS0,115200 mtdparts=orion_mtd:0x100000@0x000000(u-boot)ro,0x300000@0x100000(uImage),0x1fc00000@0x400000(rootfs)'
set bootargs_root 'rootfstype=nfs root=/dev/nfs rw'
set bootargs_end ':::DB88FXX81:eth0:none'
set bootcmd 'tftpboot 0x2000000 $(image_name);setenv bootargs $(console) $(bootargs_root) nfsroot=$(serverip):$(rootpath) ip=$(ipaddr):$(serverip)$(bootargs_end); bootm 0x2000000'
boot

Minus the changes specified in README-2.6.30-rc8, this config boots the stock kernel fine.  Am I missing something?

Thanks
Tobias

[hammack]

I downloaded the README and executed the file.  No problem downloading or extracting the kernel, buth the flash fails with:

 flash_eraseall: /dev/mtd1: Permission denied

I've been running slackware from a  usb drive, so have mucked with some of the boot parameters.  As far as I can tell, they are back to the default values now, but apparently I can't write to /dev/mtd1.

Any idea what I've done wrong?

Thanks.

[kilowatt]

Check to see if you have 'ro' in your bootargs definition following the '(uImage)'

The 'ro' sets the partition to read only.  You would have to remove it to be able to write to /dev/mtd1.

[tvrusso]

I just got my SheevaPlug and tried to use your README to reflash with the new kernel (I want the modules).  It ended with the following:

Code:

Image 2599688 bytes, NAND page 2048 bytes, OOB area 2048 bytes, devices size 2097152 bytes
Input file does not fit into device: Success
Data was only partially written due to error
: Success

Despite the "Success" claims, this doesn't look good.  Rather than test it out, I just reflashed the original uImage (by following the USB recovery instructions) and got a working device back.

But I'm thinking this probably means my NAND flash is not set up properly to receive the uImage that is downloaded here.  What do I need to do to set it up right?  I assume it's something related to the first couple of steps in the USB recovery document:

Code:

   Marvell>> set loadaddr 0x20000000
   Marvell>> set mtd1Size 0x300000

SO what should "mtd1Size" actually be if not what the recovery document says?

I assume that if I change that, I'll also have to reflash the filesystem, too, because the start of mtd2 will need to be shifted.  Yes?  So what exactly (in painfully detailed steps) would I need to do here.

I have already successfully reflashed my device using the USB recovery after having hosed it following some other instructions that left me with a corrupted "hal" package that couldn't be unwedged, so at least I know how to get it back to its original state.  But I'd rather like not to have to keep doing that  .

[tvrusso]

[...]

But I'm thinking this probably means my NAND flash is not set up properly to receive the uImage that is downloaded here.  What do I need to do to set it up right?  I assume it's something related to the first couple of steps in the USB recovery document:

Code:

   Marvell>> set loadaddr 0x20000000
   Marvell>> set mtd1Size 0x300000

SO what should "mtd1Size" actually be if not what the recovery document says?

I assume that if I change that, I'll also have to reflash the filesystem, too, because the start of mtd2 will need to be shifted.  Yes?  So what exactly (in painfully detailed steps) would I need to do here.
[...]

Answering my own question, looks like I need to completely redo the USB reflash with:

Code:

  Marvell>> set loadaddr 0x2000000
  Marvell>> set mtd1Size 0x400000
  Marvell>> set filesize 0x44ad000
  Marvell>> saveenv
  Marvell>> reset

followed by the reflash from USB drive and a new bootcmd and bootargs of:

Code:

setenv bootcmd 'nand read.e 0x800000 0x100000 0x400000; bootm 0x800000'
setenv bootargs 'console=ttyS0,115200
mtdparts=nand_mtd:0x100000@0x00000(uboot),
0x400000@0x100000(uImage)ro,0x1fb00000@0x500000(rootfs)rw
root=/dev/mtdblock2'

to get back to the original size of mtd1 and the original kernel, at which point I should be able to reflash with the 2.6.30-rc8. 

These commands differ from the ones in the  most recent USB recovery document ( SheevaPlug Development Kit - USB Flash Recovery from U-Boot-Rev1.2.pdf) in that they all set the mtd1 partition to 0x400000 instead of 0x300000.  It is a pity that the 1.2 revision of that is in the most recent documentation package has this choice of mtd1 partition size, since as far as I can tell that is *NOT* how the unit is shipped (according to http://www.computingplugs.com/index.php/Default_software which shows all the mtd1 variables at 0x400000.

 

[rc3]

I wonder if there's another way to change the mtd1Size, the tftp/nfs approach didn't work. I tried the USB recovery approach but unfortunately either the USB key or the 3.5" usb drive didn't work, always got 0 storage found errors (but they are accessible when booting with the default ubuntu system or the nfs environment). I'm so desperate to get that size changed because I need to change the kernel image onboard.

[micky]

The following commands configure uboot to load the uimage from an ext2 formatted usb-stick (there's also a fat load command, see help). It also tells the kernel the layout of the data in nand and that the root file-system is also on the usb-stick.

You need to save the arcNumber and mainlineLinux variables to nand and reset before booting. Then you set the other variables for the next boot. Use the flash utilities to reprogram any of the partitions and reboot.

I'm not sure, if it's cleat that the MTD partitions are only setup by the kernel arguments. There's no partition table that needs to be changed. Just uboot at address 0, bootcmd telling from which address to load the kernel and the kernel flags tellng the MTD driver where to setup mtd block devices. The setup of mtd0 and mtd1 are only for convenience to use them in nandwrite, they are not used by the operating system.

Code:

setenv arcNumber 2097
setenv mainlineLinux yes
saveenv
reset
...
setenv bootargs 'console=ttyS0,115200 mtdparts=nand_mtd:0x100000@0x000000(u-boot),0x00500000@0x00100000(uImage),0x1fa00000@0x00600000(rootfs) root=/dev/sda1 rootdelay=10 rw'
setenv bootcmd 'usb start; ext2load usb 0:1 0x8000000 /uImage; bootm 0x8000000; reset'
boot

[rc3]

Thanks for the reply, micky.

I still don't understand why command
cat /proc/mtd
reports a size of 2MB for mtd1, when I boot with tftp/nfs, no matter how I set the mtdparts parameter.

ust uboot at address 0, bootcmd telling from which address to load the kernel and the kernel flags tellng the MTD driver where to setup mtd block devices. The setup of mtd0 and mtd1 are only for convenience to use them in nandwrite, they are not used by the operating system.

Does that mean if I set
mtdparts=nand_mtd:0x100000@0x000000(u-boot),0x00500000@0x00100000(uImage),0x1fa00000@0x00600000(rootfs) root=/dev/sda1 rootdelay=10 rw
I will get a mtd1size of 5MB, when I do a
nandwrite -p /dev/mtd1 uImage-2.6.XX
[ assuming uImage-2.6.XX is compiled with a SZ_SIZE of 5MB ] ?
Regardless if
cat  /proc/mtd
reports the size of mtd1 as 2MB?

[micky]

I'm using
  mtdparts=nand_mtd:0x100000@0x000000(u-boot)ro,0x00500000@0x00100000(uImage),0x1fa00000@0x00600000(rootfs)

and get

root@sheeva:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00500000 00020000 "uImage"
mtd2: 1fa00000 00020000 "rootfs"

I also flashed a self-compiled kernel but did not touch the SZ_SIZE option. I had to use cat instead of nandwrite because the image was not block-aligned... maybe SZ_SIZE helps here.

Maybe there's another way to set these values in a configuration file after the kernel has booted?

[rc3]

Thank you for trying to help, micky. I've successfully flashed a customised kernal to /dev/mtd1 and here's how I did:

1. Since the newest stable version of linux kernel 2.6.30 is available, I grabbed it and compiled with the stuffs I need
2. Copy the kernel uImage-2.6.30-4M to the tftp root directory
3. I put rootfs under the root directory of my nfs server
4. Interrupt the autoboot and set image_name to uImage-2.6.30-4M, also set up the mtd_parts with size of mtd1=4M
5. With step 2 and 3, I am able to boot into the linux system with the new kernel using tftp/nfs method [ which is different to what's in the documentation, with uImage.sheeva.20090319 I could never change the size of /dev/mtd1 to 4M ]
    finally the result of cat /proc/mtd shows the size of mtd1: 4MB
6. flash_eraseall /dev/mtd1
    nand_write -p /dev/mtd1 uImage-2.6.30-4M
    flash_eraseall /dev/mtd2
    nand_write -m -q /dev/mtd2 ubuntu-9.0.5.Release.jffs2
    reboot
7.
setenv bootcmd 'nand read.e 0x800000 0x100000 0x400000; bootm 0x800000'
setenv bootargs 'console=ttyS0,115200 mtdparts=nand_mtd:0x100000@0x00000(uboot), 0x400000@0x100000(uImage)ro,0x1fb00000@0x500000(rootfs)rw root=/dev/mtdblock2 rootfstype=jffs2'
saveenv
reset
8. Since I need to boot from SD card (whith runs Debian Lenny) from time to time, I made an easy to switch boot settings as follows:
[ btw a customized u-boot.bin is needed to boot from mmc, see http://plugcomputer.org/plugforum/index.php?topic=183.0 for detail ]
setenv bootargs_nand 'console=ttyS0,115200 mtdparts=nand_mtd:0x100000@0x00000(uboot), 0x400000@0x100000(uImage)ro,0x1fb00000@0x500000(rootfs)rw root=/dev/mtdblock2 rootfstype=jffs2'
setenv 'bootcmd_nand 'set bootargs $(bootargs_nand); nand read.e 0x800000 0x100000 0x400000; bootm 0x800000'

setenv bootargs_mmc 'root=/dev/mmcblk0p1 rootdelay=0 rootfstype=ext3'
setenv bootcmd_mmc_init 'mmcinit;mmcinit;ext2load mmc 0 0x400000 /boot/uImage-2.6.30'
setenv bootcmd_mmc 'setenv bootargs $(console) $(bootargs_mmc); run bootcmd_mmc_init; bootm 0x400000'

saveenv

#boot from nand
run bootcmd_nand
#boot from mmc
run bootcmd_mmc

Now I can say good-bye to the slow and annoying usb recovery method.

[Pandemonium]

I'm loving your kernels, cbxbiker.  Thanks for the work you put into them.  You've saved me a ton of time and headache.

I need to do some iptables stuff on my sheevaplug, and I'm finding that this kernel isn't set up for it.  Could you make sure the standard iptables stuff is enabled in the next compile, as well as the following:
Networking -> Network options -> Netfilter -> Core Netfilter Configuration:
    * Netfilter connection tracking support
    * state match support

Networking -> Network options -> Netfilter -> Core Netfilter Configuration:
    * IPv4 connection tracking support

[cbxbiker61]

I need to do some iptables stuff on my sheevaplug, and I'm finding that this kernel isn't set up for it.  Could you make sure the standard iptables stuff is enabled in the next compile, as well as the following:
Networking -> Network options -> Netfilter -> Core Netfilter Configuration:
    * Netfilter connection tracking support
    * state match support

Networking -> Network options -> Netfilter -> Core Netfilter Configuration:
    * IPv4 connection tracking support

Those features should already be in rc8 and the upcoming .30 release.  Maybe you're using outdated module names?  Here's a dump of the modules that are loaded on my firewall machine.  It should give you a pretty good idea which modules need to be loaded for connection tracking. "xt_state.ko" should work for managing state.

xt_tcpudp               2620  5
iptable_nat             4604  1
iptable_mangle          2268  0
iptable_filter          2236  1
ip_tables              10572  3 iptable_nat,iptable_mangle,iptable_filter
nf_conntrack_ftp        6656  0
xt_multiport            2716  0
xt_MARK                 1820  0
xt_CLASSIFY             1244  0
xt_CONNMARK             2332  0
xt_iprange              2076  0
ipt_MASQUERADE          2428  0
nf_nat                 16432  2 iptable_nat,ipt_MASQUERADE
nf_conntrack_ipv4      12520  3 iptable_nat,nf_nat
nf_defrag_ipv4          1500  1 nf_conntrack_ipv4
x_tables               13408  9 xt_tcpudp,iptable_nat,ip_tables,xt_multiport,xt_MARK,xt_CLASSIFY,xt_CONNMARK,xt_iprange,ipt_MASQUERADE
nf_conntrack           54676  6 iptable_nat,nf_conntrack_ftp,xt_CONNMARK,ipt_MASQUERADE,nf_nat,nf_conntrack_ipv4

[Rabeeh Khoury]

Having netfilter part of the kernel isn't a good idea since it adds a ton of code to the gigE path.
Performance of TCP/IP applications (like NAS etc...) will dramatically drop even when just adding CONFIG_NETFILTER without using any rules.