• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1]
1  Hardware and U-Boot firmware / Hardware / Re: "New" Marvell Device? ICY IB-NAS 6210 on: October 15, 2011, 03:51:23 AM
I can confirm that the led's are working like bnms describes. I have not found a way to get an event from the power button yet. (Copy and reset are working)

But in the patch is a bug at the mtd partitions. The size of the uImage is 6MB not 4MB

...
I have also adapted the shutdown code from the gpl-sources (strange patches) to the machine setup.



Thanks Arne for pointing out the bug with the MTD partitions and how to power off the device via GPIO #24. I have adapted the patch on the site, but hopefully not in the original strange patch style...

I could not detect any GPIO activity when pressing the power button either. Is the original software able to detect this event?

Btw. do you run this patch on the 6210 or the 6220? I assume that it works on the 6220 as well, but I cannot verify this since I don't have the hardware.

2  Hardware and U-Boot firmware / Hardware / Re: "New" Marvell Device? ICY IB-NAS 6210 on: October 13, 2011, 11:27:50 AM
...
nice wrapup... can you confirm that your outlined kernel patch is working for handling the LEDs and buttons?


Yes, as far as I can tell they both work. I consider the patch as complete; it's just that I did not find the time to document it yet. Any sort of testing is of course highly appreciated.

LEDs:
"nas6210:green:power" is dim green when off and bright green when on.
"nas6210:red:power " is "master enabled" by the green power LED. Thus, nothing happens if the green LED is off.
"nas6210:red:usb_copy" can be toggled on/off

I did not much with the keys, but pressing them seems to generate the respective input events.
3  Hardware and U-Boot firmware / Hardware / Re: "New" Marvell Device? ICY IB-NAS 6210 on: October 03, 2011, 07:00:45 AM
Thanks punaniac! Works like a charm Cheesy.

Since the information how to get your own OS onto the box is rather "distributed", I put together a page that summarizes the steps: http://bit.ly/mZJ48r.

Perhaps it is of use to someone.
4  Hardware and U-Boot firmware / Hardware / Re: Dead SD Card after 3 weeks : caused by Sheevaplug or something else? on: July 23, 2010, 02:58:07 PM
I tried to use the dependencies with the init script to get flashybrid executed at the right place in the boot process automatically.

Cool -- sounds like a completely feasible solution for root file systems on SD cards!

...

It should be possible to use the Default-Start and Required-Start sections to survive runs of update-rc.d. This should keep you safe until flashybrid is udpated. The next step would probably be to submit a defect with the Debian folks to have this done per default -- given all the problems when starting flashybrid later, doing so sounds like a bug to me...

I use Debian Squeeze on an SD card. I changed the /etc/init.d/flashybrid script to read:

Code:
### BEGIN INIT INFO
# Provides:          flashybrid
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Should-Start:      $local_fs
# Should-Stop:       $local_fs
# X-Start-Before:    $network
# X-Stop-After:      $network
# Default-Start:     S
# Default-Stop:      0 6

Thus, the script should be started before networking starts. Then, I removed all the existing links in the other run levels and let insserv recalculate the dependencies:

Code:
cd /etc
rm rc{0,1,2,3,4,5,6}.d/*flashybrid
insserv -v flashybrid

Now, my /etc/rcS.d directory contains:

Code:
...
S14flashybrid
S14procps
S14udev-mtab
S14urandom
S15ifupdown
S16networking
...

Which is where I wanted it to be  Smiley
Pages: [1]