NSA 325 V2 Debian Is Possible!

I actualy did not think to check for a jtag connection on mine. best to see if you can get uart booting to work first there is a thread on this forum about uart booting and how far I got is above in this thread perhaps you will have better luck?

You setup your usb device wrong. you have a fat32 partition and uboot is trying to load files from it but for 1 the files arent there and 2 its looking at the wrong partition you need to follow the instructions properly.

first partition is boot partition it should contain the files from the boot directory and be ext2.

I had the same issue when I tried to use a HDD. I think the drive wasnt spinning up fast enough to be initialized before boot kicks off. That was the case with my nsa325 v1. I ended up using a small profile flash drive. I played with uboot sleep setting but it didnt help.

In my timezone is 2:52 AM ...so maybe I not think good after whole day, but I think that this is not issue with spinning, because when I have console active again and type "boot" reply is given immediately ... without any seconds waiting:

I got debian running on NSA325v2 from SATA with bodhi's kernel, Buttzy's instructions and some trial and error. Great and thanks for all your work! Especially also to WarheadSE and the ARCH team working on these parts.

Now there are still some minor things about the kernel and the hardware in general that are bugging me and I hope someone can shed a bit of light for me on one or another:

1. The buzzer:
Doesn't look like it is addressed at all in the kernel patch. Are there any plans to add support for it? I had a look at this in the zyxel kernel sources and they seem to drive the buzzer by toggling the buzzer pin (GPIO 44) in a busy loop inside a kernel timer? o_0
Isn't there a more elegant way of doing this?

2. NSA325_GPIO_HDD2_POWER in arch/arm/mach-kirkwood/nsa325-setup.c:
Where does that come from? Didn't find any equivalent in the zyxel sources...?
And while we're at it: Any idea what this HTP pin on GPIO43 is? (it's also in the zyxel sources)

3. WOL:
Again: Didn't find anything related in the patch. Any plans?

4. The MCU:
AFAIK it has 3 main tasks:
a) A watchdog timer that pulls the SoC reset line if GPIO14 is not pulled high
b) "smart" fan speed control via PWM
c) SPI-like interface to report temperature and fan speed to SoC

Is this really all? If they went to the length to attach a whole MCU to their design instead of some cheap i2c sensors and controllers, why didn't they make it do something actually useful? Like a method for software fan speed control by SoC?
Or attach the buzzer to a PWM capable pin?
And I don't know if they did, but it surely would have been a smart idea to hook the reset switch also to a MCU input to implement a kind of intelligent reset system in combination with their funny watchdog...

And a bit OT:
Did anyone already take a look at zyxel's uBoot sources to compile a new version with more features (FDT support anyone)?

Buzzer:
Well, you could write a wrapper around that, but that's really the only way to drive it since it is attached to GPIO, not PWM. You might be able to semi-synthezie PWM.

HDD2_POWER:
That's take from the the init bits on what GPIO are being set high at boot (and me manually pinning out each GPIO to confirm) from ZyXEL stock. It was a PITA to find, and in the unified 2013.10-kirkwood we're going to make it turn it on by default.

MCU:
I hate ZyXEL's "creative" EE's. Simple as that. Seriously? Use the WOL feature of the PHY to communicate with the SoC via RGMII to control the 2nd LED into a tri-state and twip the bit thereon to get the MCU to listen and stop resetting the board?? OH MY GOD.

Please, enter the code that you see below in the input field.
This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right.
If you enter the wrong code, a new image is created and you get
another chance to enter it right.