• Home
  • Help
  • Search
  • Login
  • Register
Pages: [1] 2
Author Topic: 3.1.4 new kernel available  (Read 5115 times)
cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« on: November 30, 2011, 09:38:07 PM »

3.1.4 is now available.

I can't test this kernel locally until I get a replacement power supply for my sheevaplug.
Keep me posted if there are any problems.

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

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

Kernel and modules are available from the following locations:

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.  The availability will be limited by my 2 Gig dropbox account limit, but I will keep the most recent versions available.

http://dl.dropbox.com/u/38673799/sheeva-3.1.4-KernelSource.tar.xz
Logged

birdman
Sr. Member
****

Karma: 4
Posts: 443


View Profile WWW
« Reply #1 on: December 01, 2011, 01:47:27 PM »

Thanks.  Running fine on a SheevaPlug with Debian squeeze.
Logged

spinifex
Full Member
***

Karma: 8
Posts: 167



View Profile WWW
« Reply #2 on: December 02, 2011, 07:56:22 PM »

Hi cbxbiker61,

To use a SATA drive as the rootfs on a Dreamplug, I need the following change in dream-$KVer.config
 
< CONFIG_SATA_MV=m
---
> CONFIG_SATA_MV=y

I have built a kernel with =y and it tests ok.

Without this mod, I get kernel panics.
Logged

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #3 on: December 03, 2011, 01:30:17 PM »

Hi cbxbiker61,

To use a SATA drive as the rootfs on a Dreamplug, I need the following change in dream-$KVer.config
 
< CONFIG_SATA_MV=m
---
> CONFIG_SATA_MV=y

I have built a kernel with =y and it tests ok.

Without this mod, I get kernel panics.


I can't remember if this affects the sd? boot order on dreamplugs that don't have an e-sata device attached.  Does it?
The main thing I don't want to do is build a mod into the kernel that would make the internal sd card come up as /dev/sdb for example.  Other than that I don't have any reservations to adding it to the default build for dreamplugs.
Logged

spinifex
Full Member
***

Karma: 8
Posts: 167



View Profile WWW
« Reply #4 on: December 03, 2011, 02:32:22 PM »

It changes boot order, it seems, only when the Drive is connected (plugged in).
No esata, no change.
I am running this kernel on a Multiboot dreamplug (uSD/SD), no u-Boot environment changes.
All cool.
Whilst there are u-Boot issues with eSATA, methinks the Marvell kernel stuff is pretty good.
Without this change, you would need an initrd to boot from the esata connection.
Logged

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #5 on: December 03, 2011, 03:32:15 PM »

It changes boot order, it seems, only when the Drive is connected (plugged in).
No esata, no change.
I am running this kernel on a Multiboot dreamplug (uSD/SD), no u-Boot environment changes.
All cool.
Whilst there are u-Boot issues with eSATA, methinks the Marvell kernel stuff is pretty good.
Without this change, you would need an initrd to boot from the esata connection.


Yeah, that's pretty much what I expected.  So it would create a problem for people that want to boot from the sd and use the e-sata as a data drive only.  I.e. boot with the sata-drive not connected and the sd card would be sda, boot with the sata drive attached and the sd card would be sdb.  So for the greater good, I think I'll leave it as it is.

I prefer not to use initrd's, but for this corner case I think it'll be the most flexible route.  And of course for those people, like yourself, that can build their own kernel's, they can always make the quick change to the config file and build the driver into the kernel.
Logged

spinifex
Full Member
***

Karma: 8
Posts: 167



View Profile WWW
« Reply #6 on: December 03, 2011, 03:38:34 PM »

Quote
So for the greater good, I think I'll leave it as it is.

The reason I asked for the change was not for me.  I now know a growing number of users that find the current behaviour confusing.

Quote
I prefer not to use initrd's,
I have got no idea how to make one. Any references?
Logged

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #7 on: December 03, 2011, 03:59:35 PM »

Quote
So for the greater good, I think I'll leave it as it is.

The reason I asked for the change was not for me.  I now know a growing number of users that find the current behaviour confusing.

Quote
I prefer not to use initrd's,
I have got no idea how to make one. Any references?

