Lacie EdMini V2 - noob review - speed question

[fvdw]

probably yes but I can not guarantee that :dontknow you will only know when testing it :whistle

[fvdw]

this evening I looked again on the internet and saw that I may have not used a proper setting of gpio 24 to force power off with gpio 24, I used the orion_set_valid function.
it was as it was used on the 2Big. maybe this is not enough and only set the pin as valid but not a value
I will compile a kernel where it will set the value to 1 using the gpio_set_value function and send this kernel to you for a trial.

ps We can export gpio24 to user land unfortunate, so we will do it with the /proc/resource_dump method

--edit pm send with new kernel (2.6.39.4)

[swamswam_h]

Hi,
I will be on holiday the coming week, so a response on the new kernel might take a while. I asked the ubook-ARM coordinator for additional info on the GPIO's or if he knew anyone that had additional info. He asked around and this is the 'harvest':

------original email is from A. Aribaud -------
Cc:ing the Lacie-NAS list as it gather much higher authorities that I
ever will be :) -- maybe you will have to register for your replies to
appear there. Or you can try #lacie-nas on irc.freenode.net.

What I can tell you, though, is my latest understanding of the ED Mini
V2 GPIOs. They can be found in the U-Boot project. Look in the ARM git
repo at http://git.denx.de/?p=u-boot/u-boot-arm.git;a=summary for file
include/configs/edminiv2.h. You'll see a big fat comment with the GPIO
descriptions. Here's a copy-paste:

/*
* Board-specific values for Orion5x GPIO low level init:
* - GPIO3 is input (RTC interrupt)
* - GPIO16 is Power LED control (0 = on, 1 = off)
* - GPIO17 is Power LED source select (0 = CPLD, 1 = GPIO16)
* - GPIO18 is Power Button status (0 = Released, 1 = Pressed)
* - GPIO19 is SATA disk power toggle (toggles on 0-to-1)
* - GPIO22 is SATA disk power status ()
* - GPIO23 is supply status for SATA disk ()
* - GPIO24 is supply control for board (write 1 to power off)
* Last GPIO is 25, further bits are supposed to be 0.
* Enable mask has ones for INPUT, 0 for OUTPUT.
* Default is LED ON, board ON :)
*/

As you can see, board off is easy enough to attain: write 1 to GPIO 24.
Note that from then on, the only way out is power-on through the
button; WOL won't work this way.

Fan control, OTOH, have no support in U-Boot (and don't really require
any in a bootloader) or Linux (shame on me...) so I can't help you
there. IIRC, there is no fan control on the ED Mini V2, at least, I
don't remember finding any in:

http://www.lacie.com/intl/support/drive ... m?id=10099

Note that the kernel source tree in this archive is awfully old and
needlessly complex. Maybe somewhere in this mess is the fan control
you're looking for.
------ END of email ------

Then two other people responded:

------ Email from S. Guinot ------

IRC the fan on ED Mini V2 is entirely controlled by hardware. You
should be able to check this easily.

To shutdown the board, you could turn on the GPIO 24. You will find an
obsolete Linux patch in attachment. Feel free to update it. Or as an
alternative, if you use the LaCie stock U-Boot, you could ask U-Boot to
shutdown the board:

- Turn on the power flag in the I2C EEPROM (maybe byte 6).
- Reboot

There are some pros and cons with both this methods.

Please, let us know your progress :)
------ END of email ------
I have attached his linux patch to this post for reference

And the other:
------ Original email by C. Moore -------
>IRC the fan on ED Mini V2 is entirely controlled by hardware. You
>should be able to check this easily.

I had the impression that the fan is always on. I don't think mine ever turned off :(

For me the big problem with the GPIO 24 method is that it is not persistent across a power outage :(
With this method, when power comes back after a power outage, the EDmini V2 will boot.

I think the I2C method is the way to go.
I circulated an experimental patch for this a while back.
The main problem with this is that I found no elegant way to write to the I2C EEPROM from kernel space.
My method worked but was so messy that I didn't dare submit it to mainline :(

I once saw a patch to the I2C subsystem which provided a hook making it easier to access I2C from kernel space.
However I don't think it ever made it into the kernel :(

If anyone knows of a clean and elegant way of writing to I2C from kernel space, I should be most interested ;-)
---- END of email ----

[fvdw]

