On 12/02/14 11:14, Gordan Bobic wrote:
Hi,
I am trying to get an alternative distro running on my
QNAP TS-421, and the only Linux distro I can find that
has any support for it is Debian ARM, so here I am.
I have managed to defeat most of the problems with it
this far, but u-boot continues to be a problem.
TS-421 doesn't save it's u-boot variables on NAND. As
far as I can tell, they are always saved on a virtual
MTD partition (mtdblock4) in RAM, and overwritten on
every boot with the presets hard-coded in the u-boot
binary (mtdblock0).
I want to boot my distro with rootfs on a SATA disk
rather than /dev/ram as per the standard configuration
and having the console connected for it to boot
correctly every time is not a workable proposition.
(And no, I'm not prepared to use a micro-controller
that permanently sits on the serial port running
an expect script to interrupt the boot and change
the u-boot variables, that would just be silly.)
I have an iConnect (a kirkwood based system) that I have setup in a
similar way. I have standard Debian arm rootfs on a memory stick and
just install a kernel and initrd into the right place in the NAND so
that the u-boot loads it.
I would solve your problem like this:
1. Build a chroot Debian arm system, and then transfer it the SATA drive
or a memory stick. I have instructions for how to do this for armhf on
my blog here:
http://blog.night-shade.org.uk/2013/12/building-a-pure-debian-armhf-rootfs/
2. Boot the system "by hand" the first time, off the network (with tftp)
or from a memory stick. This will need a working Debian kernel, with
some luck the kernel from the linux-image-arm package should work.
3. Build a working initramfs with mkinitramfs once the box has booted.
4. Figure out where on the NAND u-boot expects to find it's
kernel+initrd and write my own there. There is the flash-kernel package
for Debian but it doesn't support the iconnect so I've made my own
fairly simple scripts. My scripts are here:
http://co-lo.night-shade.org.uk/~tim/nand/
The kernel-flash.sh script checks that the MTD layout matches mine which
is very custom so you will need to check the details and change them to
match your setup.
At the moment I am at the stage where I am seriously
considering just taking a hex editor to mtdblock0
and modifying the presets hard-coded in there to the
presets I want. This is not a particularly elegant
solution, it replaces one horrible bodge with
another equally horrible bodge.
Is there a better way? Is there an alternative
u-boot available for use on these, one that can
handle persistent variable saving?
If you can figure out the correct settings for /etc/fw_env.config you
can then use fw_printenv and fw_saveenv from Linux to edit the settings
on mtdblock0