Lacie EdMini V2 - noob review - speed question

[fvdw]

after setting gostby perform a software power-off and see if then it powers off, you can use the webinterface to perform the shutdown command after setting gostby

fanon/fanoff, so apparently the gpio pin 4 is not the one responsible for keeping the fan running

What about the power button ? Did you try that

[swamswam_h]

after issuing the echo gostby > /proc/resource_dump and then issuing a shutdown from the webinterface everything remains as usual. The system goes down and the fan, led and network (+ cpu) stay on. Hdd goes in sleep/standby though.

powerbutton works! pressing it 'firmly' (that is: longer than just a short push/stacato) brings the machine to a shutdown and then reboots again.
Once though the fan momentarily paused, immediately spun up again full blast and quickly back to normal levels.
Same for the hdd: it rattled (parked head?) and immediately woke up. But I can't replicate it... But that WAS exactly how it should be!

After 32 pings (can't find my timer) the unit is up and running again. So I guess what happens is that we actually come quite close to having replicated the lacie shutdown procedure (when pushing the power button as a shutdown signal). The only thing left to do is (for me:) find out what caused the above mentioned 'succesfull' shutdown. Because other than that we 'just' need to write the eeprom value, because now after the reboot the uboot takes over again, reads the flag as 'reboot' and boots the kernel again.

[fvdw]

the power button just calls the poweroff or reboot command dependent on how long it is pressed and hold.
pressing and holding it for more then 1 second but release it before 5 seconds have passed will cause a reboot.
pressing and holding it for more then 5 seconds before releasing again initiate a poweroff command

Its perculiar the HDD goes to standby when perfoming a shutdown. We could try to try what happens using the other gpio pins, but it is well possible that the fan is controlled via a separate circuit and not by gpio (I2C). You can look in /sys/bus/i2c/devices/ what is defined there

ps as we have moved on to 13-0 I think I should compile a 2.6.39.4 kernel for you as the 2.6.33.1 you have now is not compatible with he new release.

[fvdw]

ps can you test if you export gpio3 ?

Code: Select all

echo 3 > /sys/class/gpio/export

and if after that a a folder /sys/class/gpio/gpio3 exists ?

you can unexport it again by

Code: Select all

echo 3 > /sys/class/gpio/unexport

after that gpio3 folder should disappear again

(gpio3 is rtc interrupt don't change setting, its only a test to see how to define gpio to be able to export them to user land)

Think i know why we can not export gpio pins or why they might have no effect

[swamswam_h]

I have finally found the time to upgrade to version 13 of the firmware. Works like a charm. After upgrading I noticed that the powerled on/off works from the webinterface! Nice... I had to reset the trigger for disk-activity manually (could this trigger function (on disk, lan, whatever) be incorporated in a next installment of the firmware? It's a nice-to-have feature I think).

Installed the custom kernel you PM'ed me. Works fine.

Exporting gpio 3 gave nothing. Exporting 4 worked... so fearless (and clueless... that might have helped) I exported all numbers from 1 to 30. And 4, 5, 17 and 19 showed up.
So... now what.. How to go from here in a more scientific way. Or should I just 'poke around' echoing "255", "1" or "0" to these gpio's?

[fvdw]

gpio 4 and 5 are pins that are used by other lacie devices to control the fan, I can not find information on the Internet if this is also the case for edmini_v2
Its also possible that it is controlled by another chip on the motherboard
What you could do is write 0 and 1 to them as value trying very combination to see if that makes the fan stop
so
gpio4 gpio5
0 0
1 0
1 1
0 1

gpio17 seems to switch control for power led from gpio 16 to "CPLD". This must be another chip on the MB that also could control the fan, is there a chip with name Altera on you MB?)
gpio19 has no function so to see
If the above brings nothing then I do not see on this moments possibilities to improve situation further :geek: and you will need to live with the one limitation that the edmin_v2 can not be switched off completely via software

[swamswam_h]

Even if we get no further than this, the new firmware is still way better than the original (and expandable as well). Again, I must compliment you on this - in my opinion - great piece of work.
My other NASses shutdown automatically during nighttime after backup jobs are done. A matter of personal preference; i feel it is safer - no one has to use these machines when I sleep, they are less prone to damage (lightning or any other way) and it's a way of reducing my power consumption.
If I were to implement scheduling of shutdown (so a timer can kill power when the machines have shutdown properly) what should I do then? Can I build a subpage somewhere in the web interface that issues an 'at xx:yy shutdown'? Of should I pursue a different approach?
Is there an easy or smart way to set the eeprom value to the values needed for uboot to go in the 'waiting for a key press'-mode after a reboot/shutdown? So it wont automatically reboot the fvdw firmware? (and that key can be the power button in the original uboot firmware which is still intact, right?).

[fvdw]

thanks for the compliments, the credits also go to Jocko who added many new features and enhancements of the webinterface

fvdw-sl-13-0 have a menu where you can schedule nas shutdown at certain time (cron task scheduler menu)

Is there an easy or smart way to set the eeprom value to the values needed for uboot to go in the 'waiting for a key press'-mode after a reboot/shutdown? So it wont automatically reboot the fvdw firmware? (and that key can be the power button in the original uboot firmware which is still intact, right?).

:dontknow I can not answer this question, the eeprom can be written to when the nas is running but I do not know a 'safe' method. And as said earlier if the eeprom is set it might be that it waits forever to continue boot as I don't know if the original firmware had a program resetting the eeprom. But as there is no information on the internet on this, so nobody was able to solve it. I would not take the risk to brick the nas.

[swamswam_h]

Neh... bricking it seems a bit 'too much'. But if the lacie uboot would rewrite the flag upon receiving the button press 'event' then it would be somewhere in the uboot source code, right?

No combination of gpio 4 and 5 does anything to deactivate the fan. The values get written correctly (cat /sys/class/gpio/gpio4/value), but nothing happens.
I opened up my Edmini and noticed something. There is a CPLD on the motherboard. CPLD = a newer, high performance PAL - sort of. So a programmable logic array. There is hardly a reason why that should be on there except if it actually controls something. My guess... that's the IC that controls the fan, temperature sensor. The datasheet is readily available, but the contents of the IC itself are of course a 'secret' only lacie knows about. Has anyone ever heard of the way this IC works in any other Lacie NAS? Is it present on other NASses?
I took some photo's of the motherboard. Perhaps it would be nice to archive them somewhere on the plugout site for reference?

And as a nice feature: the PCB has a second sata connector. All that is lacking are four small capacitors and the connector itself. Now... where is my soldering iron... I feel a project coming up.
This could also mean that the PCB with slightly different firmware was used in a dual HDD configuration in a different NAS. Does anyone know if that would be the 2Big network?

[swamswam_h]

And on the subject of bricking things. If after setting the eeprom flag and the reboot the thing refuses to boot. Would it be bootable again if I hook up the original HDD with the complete and functional Lacie software on it? My guess is that it would, or do I forget a nasty little detail somewhere?
I knew that it could be handy to leave the original disk intact... :-D