interesting.
The new kernel I have sent you uses the method described setting gpio24 value to 1.
I use the process via /proc/resource_dump instead of the function proposed in the patch. This to get compatibility with what we use for the network space 1 in that case we can use the same script as on nwsp1 and spd8020 to switch down this device.

ps writing to the eeprom from userland is possible. No need to do it the kernel. Of course the question remains how to do that in a save way

It could as simple as this (on nwsp2 the eeprom is read/writeable from userland)
copy the eeprom content using (assuming your eeprom is in the same folder as on nwsp2 otherwise adapt accordingly)

Code: Select all

cat /sys/bus/i2c/devices/0-0050/eeprom > eeprom.bin

Now load this file in a hex editor and change power off byte using a hex editor, save the file as eeprom2.bin
write it new file

Code: Select all

cat eeprom2.bin > /sys/bus/i2c/devices/0-0050/eeprom

I suppose that after that you need to initiate a reboot and u-boot will power it off

ps I can not guarantee that it will work or cause problems with your nas. But reading the e-mails from the experts it should work
After writing to the eeprom you could read it again to see if the change was made before doing the reboot

[swamswam_h]

Well. The kernel works. After issuing the echo gostby > /proc/resource_dump the unit immediately 'cuts the power'. Hard disk shuts down, fan stops, leds go out, network-connection leds go out.
The unit is then non-responsive over network (obviously as the PHY doesn't support WOL and it's also apparently disabled).
After this shutdown, CPU temperature drops significantly and after some time the CPU feels cold. The xilinx unit seems to remain noticeably warmer as does it's power supply. But in what state is the system then? It is not in uboot given that:
After pressing the power button the network leds light up and nothing happens. Pressing the power button again or keeping it pressed for a couple of seconds leads to nothing. The CPU reheats to normal operating values. So after the button press the CPU is woken up again, but seems to be stuck somewhere or is waiting for something 'special' to happen.

So our theory was:
1) EEPPROM Flag is set
2) The system is halted
3) The system is reset
4) Uboot takes over control, sees the flag and kills power

Now what we have is that the flag is NOT set. The system is brutally 'killed' by cutting power. Apparently some sort of logic device still rules the system (xilinx?) and starts the thing up againg after the button press. The CPU goes through it's startup routine, starts Uboot... and does nothing. Why? The eeprom flag is not set, so it should just continue booting? Right?

[fvdw]

yes no flag is set the eeprom is not touched only the gpio value of pin 24, no more no less

what you could try is disconnecting the AC power, press the power button to drain capacitors and then reconnect power and see if it starts.
Maybe the gpio value is kept while power stays connected

this what the kernel does when finding gostby in the /proc/resource_dump file

Code: Select all

   
#define EDMINI_V2_GPIO_INHIBIT_POWER_OFF    24

/* When written to the /proc/resource_dump file this function is called */

int evb_resource_dump_write (struct file *file, const char *buffer,
                      unsigned long count, void *data) {

    int len;
    int command;
    int ret;
    if (count > EVB_MAX_SIZE)
       len = EVB_MAX_SIZE;
      else
       len=count;

if(!strncmp (buffer , "gostby" , 6)) {
        gpio_set_value(EDMINI_V2_GPIO_INHIBIT_POWER_OFF, 1);
   command = 1;
   return len;
        }

<snip>

}


[swamswam_h]

Yes! It was actually that simple. After approximately 20 seconds waiting and pushing the button it boots normally.

I booted a linux machine to see if uboot is active after cycling the power. The gpio24 seems to remain active. The CLUNC - netwerk terminal connected after a short power cycle and after issuing the 'boot' command it just booted. Nifty little piece of software this uboot. Lots of options in there including EEPROM functionalities!
So, onwards... let's try the eeprom.

[swamswam_h]

Apparently i do not have permission to issue:
cat eeprom_off.bin > /sys/bus/i2c/devices/0-0050/eeprom

Am i doing something wrong here?

[fvdw]

on my nwsp2 the rights of this folder are rw for the user root, so you must perform it as user root

I also seems to be able to change permission of that file using chmod command

below a screenshot of eeprom settings on the nwsp2

[swamswam_h]

Can't write to it. I'm logged in via ssh as root. I have changed the permissions via 'chmod 777 eeprom', but no go. The permissions are now -rwxrwxrwx with owner and group both as 'root'. I can't write anything to the directory as well (its a link I guess).