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.

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.

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.

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).

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.

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.

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.

Where things are atI 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.

Where things are atI 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 notI 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.