I use mkinitcpio.  You control which modules you want to load in /etc/mkinitcpio.conf or in preset files in /etc/mkinitcpio.d.  Once you've configured it to load the boot modules you want, it's just a matter of running it for each kernel update.

Here's a preset that would work for kernel 3.1.4.  If there's enough interest in this, I could change the updater to automatically run mkinitcpio (if it's installed).

cat /etc/mkinitcpio.d/plug-3.1.4.preset                                                       
Code:
PRESETS=('plug')
plug_config="/etc/mkinitcpio.conf"
plug_kver='3.1.4'
plug_image=/boot/initrd-'3.1.4'
« Last Edit: December 03, 2011, 04:08:36 PM by cbxbiker61 » Logged

spinifex
Full Member
***

Karma: 8
Posts: 167



View Profile WWW
« Reply #8 on: December 03, 2011, 05:35:56 PM »

Quote
If there's enough interest in this, I could change the updater to automatically run mkinitcpio (if it's installed).

I had a look at this, and having struggled with the debian installer result (which uses initrd), I am of the view that a simple uImage is so much better on a plug (Sheeva or Dream).

The alternative is that I clone your .config and build (natively) a DreamPlug kernel for each of your kernel releases. I am halfway there already, in that I build the SDLAN wifi drivers for each Dreamplug kernel anyway. So if there is enough interest I will do this.
Logged

spinifex
Full Member
***

Karma: 8
Posts: 167



View Profile WWW
« Reply #9 on: December 05, 2011, 07:08:58 PM »

Methinks that our logic(s) on ESATA were both wrong.

If the ESATA is plugged in at boot time on current model Dreamplugs then the ESATA will be /dev/sda.

On some earlier Dreamplugs this does not happen (not sure why).
If anyone has a different experience, please let us know.

Changing to CONFIG_SATA_MV=y has no impact on the boot order. The order of devices remains the same. The only thing that changes is that the kernel will no longer panic when you try to boot from the ESATA. So the change would not disrupt anyone using the ESATA as a data drive.

I think I have located the 2 lines of code in the kernel which will change this boot order behaviour, I will test and let you know. However, I am thinking that the current Dreamplug default behaviour of always making ESATA sda has the benefit of no u-Boot changes required when using the ESATA as the rootfs. As it stands, on the Dreamplugs that I have, ( DS2-1122-* & DS2-1113-*) they will not boot if the ESATA is connected at power up time, unless you make u-Boot changes.



Logged

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #10 on: December 09, 2011, 03:16:39 PM »

Methinks that our logic(s) on ESATA were both wrong.

If the ESATA is plugged in at boot time on current model Dreamplugs then the ESATA will be /dev/sda.

On some earlier Dreamplugs this does not happen (not sure why).
If anyone has a different experience, please let us know.

Changing to CONFIG_SATA_MV=y has no impact on the boot order. The order of devices remains the same. The only thing that changes is that the kernel will no longer panic when you try to boot from the ESATA. So the change would not disrupt anyone using the ESATA as a data drive.

I think I have located the 2 lines of code in the kernel which will change this boot order behaviour, I will test and let you know. However, I am thinking that the current Dreamplug default behaviour of always making ESATA sda has the benefit of no u-Boot changes required when using the ESATA as the rootfs. As it stands, on the Dreamplugs that I have, ( DS2-1122-* & DS2-1113-*) they will not boot if the ESATA is connected at power up time, unless you make u-Boot changes.



spinifex, what's the word on this?
Logged

spinifex
Full Member
***

Karma: 8
Posts: 167



View Profile WWW
« Reply #11 on: December 09, 2011, 04:35:43 PM »

Quote
I think I have located the 2 lines of code ...

Quote
spinifex, what's the word on this?


Not what I thought. The theory did not stand up to the test.

Where things are at
I am at the moment (slowly) working through the mountain of DreamPlug patches and will try to reconcile these down to a minimum.
You can help me by telling me the origin of linux-3.0-SDIO-micro-AP.patch and 0003-Initial-defconfig.patch. I would also like to know how you maintain the Dreamplug .config from version to version.

