[DEV] New kernel 2.6.38.6 in testing

Development on core packages and the distribution goes on in here.

Re: [DEV] New kernel 2.6.37 in testing

Postby BillyBoy » Fri Mar 04, 2011 4:24 pm

Did new USB stick install on my dockstar yesterday. Just ran update on new kernel 2.6.37 today (few hours ago).

Still dockstar LEDs are not working even though xt_LED module has been started correctly (not even solid green after proper Arch Linux ARM install launch). Seems that not all LED triggers are installed by default in /sys/class/leds. At least there's only one trigger "status:green:health" included. Shouldn't there be more subfolders like "/dockstar:green:health/trigger" and so forth, and the same also for the color orange? :?:

I'm a little bit confused... :?
How do I know the right folder structure and how can I obtain the mising triggers? :shock:

Edit on
Found a bug report at github mentioning the same problem already five days ago:
https://github.com/Arch Linux ARM/Arch Linux ARM/issues/closed/#issue/42
And why does it only occur if a new install is done (Arch Linux ARM install 2011-02 with kernel 2.6.37)?
If it really can be fixed by changing the arc-number in uboot to 2998, how can this be done?

Edit off

Regards,
BillyBoy
BillyBoy
 
Posts: 7
Joined: Mon Sep 27, 2010 2:43 pm

Re: [DEV] New kernel 2.6.37 in testing

Postby kmihelich » Sat Mar 05, 2011 1:35 am

Make sure you have the latest uboot installed, just follow the first box of instructions here:
http://jeff.doozan.com/debian/uboot/

You can run that within Arch Linux ARM now, you don't have to be in the stock firmware. All new kernels configure LEDs by using the ARM architecture/implementation ID specified in uboot as the variable arcNumber. After running Jeff's script, you'll want to do this:
$this->bbcode_second_pass_code('', 'fw_setenv arcNumber 2998')
and then reboot. 2998 is the ID for the Dockstar, which will run the machine initialization code in the kernel, configuring the LEDs. I don't remember what the default states are, but you can configure them or set boot defaults in /etc/rc.local.
Arch Linux ARM exists and continues to grow through community support, please donate today!
kmihelich
Developer
 
Posts: 1133
Joined: Tue Jul 20, 2010 6:55 am
Location: aka leming #archlinuxarm

Re: [DEV] New kernel 2.6.37 in testing

Postby BillyBoy » Sat Mar 05, 2011 8:52 am

Thanks a lot for this information. Unfortunately, all issues aren't solved yet.

After re-flashing the latest uBoot (which was already there before) and setting the arcNumber to the new dockstar value, the status led is now solid green after bootup. Also two files (status:green:health and status:orange:fault) are now present in the /sys/clas/leds folder. However, all other dockstar specific triggers which should reside in the /dockstar subfolder are still missing, even after re-installing iptables 1.4.10-1. The triggers I'd like to use are described in this Arch Linux ARM guide, step five:

http://Arch Linux ARM.com/index.php5?title=Ten(ish)_steps_to_setting_up_a_Seagate_Dockstar

Is there a way to get the missing triggers if they aren't present in the new kernel installation package by default? Putting trigger commands into rc.local or rc.local.shutdown doesn't make any sense as long as the necessarry dockstar triggers are not existing at all. For example:

$this->bbcode_second_pass_code('', '#Set up orange LED to blink on incoming TCP traffic (rc.local)
iptables -A INPUT -p tcp -j LED --led-trigger-id tcpin --led-delay 100
echo netfilter-tcpin > /sys/class/leds/dockstar\:orange\:misc/trigger') or
$this->bbcode_second_pass_code('', '#Set up orange LED to pulse heartbeat when system halted (rc.local.shutdown)
echo heartbeat > /sys/class/leds/dockstar\:orange\:misc/trigger')
Thanks in advance for your help.

Edit on----
Ok, finally I got it. In order to make the LED triggers work with the new kernel version, the command paths have to be changed:

$this->bbcode_second_pass_code('', 'from /sys/class/leds/dockstar\:green\:health to /sys/class/leds/status\:green\:health') and
$this->bbcode_second_pass_code('', 'from /sys/class/leds/dockstar\:orange\:misc to /sys/class/leds/status\:orange\:fault')
Maybe you can update all the official guides to reflect that basic change. Thank you.
Edit off----
BillyBoy
 
Posts: 7
Joined: Mon Sep 27, 2010 2:43 pm

Re: [DEV] New kernel 2.6.37 in testing

Postby replabrobin » Sat Mar 05, 2011 2:07 pm

Trying the March 04 kernel on a sheeva arcNumber=2097.

With the old 2.6.36 kernel I see two entries in /sys/class/leds
dockstar:green:health dockstar:orange:misc, but I can't seem to get dockstar:orange:misc to do anything. However, dockstar:green:health does work and sets the non-power light at a red colour. The power light stays blue continually.

With the new kernel I see one entry in sys/class/leds status:green:health. This works, but it affects a different led (the power light); trigger is default-on and makes the light blue; none makes it green; heartbeat blue/green flashing.

From this I deduce that both lights on the sheeva can be controlled, but neither the previous kernel 2.6.36 or this new Mar 4 kernel-2.6.37 seems to make both available on the Sheeva.
replabrobin
 
Posts: 108
Joined: Tue Nov 30, 2010 11:18 am

Re: [DEV] New kernel 2.6.37 in testing

Postby replabrobin » Mon Mar 07, 2011 8:44 am

I changed the sheevaplug_setup.c patch to the following to obtain working LEDs for both the green/red and the green/blue. The patch seems to work fine. Of course the names are a bit wrong since in fact the [none] colours are actually green for both and they flash red and blue respectively. I don't have access to the sata version so I left that alone.

$this->bbcode_second_pass_quote('', '-')-- a/arch/arm/mach-kirkwood/sheevaplug-setup.c
+++ b/arch/arm/mach-kirkwood/sheevaplug-setup.c
@@ -58,7 +58,13 @@

static struct gpio_led sheevaplug_led_pins[] = {
{
- .name = "plug:green:health",
+ .name = "status:red:misc",
+ .default_trigger = "none",
+ .gpio = 46,
+ .active_low = 1,
+ },
+ {
+ .name = "status:green:health",
.default_trigger = "default-on",
.gpio = 49,
.active_low = 1,
@@ -80,7 +86,8 @@

static unsigned int sheevaplug_mpp_config[] __initdata = {
MPP29_GPIO, /* USB Power Enable */
- MPP49_GPIO, /* LED */
+ MPP46_GPIO, /* LED Red*/
+ MPP49_GPIO, /* LED Green*/
0
};

replabrobin
 
Posts: 108
Joined: Tue Nov 30, 2010 11:18 am

Re: [DEV] New kernel 2.6.37 in testing

Postby replabrobin » Mon Mar 07, 2011 8:46 am

The [code][/code} really mangled that patch I'll quote it

$this->bbcode_second_pass_quote('', '-')-- a/arch/arm/mach-kirkwood/sheevaplug-setup.c
+++ b/arch/arm/mach-kirkwood/sheevaplug-setup.c
@@ -58,7 +58,13 @@

static struct gpio_led sheevaplug_led_pins[] = {
{
- .name = "plug:green:health",
+ .name = "status:red:misc",
+ .default_trigger = "none",
+ .gpio = 46,
+ .active_low = 1,
+ },
+ {
+ .name = "status:green:health",
.default_trigger = "default-on",
.gpio = 49,
.active_low = 1,
@@ -80,7 +86,8 @@

static unsigned int sheevaplug_mpp_config[] __initdata = {
MPP29_GPIO, /* USB Power Enable */
- MPP49_GPIO, /* LED */
+ MPP46_GPIO, /* LED Red*/
+ MPP49_GPIO, /* LED Green*/
0
};

replabrobin
 
Posts: 108
Joined: Tue Nov 30, 2010 11:18 am

Re: [DEV] New kernel 2.6.37 in testing

Postby SeVaN » Thu Mar 10, 2011 9:38 am

I upgraded my (pink) PogoPlug two days ago using the procedure described in the wiki.
So far, everything still works, which IMHO is a great result for such a major update!

From time to time I take a quick peek at everything.log to see if everything is OK. I noticed that since the update, when I unplugged a USB device, the following entry is logged:
$this->bbcode_second_pass_quote('', 'm')odprobe: FATAL: Could not load /lib/modules/2.6.36/modules.dep

On my filesystem I don't have /lib/modules/2.6.36 but 2.6.37.

If I execute uname -a then I get:
$this->bbcode_second_pass_quote('', 'L')inux PogoPlug 2.6.36 #1 PREEMPT Wed Nov 17 06:23:34 CST 2010 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux

I haven't rebooted since the update.

Do you have any idea what could be causing modprobe to look in the wrong directory?

(A quick fix would probably be to create a symlink from 2.6.36 to 2.6.37 but I'd really like to know what causes the problem before I attempt a workaround)

Thanks!
SeVaN
 
Posts: 3
Joined: Thu Mar 10, 2011 9:27 am
Top

Re: [DEV] New kernel 2.6.37 in testing

Postby pepedog » Thu Mar 10, 2011 10:50 am

uname -a won't take effect until reboot
Just incase
pacman -Sf kernel26 kernel-headers
pepedog
Developer
 
Posts: 2431
Joined: Mon Jun 07, 2010 3:30 pm
Location: London UK

Re: [DEV] New kernel 2.6.37 in testing

Postby SeVaN » Thu Mar 10, 2011 10:56 am

Did pacman -Sf kernel26 kernel-headers
Then tried modprobe smbd
No change. modprobe still looks for /lib/modules/2.6.36/modules.dep

Thanks anyway!
SeVaN
 
Posts: 3
Joined: Thu Mar 10, 2011 9:27 am

Re: [DEV] New kernel 2.6.37 in testing

Postby SeVaN » Mon Mar 14, 2011 10:59 am

In the meantime I reinstalled my PogoPlug (for a different reason). Problem solved.
SeVaN
 
Posts: 3
Joined: Thu Mar 10, 2011 9:27 am

PreviousNext

Return to Arch Linux ARM

Who is online

Users browsing this forum: No registered users and 14 guests