Linux Kernel 6.8.7 Kirkwood package and Debian rootfs

Hi bodhi,

I'm currently trying to make an Debian 7.1 / grip 4.1 embdebian with your kernel.

The Pogoplug has too little flash, but a Dockstar seams fine.

But I realized you have an interesting selection of kernel modules.
While I could (and partly did) delete the ones I don't need, I wanted to ask you:

Could you tell me where the source is, so that I can build my own, with a different selection of modules?

Thanks,
Goetz.

Hi Goetz,

The tarball has everything you need (the patch file, config file, kernel deb package, kernel headers). So you can get the 3.9.11 source from the kernel source tree and apply the patch to it.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Greetings. Thanks Bodhi for your great work. I tried your latest Debian-3.9.11-kirkwood-tld-1-rootfs-bodhi.tar.bz2 on a 2TB GoFlex Home but encoutered the /root/dev mount error eas mentioned on or about 5 Aug in this thread. It seems the solution is to "remove the kernel flash" but I have no idea what you're talking about. Maybe I'm doing something wrong? Basically, I simply untarred your Debian-3.9.11-kirkwood-tld-1-rootfs-bodhi.tar.bz2 to the rootfs partition on the drive. I did not run the additional "dpkg" or "mkimage" commands you mentioned because I don't understand those instructions. Under what environment am I to run them? They would seem to alter the system under which I'm untarring, and that just seems wrong. Can someone explain the procedure for this dummy please. I'm attaching the boot with the error, along with a printenv. Note that I added the sata_* environment strings in order to boot from the sata drive of the GoFlex Home. Any advice welcome and thanks again.

To reply to my own question..

The solution apparently had nothing to do with "kernel flash". I had formatted the rootfs as ext2 and my sata_rootfstype was ext3. Changed the rootfs type to ext3 and edited /etc/fstab. All is well now. Sorry for the noise.

PhantomsDad Wrote:
-------------------------------------------------------
> To reply to my own question..
>
> The solution apparently had nothing to do with
> "kernel flash". I had formatted the rootfs as
> ext2 and my sata_rootfstype was ext3. Changed the
> rootfs type to ext3 and edited /etc/fstab. All is
> well now. Sorry for the noise.

Thanks for you feedback, reminding me to update the installation instruction. In the past, fstab entry really does not matter if we pass the rootfs type in kernel command line. So I did not really pay attention to this. But they should match to prevent problem.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

eas Wrote:
-------------------------------------------------------
> Thanks. To be clear, I didn't have any sort of
> error while generated the initrd.img. Its just
> that it couldn't mount the root file system due to
> flash-kernel forcing it to look for "/dev/root"
> rather than the bootparam I'd configured in
> uboot.
>
> On the upside, I've learned about how the boot
> scripts work. Information I'm sure to forget
> before it comes up again.
>

@eas,

I'm curious, which bootscripts did you look at to figure out this problem? Thanks.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I noticed that I can't shutdown my NSA320 using power button in combination with input-event-daemon.
It seems the event is not generated as polling /dev/input/event0 leads to no results.
Could it be something related to 3.9.11-kirkwood-tld-1 ?

Gaogao,

Possibly. See this post:
http://forum.doozan.com/read.php?2,12096,12987#msg-12987

I will release 3.10.4 with this config option (in a couple days).You can give it a try then!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

can't wait then :)
TIA

Kernel 3.10.4 Kirkwood package was uploaded. Please see 1st post for download link.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
> I will release 3.10.4 with this config option (in
> a couple days).You can give it a try then!

unfortunately it did not help, still no events from the power button.
TKS for the update anyway!

Gaogao,

"Still no events from the power button". I don't have the NSA320 so not sure about this. It might not be related to the Config_Marvell_Phy option. As I recalled, iConnect has similar button, and I needed a script to manage the event. I imagine the NSA320 would have the same kind of script that should come with the stock installation.

Perhaps others who have set this up successfully on NSA320 should give post a hint here!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Debian Kirkwood rootfs 3.10.4 was uploaded. Please see 1st post for download link.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi,

just some comments concerning the NSA320 and the power button,.. I have not tested bodhi's 3.10.4 kernel yet, but:

on one of my NSA320 boxes here there ist 3.10.1 mainline kernel running with
full ARCH patches and with some minor patches I added because of the sata leds together with bodhi's debian rootfs,..

the power button is working nicely,
the input event daemon waits for the gpio-key as /devices/platform/gpio-keys/input/input0
and everything is fine so far,..

@ gaogao: please check /dev/input/by-path, there a platform-gpio-keys-event should show up which is
identical to /dev/input/event0, that is the one the events-input-daemon is waiting for,..

but only if you have a configured /etc/input-event-daemon.conf with something like:

[Global]
listen = /dev/input/event0
[Keys]
POWER = shutdown -P -h now

the issue with the poweron resume is a different story, in my rc.local there is
something like

    /bin/echo 47 > /sys/class/gpio/export
    /bin/echo 49 > /sys/class/gpio/export

    # 49 out, value 1
    /bin/echo "out" > /sys/class/gpio/gpio49/direction
    /bin/echo 1 > /sys/class/gpio/gpio49/value
    # 47 out, value 1
    /bin/echo "out" > /sys/class/gpio/gpio47/direction
    # next line 0 to disable, 1 to enable resume from power loss ( powers the PHY also!!)
    /bin/echo 1 > /sys/class/gpio/gpio47/value
    # set 49 value 0
    /bin/echo 0 > /sys/class/gpio/gpio49/value

but this only affects the powering on procedure and by the way activates the Marvell Phy,..
(and permits WOL if you power it down with the power button),..

best wishes pbg4



Edited 3 time(s). Last edit at 08/25/2013 03:45PM by pbg4.

@pbg4: everything here seems to be the same:

$ ll /dev/input/by-path
total 0
drwxr-xr-x 2 root root  60 Aug 23 12:17 .
drwxr-xr-x 3 root root 100 Aug 23 12:17 ..
lrwxrwxrwx 1 root root   9 Aug 23 12:17 platform-gpio-keys-event -> ../event0

$ cat /etc/input-event-daemon.conf
#
# /etc/input-event-daemon.conf
#

[Global]
listen = /dev/input/event0

[Keys]
POWER = shutdown -h now

so either the rc.local lines you have make a difference or it should be the kernel - AFAIK.

EDIT: I ran the rc.local lines and I got the power off event. TKS!



Edited 1 time(s). Last edit at 08/27/2013 01:09AM by gaogao.

Hi,

@gaogao,

good to hear, that you got the shutdown button working,..

@bodhi,

this weekend I had some time to test your 3.10.4 kernel packages (image and header files)
on my iConnect, everything is fine, with a debian squeeze rootfs,.. only the lm63 module for hwmon is missing, ..
thanks!!

I just recompiled the lm63 module and everything is working now,

because this recompilation could serve as a template
for other users here in this thread who ask for missing modules,.. here are the few steps to get it working without
recompiling the kernel and all the modules, ... here is the quick solution:

prerequisite: you have installed bodhi's kernel and header files
according to his howto in this thread and you are running the new kernel,
and perhaps some module you need is missing, say the lm63 hwmon module for an iConnect,..

and you want to compile it natively on the arm device without crosscompiling,
so you have the compiler suite and relevant tools already installed,..

than download 3.10.4 kernel sources from kernel.org, decompress the sources in /usr/src, copy the config and cd into the sources,

cp linux-3.10.4-tld-1-kirkwood.patch from bodhi's kernel files into /usr/src/.

cd linux-3.10.4/
patch -p 1 < ../linux-3.10.4-tld-1-kirkwood.patch --dry-run to test the patch, than apply it without --dry-run,

next:
cp ../linux-headers-3.10.4-kirkwood-tld-1/Module.symvers . <--- this is important, the Module.symvers must get copied in linux-3.10.4 directory!

copy the config and make the oldconfig:

cp /boot/config-3.10.4-kirkwood-tld-1 .config
make oldconfig

edit .config to enable the modules you need, in my case

set CONFIG_SENSORS_LM63=m with vi, nano or whatever editor you like,..

than:

make prepare
make SUBDIRS=scripts/mod
make SUBDIRS=scripts/genksyms
make SUBDIRS=drivers/hwmon modules

after the make prepare you have to test wether make SUBDIRS=drivers/hwmon modules works,
in my case genksyms.o was missing (see the error report),
than a make of SUBDIRS=scripts/genksyms got rid of the error,
next test wether the directory where the missing driver resides can be build all together,..

