[LEDE-DEV] adding support to kirkwood devices

[Alberto Bursi]

I'm looking to see if I can add a couple of Zyxel devices I own in LEDE 
(NSA310 and NSA325), possibly more as I can take dtb files for quite a 
few other out-of-tree Kirkwood devices from a Debian-on-Kirkwood 
community I know.

I see you have already the NSA310s in the source, so I was grepping 
around to copy that for NSA310 too.

Most things were easy to do, but I'm stumped in 
target/linux/kirkwood/image/Makefile

I would like to have the build system generate a ubifs for rootfs, as 
this device has 48 MB for each rootfs (it has dual firmware so on flash 
there is two kernels and two rootfs), but I'm not understanding how it 
is done.

Is there any kirkwood device that has it (I see some hints they do as 
there are variables with info needed to build the ubifs, but where is 
this done)?

If not, is there some other device in LEDE that builds an ubifs I can copy?


Also, the NSA310 is using a realtek ethernet chip, I did some 
preliminary tests with OpenWRT CC, and had to integrate a realtek driver 
from the packages for it to work.
Is it ok to just add such package in the device profile (i.e. default 
packages to install in rootfs) or do I need to add that as a built-in 
module to its kernel configuration?


Last but not least, I've nearly finished developing a script that can 
download install LEDE in Kirkwood devices (probably elsewhere too, as 
long as it is ARM) by using its own toolbox of binaries. (I actually 
made it to install a custom modern uboot, format a drive and install a 
Debian ARM system in it, for the abovementioned community, but making a 
fork that installs LEDE instead is very easy)

Most NAS boxes with a Kirkwood SoC have some kind of telnet backdoor 
that can be easily exploited (long since documented in tutorials), or 
failing that they usually offer UART/TTL pins on the board to get at a 
command line interface. Hence why I made the script.

Do you have some need for it?

I know Zyxel devices have a remarkably complex firmware upgrade binary 
that can be decompressed only by closed-source ARM binary tools from 
stock firmware (long since extracted), I was hoping to avoid 
reverse-engineering that.


Any tips or help is welcome


-Alberto