Lacie EdMini V2 - noob review - speed question

[fvdw]

maybe it gives indeed some indications

for d2 network I found this quote
" It is possible to control the power-off behaviour using GPIO #24, setting this pin to 1 will activate the ignore power-off status, thus enabling the software to catch the event and initiate a clean shutdown. "

However the d2 network has a tumble switch (like nwsp1) as the edmini_v2 has a push button (afik)


what you can try is to see if on the edmini_v2 gpio export of pin 24 works or not and if is if that influence the shutdown

Code: Select all

echo 24 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio24/direction
echo 1 > /sys/class/gpio/gpio24/value
echo 24 > /sys/class/gpio/unexport

[fvdw]

to switch on the power led on the edmini_v2 you can try following command

Code: Select all

echo "255" > "/sys/class/leds/power:blue/brightness"

to switch it off

Code: Select all

echo "0" > "/sys/class/leds/power:blue/brightness"

[fvdw]

I have added the contents of my eeprom for reference.

this is what i found for d2 network on eeprom...looks similar

With a proper kernel (2.6.32 with the above patch, or 2.6.37) the EEPROM content is exposed for read and write via the pseudo file /sys/bus/i2c/devices/0-0050/eeprom. This is what I know about its content:
Offset Length Content
0 6 Ethernet MAC address.
6 1 Power flag.
If set to LACIE_POWER_OFF (0), U-Boot will stop the boot process and wait for Wake-on-LAN.
If set to LACIE_POWER_ON (1), U-Boot will reboot.

This seems to be in line with what you see when performing the reboot command, in your case the power flag is set to 1 and the reboot contunues
If edmini_v2 has the same setup Seems you have a possibility to influence the behavior when rebooting and let it halt and wait for a magic packet (WOL) to continue boot.
Ps writing to the eeprom is possible when the edmini_v2 is up and running with our kernel so you could change this setting. However it is quite possible that u-boot needs something to process the WOL request, to my knowledge the network interface card of the edmini_v2 is not capable of a real WOL and Lacie uses a fake method to dtect the magic package. For this is loads some programs in early stage of booting. As these programs are not present in our firmware your edmini_v2 may be halted forever waiting on the magic packet. So if you try it you might end up with a non booting device. Then the only way to get it working again is using the lacie firmware...
Furthermore the "WOL" status of a Lacie device is not a poweroff, the cpu will be running and also the network card.
So this is to my opinion not a real solution to your problem.

The only option I see is using this gpio 24 pin. If the export doesn't work I can compile a kernel to make that possible. Then the script to shutt it down would be stopping important daemons, do a sync to write all data from cache to disk and then sent a 1 to this gpio pin

source: http://www.rigacci.org/wiki/doku.php/do ... d2_network

[swamswam_h]

This is what happens when I enter the commands you proposed:
----
root@LACIE_NAS:/ # echo 24 > /sys/class/gpio/export
root@LACIE_NAS:/ # echo out > /sys/class/gpio/gpio24/direction
-sh: can't create /sys/class/gpio/gpio24/direction: nonexistent directory
root@LACIE_NAS:/ # echo 1 > /sys/class/gpio/gpio24/value
----
There is no gpio24 directory in the /sys/class/gpio directory.
Does this lead us anywhere? Except that it is not GPIO24 that turns the system off.

I will try to make some high resolution images of the PCB. Perhaps I can follow the traces from the button to the CPU or get a clue as to what makes the system shut down (the circuit).

The Led turns on (static, as in power led) using these commands:
echo "255" > "/sys/class/leds/power:blue/brightness"

Is there any way we can use this to make the led:
- turn on when the system is started (power led)? <- insert the command in some startup script
- turn off when it is safe to 'pull the plug' or in other words when the system is in some sort of 'halted' or preboot state?
- make it show the disk activity (activity led)?

thanks!

[fvdw]

This is what happens when I enter the commands you proposed:
----
root@LACIE_NAS:/ # echo 24 > /sys/class/gpio/export
root@LACIE_NAS:/ # echo out > /sys/class/gpio/gpio24/direction
-sh: can't create /sys/class/gpio/gpio24/direction: nonexistent directory
root@LACIE_NAS:/ # echo 1 > /sys/class/gpio/gpio24/value
----
There is no gpio24 directory in the /sys/class/gpio directory.
Does this lead us anywhere? Except that it is not GPIO24 that turns the system off.

It means the gpio pin can not be exported as it is not defined in the kernel, I will compile a trial kernel for you