than

cp drivers/hwmon/lm63.ko /lib/modules/3.10.4-kirkwood-tld-1/kernel/drivers/hwmon/.
depmod
modprobe lm63

and you are done, painfree and easy,...

best wishes pbg4



Edited 3 time(s). Last edit at 09/08/2013 04:29PM by pbg4.

pbg4 Wrote:
-------------------------------------------------------
> Hi,
>
> @gaogao,
>
> good to hear, that you got the shutdown button
> working,..
>
> @bodhi,
>
> this weekend I had some time to test your 3.10.4
> kernel packages (image and header files)
> on my iConnect, everything is fine, with a debian
> squeeze rootfs,.. only the lm63 module for hwmon
> is missing, ..
> thanks!!
>
> I just recompiled the lm63 module and everything
> is working now,
>
> because this recompilation could serve as a
> template
> for other users here in this thread who ask for
> missing modules,.. here are the few steps to get
> it working without
> recompiling the kernel and all the modules, ...
> here is the quick solution:
>
> prerequisite: you have installed bodhi's kernel
> and header files
> according to his howto in this thread and you are
> running the new kernel,
> and perhaps some module you need is missing, say
> the lm63 hwmon module for an iConnect,..
>
> and you want to compile it natively on the arm
> device without crosscompiling,
> so you have the compiler suite and relevant tools
> already installed,..
>
> than download 3.10.4 kernel sources from
> kernel.org, decompress the sources in /usr/src,
> copy the config and cd into the sources,
>
> cp linux-3.10.4-tld-1-kirkwood.patch from bodhi's
> kernel files into /usr/src/.
>
> cd linux-3.10.4/
> patch -p 1 < ../linux-3.10.4-tld-1-kirkwood.patch
> --dry-run to test the patch, than apply it without
> --dry-run,
>
> next:
> cp
> ../linux-headers-3.10.4-kirkwood-tld-1/Module.symv
> ers . <--- this is important, the Module.symvers
> must get copied in linux-3.10.4 directory!
>
> copy the config and make the oldconfig:
>
> cp /boot/config-3.10.4-kirkwood-tld-1 .config
> make oldconfig
>
> edit .config to enable the modules you need, in my
> case
>
> set CONFIG_SENSORS_LM63=m with vi, nano or
> whatever editor you like,..
>
> than:
>
> make prepare
> make SUBDIRS=scripts/mod
> make SUBDIRS=scripts/genksyms
> make SUBDIRS=drivers/hwmon modules
>
> after the make prepare you have to test wether
> make SUBDIRS=drivers/hwmon modules works,
> in my case genksyms.o was missing (see the error
> report),
> than a make of SUBDIRS=scripts/genksyms got rid of
> the error,
> next test wether the directory where the missing
> driver resides can be build all together,..
>
> than
>
> cp drivers/hwmon/lm63.ko
> /lib/modules/3.10.4-kirkwood-tld-1/kernel/drivers/
> hwmon/.
> depmod
> modprobe lm63
>
> and you are done, painfree and easy,...
>
> best wishes pbg4


Well done, pbg4! I'm sure it will benefit many users.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Bodhi,

thanks for all of your effort put into this project. I am curious if debian can be installed on a newly purchased pogo-p22. My attempts have been unsuccessful. Should I keep trying?

DanK Wrote:
-------------------------------------------------------
> Bodhi,
>
> thanks for all of your effort put into this
> project. I am curious if debian can be installed
> on a newly purchased pogo-p22. My attempts have
> been unsuccessful. Should I keep trying?

DanK,

You'll need to verify whether the P22 is an OXNAS or Kirkwood. According to the Arch site, there are many variations of the OXNAS (e.g. P21, B01, P01,...) not none of them is a P22. I suspect it is an OXNAS.
http://archlinuxarm.org/platforms/armv6/pogoplug-v3oxnasend-life

If you can log into Arch Linux, then do uname -a will tell you for sure.

If it is indeed an OXNAS then see this thread:
http://forum.doozan.com/read.php?3,6336

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Dear all,

I have a NSA320 and the 3.10.4 kernel and rootfs running. My leds are not working correct. I check the file rc.local there is not any config for the NSA320. I don't know if I misunderstood something or I have something wrong with my system.

ls /sys/class/leds/
nsa320:green:copy
nsa320:green:hdd1
nsa320:green:hdd2
nsa320:green:sys
nsa320:green:usb
nsa320:orange:sys
nsa320:red:copy
nsa320:red:hdd1
nsa320:red:hdd2

Also I will like to know which is the correct arcNumber for the NSA320 because maybe that is the problem. I found different numbers (3339, 3956, 4022) on internet so I don't know which is the correct one.

Thanks in advance.



Edited 1 time(s). Last edit at 09/22/2013 12:30PM by enavarrocu.

I make the system led work add this in rc.local before the exit 0

if [ -d /sys/class/leds/nsa320:green:sys ]; then
echo default-on > /sys/class/leds/nsa320:green:sys/trigger
echo none > /sys/class/leds/nsa320:orange:sys/trigger
fi

Anything about the other leds?

enavarrocu Wrote:
-------------------------------------------------------
> I make the system led work add this in rc.local
> before the exit 0
>
> if [ -d /sys/class/leds/nsa320:green:sys ]; then
> echo default-on >
> /sys/class/leds/nsa320:green:sys/trigger
> echo none >
> /sys/class/leds/nsa320:orange:sys/trigger
> fi
>
> Anything about the other leds?

enavarrocu,

I don't have the NSA320, so I did not include the LED controls in rc.local for it! Now that you have posted the content of /sys/class/leds/nsa320, next time I release another rootfs I will include them.

Usually, the other LEDs work the same way. It will light up with the correct color if you set them. So if you set

echo default-on > /sys/class/leds/nsa320:green:hdd1/trigger

then it will light up green whenever you have hardisk 1 activity.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi enavarrocu,