The one patch that I have tested (a lot) is the SPI patch (http://www.solinno.co.uk/public/dreamplug/0001-arm-kirkwood-dreamplug-support.patch), it seems good.  The same code exists in various other patches. The only thing I have not tested (for fear of trashing a Dreamplug) is updating u-Boot (via dd if=uboot.kwb of=/dev/mtd0), but my reading of code/dumps is that it will work. I can dd the uboot from (read) from /dev/mtd0.

Re: mkinitcpio. I think including this in the updater is a good idea. (Some say that mkinitcpio initrd gives a faster boot on a SheevaPlug.) If you do this, may I suggest that you add instructions for installing mkinitcpio on Debian.

Googling around: there are reports that the cpu scaling patch does nothing.

And last, CONFIG_SATA_MV=y; it has now been tested on 2 more SATA drives.

Logged

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #12 on: December 09, 2011, 05:32:25 PM »

Quote
I think I have located the 2 lines of code ...

Quote
spinifex, what's the word on this?


Not what I thought. The theory did not stand up to the test.

Where things are at
I am at the moment (slowly) working through the mountain of DreamPlug patches and will try to reconcile these down to a minimum.
You can help me by telling me the origin of linux-3.0-SDIO-micro-AP.patch and 0003-Initial-defconfig.patch. I would also like to know how you maintain the Dreamplug .config from version to version.

The one patch that I have tested (a lot) is the SPI patch (http://www.solinno.co.uk/public/dreamplug/0001-arm-kirkwood-dreamplug-support.patch), it seems good.  The same code exists in various other patches. The only thing I have not tested (for fear of trashing a Dreamplug) is updating u-Boot (via dd if=uboot.kwb of=/dev/mtd0), but my reading of code/dumps is that it will work. I can dd the uboot from (read) from /dev/mtd0.

Re: mkinitcpio. I think including this in the updater is a good idea. (Some say that mkinitcpio initrd gives a faster boot on a SheevaPlug.) If you do this, may I suggest that you add instructions for installing mkinitcpio on Debian.

Googling around: there are reports that the cpu scaling patch does nothing.

And last, CONFIG_SATA_MV=y; it has now been tested on 2 more SATA drives.



linux-3.0-SDIO-micro-AP.patch - this was just an update to the earlier 2.6 AP patch, not sure if it's still needed or not
I just kept updating the earlier patches, since they seemed to be necessary on earlier kernels.

0003-Initial-defconfig.patch - Pretty sure this was from marvell's site, it's not really needed when you are starting with an existing .config file anyway.

As far as maintaining the dreamplug config.  My build script takes the sheevaplug config and turns a thing or two off (which then cascades to more things being turned off).

I'm interested to know if plugenv reads the environment properly with that SPI patch.  There's a ton of validity checks in plugenv to make sure it won't trash the environment before it will allow a write.  So if it will read the environment it has a very high probabilty of writing correctly.

The mkinitcpio stuff will be pretty easy to implement.

I think I'll go ahead and make no significant changes to the 3.1.5 release.  After you've had a chance to evaluate those new patches, I'll roll in any that seem solid.

I should be getting my replacement sheevaplug power supply next week, so I'll be better equipped to do some of my own evaluations.
Logged

spinifex
Full Member
***

Karma: 8
Posts: 167



View Profile WWW
« Reply #13 on: December 09, 2011, 06:49:17 PM »

Quote
I think I'll go ahead and make no significant changes to the 3.1.5 release.

Smart move. However, at 3.1.5 the mvsdio2 patch needs updating

@@ -263,6 +263,15 @@

becomes

@@ -388,6 +388,15 @@

(I think)
Logged

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #14 on: December 09, 2011, 07:08:56 PM »

Quote
I think I'll go ahead and make no significant changes to the 3.1.5 release.

Smart move. However, at 3.1.5 the mvsdio2 patch needs updating

@@ -263,6 +263,15 @@

becomes

@@ -388,6 +388,15 @@

(I think)

Unless patch fails I don't usually change the patches.  But it's miscompiling right now, so I'll have to figure that out.

`oprofile_arch_exit' referenced in section `.init.text' of arch/arm/oprofile/built-in.o: defined in discarded section `.exit.text' of arch/arm/oprofile/built-in.o
Logged

Pages: [1] 2
Print
Jump to: