Lacie EdMini V2 - noob review - speed question

[fvdw]

I was wondering about this:
The system software (original lacie) sets the eeprom status bit to enable a reboot or halt. After that is resets the unit and Uboot boots up again, checks the status in the eeprom and turns off power or reboots. Right? Or did I get it all wrong... But if this is so, shouldn't the 'magic bullet' to our problem be incorporated in the lacie uboot source (which is free, available and heavily modified by lacie)??

As i read it indeed this makes u-boot wait to receive a magic packet (WOL). When this is implemented as on later lacie devices then this will need software present int the lacie firmware as the the network card doesn't support real WOL. So setting this bit and not using the Lacie firmware may make you edmini_v2 wait forever.
Making it work again will then require rerstoring the old firmware to reset the bit.
Also this WOL method of lacie means that the edmini_v2 is not fully powered of, the cpu will be running as well as the power of on the network card. probably only the fan and HDD power are not yet initiated.

The kernel could be adapted to run a kernel process to which you can sent commands from user space. Its the way we also use on the nwsp1 and spd8020. When the kernel receives a message it can then switch of power of HDD, FAN and leds, if we now the right GPIO pins and then halt the system. That will then be almost a complete shutdown.
To figure all this out time will ne necessary and unfortunate it is not on the top of my priority list. So for the moment I think you need to live with it, you can halt the system and then pull the power plug. I know not perfect but most NAS system are always running and only seldom switch down.
I will do some investigations later and maybe later adapt the kernel.

To make the red led working could be easy if we now which GPIO pin it uses

[fvdw]

refering to what you set about red led that it showed sata activity when running the lacie firmware this could mean that the red led is using gpio 14 (sata0 activity)

I will compile a kernel with this gpio pin included in the led settings of the kernel

If we also know the gpio pins for fan, sata, usb and eth power then it also possible to switch off the edmini_v2 by software by communicating from user space with the kernel but I can not find information if those are controlled by gpio pins, maybe you can do some research

[swamswam_h]

I'm doing research allright! Painfully slow, but I will get somewhere. I might even try to contact Lacie for some info.

Apparently there are several 'active'/pollable gpio pins of a total of 26 (!) pins. GPIO 18 is probably the power button (if that could be tested somehow would be nice.. some script that echoes some string in a log or something that the button was pushed). The other GPIO's are a bit confusing now. 16 is the power led as far as i can tell. 17 has also something to do with leds (some form of triggering?). In the current kernel, how is the led activated? Is that gpio 16?

Does anyone have the datasheet for the CPU?

[swamswam_h]

Oh.. and to speed things up. Is there any way that I could install some form of (cpu/kernel) logging or some other software that could give me a clue on the original system software to see what actions it takes? Does such software exist? I have two drives: one with plugout and the other stock lacie software. So swapping is easy as 1-2-3...

[swamswam_h]

I have made a mistake. I must be getting old. The Edmini V2 does NOT have a red led. My other older lacie enclosure did. I must have mixed them up in my mind.

[swamswam_h]

I have found this in a linux distribution. On the board of the edmini there are empty places for a second sata interface and the corresponding second led.

/****************************************************************************
153 * GPIO key
154 ****************************************************************************/
155
156 #define EDMINI_V2_GPIO_KEY_POWER 18
157
158 static struct gpio_keys_button edmini_v2_buttons[] = {
159 {
160 .code = KEY_POWER,
161 .gpio = EDMINI_V2_GPIO_KEY_POWER,
162 .desc = "Power Button",
163 .active_low = 0,
164 },
165 };
166
167 static struct gpio_keys_platform_data edmini_v2_button_data = {
168 .buttons = edmini_v2_buttons,
169 .nbuttons = ARRAY_SIZE(edmini_v2_buttons),
170 };
171
172 static struct platform_device edmini_v2_gpio_buttons = {
173 .name = "gpio-keys",
174 .id = -1,
175 .dev = {
176 .platform_data = &edmini_v2_button_data,
177 },
178 };
179
180 /*****************************************************************************
181 * General Setup
182 ****************************************************************************/
183 static struct orion5x_mpp_mode edminiv2_mpp_modes[] __initdata = {
184 { 0, MPP_UNUSED },
185 { 1, MPP_UNUSED },
186 { 2, MPP_UNUSED },
187 { 3, MPP_GPIO }, /* RTC interrupt */
188 { 4, MPP_UNUSED },
189 { 5, MPP_UNUSED },
190 { 6, MPP_UNUSED },
191 { 7, MPP_UNUSED },
192 { 8, MPP_UNUSED },
193 { 9, MPP_UNUSED },
194 { 10, MPP_UNUSED },
195 { 11, MPP_UNUSED },
196 { 12, MPP_SATA_LED }, /* SATA 0 presence */
197 { 13, MPP_SATA_LED }, /* SATA 1 presence */
198 { 14, MPP_SATA_LED }, /* SATA 0 active */
199 { 15, MPP_SATA_LED }, /* SATA 1 active */
200 /* 16: Power LED control (0 = On, 1 = Off) */
201 { 16, MPP_GPIO },
202 /* 17: Power LED control select (0 = CPLD, 1 = GPIO16) */
203 { 17, MPP_GPIO },
204 /* 18: Power button status (0 = Released, 1 = Pressed) */
205 { 18, MPP_GPIO },
206 { 19, MPP_UNUSED },
207 { -1 }
208 };
209


So.. what else can we deduce from this piece of code:
Power button is on gpio 18
There are several empty or non-existent gpio's: 0-2, 4-11, 13, 15, 19, ... onward to 24/26.

[fvdw]

I have made a mistake. I must be getting old. The Edmini V2 does NOT have a red led. My other older lacie enclosure did. I must have mixed them up in my mind.

ok thanks so no effort to be put in that.
The only way I see to make some progress is if we would know if there are gpio pins controlling fan power HDD power, Ethernet or usb power.
If so a process can be included as explained earlier to "talk" to the kernel to switch those off when powering off and then perform a halt to stop the cpu.
On the other hand is it really worth the effort, poweroff will not be used by many. And as said you can still after the system has halted pull the plug ;)

about the table you posted, yes I know that table it is also present in the vanilla kernel. The gpio pin for the power button will only tell you if the power button is pressed no more no less (it will not power off or power on the system, for that some software needs to run to do something when it detects that the power button is pressed.

Detection if the button is pressed can be done from user land (see the D2 link). But what to do if it is pressed is then again something different as the linux power off command is not working, but it could be used for a reboot. On the the nwsp2 we implemented something similar, if the button is pressed and hold for more then 5 seconds it will initiate a power off, if it is pressed and hold for more then 1 sec and shorter then 5 seconds a reboot is initiated. There is running a small daemon watching if the button is pressed. That could be adapted to work with the edmini_v2. But as said power-off won't work properly

[fvdw]

As promised I recompiled the kernel with now a process that lets you send commands from user land to the kernel.
See PM for kernel nr 7

This communication with the kernel is done by writing commands to a file called "/proc/resource_dump" (without the quotes)
You can check if it is present after booting the NAS with the new kernel

To use you write commands to this file using for example on the command line

Code: Select all

echo cmd > /proc/resource_dump

Replace cmd in this line by one of the following:
blinkon
blinkoff
pledon
pledoff
fanoff
fanon
gostby

example

Code: Select all

echo fanoff > /proc/resource_dump

blinkon: should make the power led blink
blinkoff: should stop blinking of power led
pledon: should switch power led on
pledoff: should switch power led off
fanoff: should switch of the fan (I hope I choose the right GPIO pin (nr 4, I copied this from other setup file lacie)
fanon: should switch the fan on
gostby: will set the power_of inhibit from 0 to 1 and maybe will switch it off (you will need to try and see what happens)

if this works then we have compatibility with the firmware to swictch the power led on/of or make it blink while booting
The fan commands can be used to use the spd8020 fan daemon which can switch the fan on or off dependent on HDD temp assuming your HDD supports temperature reading (you can check that in disk menu of the webinterface , if HDD temp is shown then we can use it to control the fan

Please check what works and what doesn't work

[fvdw]

ps the pressing of the power button should also already be detected by the firmware.
I assume it is a press button (so coming back to position when released)

Check if the the daemon buttons-nwsp2 is running (ps -ef | grep button
It should be running as it is fired up at boot.
To check if the daemon detcts the pressing of the button. press and hold for more then 1 sec but less then 5 seconds and then release it, this should initiate a reboot, holding it longer then 5 seconds and releasing should initiates a poweroff (but that will probably not function correctly as it uses the standard power-off command in Linux.

[swamswam_h]

Well .. mixed results.

Blinkon/off worked as expected
Pledon/off worked as expected
Fanon/off ... so far nothing, but I will check again tomorrow.
gostby ... nothing. System keeps running, connection remains.

I will run some more tests tomorrow when I'm less sleepy.
By the way: if you manually interrupt the fan -> upon release it goes to full speed and then settles at a speed lower than full blast. So there must be some sort of (pwm?) control mechanism there...