3.2 new kernel available

[cbxbiker61]

3.2 is now available.

For everything besides Dreamplugs:
sudo ./README-PLUG-UPDATE.sh 3.2 --nandkernel (installs to nand)
or:
sudo ./README-PLUG-UPDATE.sh 3.2 --rootkernel (installs to /boot)

For Dreamplugs:
sudo ./README-DREAM-UPDATE.sh 3.2 (installs to /boot)

Kernel and modules are available from the following locations:

http://www.plugapps.com/mirror/with-linux/
http://www.xilka.com/sheeva/

Features systemd, e-sata, dmcrypt, IPV6, CIFS, NFS4, EXT3, EXT4, JFS, XFS, FUSE(for ntfs-3g), UBIFS, usb-serial, uvcvideo, iptables, appletalk, bluetooth, v4l and ppp.

The kernel source is here, for those of you who need to compile custom modules.  It's no longer necessary for me to use dropbox for the kernel source, since you can access it on the plugapps mirror.

[spinifex]

The Marvel sd8xxx drivers need some work for the 3.2 kernel. Unless new source from Marvell appears it will be back to the disfunctional Libertas drivers for some Dreamplug owners.

[spinifex]

Hi Biker,

When trying to boot using the dream 3.2 uImage, It hangs after the following console output.
I have tried building the kernel myself with the same result.
Any ideas.

Code:

Load address: 0x6400000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ######
done
Bytes transferred = 2688072 (290448 hex)
## Booting kernel from Legacy Image at 06400000 ...
   Image Name:   Linux-3.2.0
   Created:      2012-01-05   9:39:24 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2688008 Bytes = 2.6 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

[cbxbiker61]

Hi Biker,

When trying to boot using the dream 3.2 uImage, It hangs after the following console output.
I have tried building the kernel myself with the same result.
Any ideas.

Code:

Load address: 0x6400000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ######
done
Bytes transferred = 2688072 (290448 hex)
## Booting kernel from Legacy Image at 06400000 ...
   Image Name:   Linux-3.2.0
   Created:      2012-01-05   9:39:24 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2688008 Bytes = 2.6 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

3.2 seems to be working well on my sheevaplug.

There's the patch I created that pulled a function out of the uap code.  That's built as a module, so shouldn't be a problem here.

I'd diff the dream-3.1.7.config to dream-3.2.config to see if there are any new options turned on that might specifically affect the dream.

[weltall]

Hi Biker,

When trying to boot using the dream 3.2 uImage, It hangs after the following console output.
I have tried building the kernel myself with the same result.
Any ideas.

Code:

Load address: 0x6400000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ######
done
Bytes transferred = 2688072 (290448 hex)
## Booting kernel from Legacy Image at 06400000 ...
   Image Name:   Linux-3.2.0
   Created:      2012-01-05   9:39:24 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2688008 Bytes = 2.6 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

I've the same issue on my guruplug server plus. First i tried my own kernel (by just doing a makeold config run from a configuration which worked on 3.0) then the sheevaplug build from the link here, in both cases it stopped at booting the kernel.

Code:

U-Boot 2010.03-01266-g42f7128-dirty (Mai 12 2010 - 13:28:48)
Marvell-GuruPlug (-: flipflip's version 20100512 :-)

SoC:   Kirkwood 88F6281_A0
DRAM:  512 MB
NAND:  512 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0, egiga1
88E1121 Initialized on egiga0
88E1121 Initialized on egiga1
Hit any key to stop autoboot:  0
GuruPlug>> bdinfo
arch_number = 0x00000A63
env_t       = 0x00000000
boot_params = 0x00000100
DRAM bank   = 0x00000000
-> start    = 0x00000000
-> size     = 0x10000000
DRAM bank   = 0x00000001
-> start    = 0x10000000
-> size     = 0x10000000
DRAM bank   = 0x00000002
-> start    = 0x00000000
-> size     = 0x00000000
DRAM bank   = 0x00000003
-> start    = 0x00000000
-> size     = 0x00000000
ethaddr     = 00:50:43:01:8C:24
ip_addr     = 192.168.1.188
baudrate    = 115200 bps
GuruPlug>> printenv
bootcmd=${x_bootcmd_usb}; ${x_bootcmd_kernel}; setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x6400000;
bootdelay=3
baudrate=115200
x_bootcmd_usb=usb start
x_bootcmd_kernel=nand read.e 0x6400000 0x100000 0x400000
x_bootargs=console=ttyS0,115200
ethact=egiga0
ethaddr=<removed>
eth1addr=<removed>
filesize=2CD254
fileaddr=800000
ipaddr=192.168.1.188
serverip=192.168.1.19
x_bootargs_root=ubi.mtd=2 root=/dev/sdb1 rootwait
bootargsconsole=ttyS0,115200 ubi.mtd=2 root=/dev/sdb1 rootwait
bootargs=console=ttyS0,115200 ubi.mtd=2 root=/dev/sdb1 rootwait
stdin=serial
stdout=serial
stderr=serial

Environment size: 615/131068 bytes
GuruPlug>> tftpboot 0x6400000 sheeva-3.2-uImage
Using egiga0 device
TFTP from server 192.168.1.19; our IP address is 192.168.1.188
Filename 'sheeva-3.2-uImage'.
Load address: 0x6400000
Loading: #################################################################
         #################################################################
         #################################################################
         ####
done
Bytes transferred = 2911816 (2c6e48 hex)
GuruPlug>> bootm 0x6400000
## Booting kernel from Legacy Image at 06400000 ...
   Image Name:   Linux-3.2.0
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2911752 Bytes =  2.8 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

[spinifex]

I've the same issue on my guruplug server plus. First i tried my own kernel (by just doing a makeold config run from a configuration which worked on 3.0) then the sheevaplug build from the link here, in both cases it stopped at booting the kernel.

Thanks, that's reassuring. I have fiddled a few likely parameters with no luck, so far.

[cbxbiker61]

The 3.2 kernel size is a bit bigger than the previous kernels.

I wonder if your uImage partition size is large enough.

On my sheeva the uImage partition size is 0x400000.
I wonder if you guys maybe have a partition size of 0x300000.
If that's the problem, either the kernel image is going to have to shrink
or you're going to have to reconfigure your partition sizes (which would be a pain).
We could probably shrink the kernel size by using CONFIG_KERNEL_LZMA rather than CONFIG_KERNEL_GZIP.

[cbxbiker61]

The 3.2 kernel size is a bit bigger than the previous kernels.

I wonder if your uImage partition size is large enough.

On my sheeva the uImage partition size is 0x400000.
I wonder if you guys maybe have a partition size of 0x300000.
If that's the problem, either the kernel image is going to have to shrink
or you're going to have to reconfigure your partition sizes (which would be a pain).
We could probably shrink the kernel size by using CONFIG_KERNEL_LZMA rather than CONFIG_KERNEL_GZIP.

If you boot from SD card none of that should apply.  In any case, for plug users it's something to keep in mind.  My sheeva boots from SD, so I personally have to worry too much about uImage size.

[weltall]

i'm running it from ram i didn't even reach that point... anyway i've checked my 3.0 build is bigger than the prebuild posted here (2.8mb vs 2.7mb) my 3.2 build is 3mb

[spinifex]

I have carefully checked bikers (and my) .config. I have built dozens of variations trying to get 3.2 to at least start the boot process. None of them would even twitch. Wait for 3.2.1 methinks.

[mgillespie]

Can confirm Something fishy going on with 3.2...

http://www.plugcomputer.org/plugforum/index.php?topic=6029.0

[cbxbiker61]

I have carefully checked bikers (and my) .config. I have built dozens of variations trying to get 3.2 to at least start the boot process. None of them would even twitch. Wait for 3.2.1 methinks.

There is another option...git bisect.  It's not necessarily true that the problem will self-resolve as the 3.2 kernel increments.  You could get the main kernel git code and bisect between the 3.1 and 3.2 tags to isolate the problem.  Since it's a "lockup" problem, the test procedure is quite simple.

I've isolated problems with the kernel with git before, and once you've experience "git bisect" in action, you'll wonder how any decent sized software project could get by without it.


I see that 3.2.1 has just been released.  I'll build that up real soon and you can give that a try.  If it doesn't fix the problem, git bisect might be the answer.

[weltall]

git bisect is just a basic binary search it can be done with anything which has a concept of revisions including svn or even something as basic as dropbox... actually even cvs can be used for it with the time statement. all this in log(n) (in the worst case) where n is first known not working revision minus last known woking revision
So don't wonder how big project can get by without git at all.

[cbxbiker61]

git bisect is just a basic binary search it can be done with anything which has a concept of revisions including svn or even something as basic as dropbox... actually even cvs can be used for it with the time statement. all this in log(n) (in the worst case) where n is first known not working revision minus last known woking revision
So don't wonder how big project can get by without git at all.

Actually, git's non-linear check-in model makes bisection a bit more complicated than just splitting the difference between versions, which you can do in your head.  Anyway, it's very nicely integrated in git.  Sounds like Mercurial has bisect as well, although I haven't used it.

[weltall]

yes without the command git would have an extremely big negative point because it's extremely complex for humans to handle it manually with the git system. others can be easily implemented as a command with a 5 lines bash script.
Anyway going back to the topic for me it's difficult to do as it would take 4 hours each build (as i build on the plug and i don't have crosscompilers on my main systems) i wonder if spinifex could do it else i could have a try at it. 3.1.5 didn't build for me at all so i'll have to hope 3.1 builds for me (as in linus tree you've just that one).