as bodhi pointed out you can change the leds behaviour in rc.local and adapt it
to your specific needs, perhaps it is better to use the ide-disk trigger, my rc.local on a nsa320 with a
3.10.1 ARCH ALARM type kernel contains something like:
(which off course you could use also for bodhi's 3.10.4 kernel)

if [ -d /sys/class/leds/nsa320:orange:sys ]; then
   echo none > /sys/class/leds/nsa320:orange:sys/trigger
   if [ -d /sys/class/leds/nsa320:green:sys ]; then
      echo default-on  > /sys/class/leds/nsa320:green:sys/trigger
   fi
   if [ -d /sys/class/leds/nsa320:red:hdd1 ]; then
      echo ide-disk  > /sys/class/leds/nsa320:red:hdd1/trigger
   fi
   if [ -d /sys/class/leds/nsa320:red:hdd2 ]; then
      echo ide-disk  > /sys/class/leds/nsa320:red:hdd2/trigger
   fi

than you have leds which react to the disk activity,

the options you have for setting the trigger are:

none nand-disk timer oneshot [ide-disk] heartbeat gpio default-on

if you want to have these leds acting from the very begin of the boot process
you have to compile your own kernel with modifications in the nsa320-setup.c
in the settings of the

static struct gpio_led nsa320_led_pins[]

and set the default trigger there, however this is more work, but the real place to
change the leds behaviour,

best wishes pbg4

p.s arcNumber=3956 for nsa320



Edited 2 time(s). Last edit at 09/23/2013 03:27PM by pbg4.

pbg4 Wrote:
-------------------------------------------------------
> Hi enavarrocu,
>
> as bodhi pointed out you can change the leds
> behaviour in rc.local and adapt it
> to your specific needs, perhaps it is better to
> use the ide-disk trigger, my rc.local on a nsa320
> with a
> 3.10.1 ARCH ALARM type kernel contains something
> like:
> (which off course you could use also for bodhi's
> 3.10.4 kernel)
>
>

> if [ -d /sys/class/leds/nsa320:orange:sys ]; then
>    echo none >
> /sys/class/leds/nsa320:orange:sys/trigger
>    if [ -d /sys/class/leds/nsa320:green:sys ];
> then
>       echo default-on  >
> /sys/class/leds/nsa320:green:sys/trigger
>    fi
>    if [ -d /sys/class/leds/nsa320:red:hdd1 ];
> then
>       echo ide-disk  >
> /sys/class/leds/nsa320:red:hdd1/trigger
>    fi
>    if [ -d /sys/class/leds/nsa320:red:hdd2 ];
> then
>       echo ide-disk  >
> /sys/class/leds/nsa320:red:hdd2/trigger
>    fi
>

>
> than you have leds which react to the disk
> activity,
>
> the options you have for setting the trigger are:
>
>

> none nand-disk timer oneshot [ide-disk] heartbeat
> gpio default-on
>

>
> if you want to have these leds acting from the
> very begin of the boot process
> you have to compile your own kernel with
> modifications in the nsa320-setup.c
> in the settings of the
>
>

> static struct gpio_led nsa320_led_pins[]
>

>
> and set the default trigger there, however this is
> more work, but the real place to
> change the leds behaviour,
>
> best wishes pbg4
>
> p.s arcNumber=3956 for nsa320

Very nice! thanks pbg4.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Debian kernel 3.11.1 was uploaded. Please see 1st post for download link.

@bodhi I try what you say but the leds stay on all the time. It work a little better with @pbg4 solution.

@pbg4, I did the change and the leds are working. BUT both blink at the same time, not when I use one disk or the other.
BTW my triggers look in this way: none nand-disk timer [ide-disk] default-on. That depend of the kernel? Because there is some options missing that you have.

Also I upgrade to 3.11.1. There is any place were I can check the changes?

Thansk both of you.

PD: @bodhi if you need me to test anything in the NSA320 just let me know.

enavarrocu Wrote:
-------------------------------------------------------
> @bodhi I try what you say but the leds stay on all
> the time. It work a little better with @pbg4
> solution.

Yup! I did not remember about tthe ide-disk trigger (I had ide-disk trigger set that way in my GoFlexNet). What pbg4 said was the correct way to control the disk LEDs.

Regarding the problem with both blinking, you could play at the command line to see what happen when you turn both off and then turn only one on,... (they don't have to be in rc.local).

> PD: @bodhi if you need me to test anything in the
> NSA320 just let me know.

Thanks!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Debian Kirkwood rootfs 3.11.1 was uploaded. Please see 1st post for download link.

@enavarrocu:

Hi, it's good that you got the ide-disk trigger leds working, that's fine,... but at the moment both
leds for the two sata ports of the sata_mv.c driver behave identical, unless someone
is going to invest some time for coding a better patch than this, which of course is a good starting point:

diff -ruN a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
--- a/drivers/ata/sata_mv.c     2013-05-24 12:45:59.000000000 -0600
+++ b/drivers/ata/sata_mv.c     2013-05-30 22:44:14.000000000 -0600
@@ -71,6 +71,7 @@
 #include <scsi/scsi_cmnd.h>
 #include <scsi/scsi_device.h>
 #include <linux/libata.h>
+#include <linux/leds.h>
 
 #define DRV_NAME       "sata_mv"
 #define DRV_VERSION    "1.28"
@@ -1156,6 +1157,8 @@
 {
        int want_ncq = (protocol == ATA_PROT_NCQ);
 
+       ledtrig_ide_activity();
+
        if (pp->pp_flags & MV_PP_FLAG_EDMA_EN) {
                int using_ncq = ((pp->pp_flags & MV_PP_FLAG_NCQ_EN) != 0);
                if (want_ncq != using_ncq)

the LEDS_TRIGGER_IDE_DISK is invoked in the drivers/leds/Kconfig and depends on LEDS_TRIGGERS
and can get activated in the config of the kernel, and, of course the corresponding drivers/leds/trigger/ledtrig-ide-disk.c
subroutine is quite simple at the moment and does not differentiate the sata port numbers,...

in my config of the 3.10.1 kernel with the archlinuxarm patches :

#
# LED Triggers 
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=y 
CONFIG_LEDS_TRIGGER_ONESHOT=y
CONFIG_LEDS_TRIGGER_IDE_DISK=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
# CONFIG_LEDS_TRIGGER_CPU is not set
CONFIG_LEDS_TRIGGER_GPIO=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y

these triggers are set, that's different from bodhi's 3.10.4 kernel config, that is why you noticed
the differences,...

best wishes pbg4

pbg4,

I never had 2 HDDs mounted on my GoFlex Net, so would never know that :). Thanks! I'll take a look at the code and see if I can create a patch for it.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)