I will try to make some high resolution images of the PCB. Perhaps I can follow the traces from the button to the CPU or get a clue as to what makes the system shut down (the circuit).

Even if we know that it will not help us. We need a software command

The Led turns on (static, as in power led) using these commands:
echo "255" > "/sys/class/leds/power:blue/brightness"

Is there any way we can use this to make the led:
- turn on when the system is started (power led)? <- insert the command in some startup script
- turn off when it is safe to 'pull the plug' or in other words when the system is in some sort of 'halted' or preboot state?
- make it show the disk activity (activity led)?

thanks!

to incorporate it in the boot scripts to switch on the power led or switch it off is easy, when recompiling the kernel I will see if it can be enabled by default.
ps you could look in the directory /sys/class/leds/power:blue if a file with name trigger is there read the content, if stat or harddisk or something similar is mentioned it could be used to enable disk activity

[fvdw]

I have sent you the trial kernel by PM, I do not like to post trial kernels here as they need to be tested first
Please try it out and report here the result.
This new kernel has changed setting for power LED, maybe it will be on now by default.
And it has defined gpio pin 24 now, so the earlier posted command should work.
I don't know what will happen if you write the new setting to the gpio 24 pin. The edmini might switch off directly or you still must perform the halt command as earlier posted

[swamswam_h]

We're getting somewhere!
The trigger file in the /sys/class/leds/power:blue directory had several items in it.
Default was: [none] nand-disk timer ide-disk heartbeat gpio default-on
I searched the web how to change this file and found:

Code: Select all

echo ide-disk > trigger

This did the trick and changed the file to: none nand-disk timer [ide-disk] heartbeat gpio default-on

The led is now flashing to the disk activity. The original Lacie firmware had this light on, always on, and flash with disk activity. I'm not sure, nor do I know how, if more 'actions' can be combined to be the trigger for the led. Or make the led-action reverse (so always on and disk activity = off)
I think that:
default-on = led always on (power)
ide-disk = disk activity
heartbeat = server load?
nand-disk = ...
timer = ... (shutdown timer for instance? The lacie firmware blinked the led when in shutdown procedure).
gpio = ...

Thanks for the new kernel. Wow,I thought you said you didn't have time to do all this! It is GREATLY appreciated :thumbup .
I have (i'm pretty sure) followed the instructions and issued a reboot. And i'm not sure, but i think it is stuck somewhere very early in the boot process <- read: "it won't boot". Upon powering it up, the fan stays on and the led is lit, exactly as it does right before it used to load the old kernel (and immediately dimmed the led). So I guess that means the firmware can't boot the kernel and is still somewhere waiting for some user interaction (serial console I guess? Now where is my logic level converter to hook it up to my serial port?). So this weekend I will reinstall the old kernel and have another go (to check if I made a mistake somewhere). You'll be hearing from me. And again: so far, your support has been amazing. Thanks.

[fvdw]

---message edited

mmm..its odd that this new kernel doesn't seem to boot.
The previous one I cross compiled on another PC, this one has been compiled on my nwsp2. So it could be a compiler problem although not likely as i used it to compile kernels vor as well nwsp2, nwsp1 and spd8020. All run fine. So it could also be that the gpio 24 which is no set in the kernel now causes the boot procedure to be aborted or in other words, powers off the device !

this were the two lines added

Code: Select all


       /* 24: Inhibit board power off (0 = Disabled, 1 = Enabled) */

#define EDMINI_V2_GPIO_INHIBIT_POWER_OFF    24

and in the init functions

orion_gpio_set_valid(EDMINI_V2_GPIO_INHIBIT_POWER_OFF, 1);


maybe setting it 0 instead of 1 is the right way. To poweroff we have then to change the setting of the gpio pin to 1

Anyhow I will compile a new kernel with the original setup, so not defining and setting gpio 24 pin, I will leave the adapted setting for the power led in, I think thats no reason for not booting. I f that kernel boots then it is the definition or setting of gpio pin 24 and we could try a kernel with only defining the key and one with defining and setting the value to 0 instead of 1)

If you have serial console access you should be able to see were it fails. Probably during loading the kernel.
And compiling this new kernel was little effort I only added two lines in the setup.

pm sent with new kernel

[fvdw]

I edited above post

[swamswam_h]

I have installed the new kernel and the system boots (again). Everything seems normal. Powerled is lit. Disk activity is not shown throught the power led.
So the compilation method is ok?
How can we find out if the '1' or '0' in the first kernel might be the culprit?