DSM-G600, DNS-3xx and NSA-220 Hack Forum

Afaict, vanilla kernels don't support B1 hardware, yet. So reloaded is DNS-323 rev A1 only, for now.

Fonz, can you give a little more detail on why it doesn't work with B1 hardware.
Also, do you expect that we will soon be able to get ffp-reloaded working with B1 hardware?

Thanks

puterboy wrote:

Couple of other questions on ffp-reloaded that weren't clear from the wiki:
1. Does it need to be reloaded each time or does it happen automatically after the first boot?
2. Does the native d-link web interface still work? If not, can it be made to work by copying over files from /sys/crfs (and other relevant places)?
3. Is there any danger of "bricking" the dns-323 or requiring a serial interface intervention?
4. Is the full functionality of the 2.6.25 kernel accessible?
5. Will the 2.6.26 kernels work too?

1. It boots once. When you reboot, you're back to normal.
2. No. No part of the firmware will be loaded or used in any way.
3. I'm not aware of any significant risks, but I also won't promise anything. The disclaimer at http://www.inreto.de/dns323/fun-plug/0.5/ applies as usual.
4. Yes.
5. 2.6.25.1 works best at the moment. There's small problems with 2.6.26.

I'm willing to try to help out here to get it to work with rev B1 however I can.
- Can you point me to anybody who is working on it so I can offer assistance?
- If nobody is working on it, are there any pointers and background that you can give me to get me started on trying to figure this out? (or is it too complicated and kernel-hacky)

I would be happy to start digging.
But I would probably need to know as much as I could about the problem so I could start searching intelligently and asking the right questions.
Other than "SATA doesn't work" can you be a little more specific about what goes wrong in rev B1 vs. what goes right in rev A1?
Also, are you just using a vanilla 2.6.25 kernel compiled for arm cpu's or did you have to make some changes to make it work on rev A1?

I am concerned though that without a serial port, I may not be able to see the boot messages about what is going right & wrong early in the boot. Do you see that as a big problem?

Finally, does the original d-link kernel differ between versions A1 vs B1 or do they use the same kernel? Because that could help narrow down the source of the problem.

Fonz - any thoughts on whether the above may be the source of the A1 vs. B1 differences?

Also, is it fair to assume that ffp-reloaded could easily be modified to make a USB stick to be root, rather than /mnt/HD_a2?

OK. I tried it but the machine hangs.

nohup.out shows the following:
+ cd /ffp/boot
+ ./reload.sh -I root=/dev/sda2
kernel=/mnt/HD_a2/ffp/boot/zImage-2.6.12.6
initrd=
machtype=1542
cmdline=console=ttyS0,115200 root=/dev/sda2 ip=192.168.1.138::192.168.1.1:255.25
5.255.0:raider:egiga0:none

Booting in 3 seconds. Please Ctrl-C to abort...
+ /ffp/etc/rc stop
Stopping sshd
Stopping telnetd
Stopping unfsd
Stopping rpc.portmap
+ killall5 -15
+ sleep 5
+ killall5 -9
+ sync
+ swapoff -a
+ umount -a -r
umount: can't remount /dev/md0 read-only
umount: can't remount /dev/root read-only
umount: can't remount rootfs read-only
+ sync


I wonder about a couple of things.
1. Given that I am using RAID1, should I have root=/dev/md0 rather than root=/dev/sda2
2. There is no inittrd. Do I need to make one to load some modules needed for RAID or to run something like mdadm -A to start the array (I know that in x386 linux I need to have an mdadm.conf file in my inittrd)
3. The 2.6.12.6 kernel (that I took from fsck) doesn't seem to come with any modules. Is that a problem?

puterboy wrote:

Or would I have similar issues with needing an initrd to load the usb drivers this time?

Depends on the kernel. The kernels I provide all have usb-storage compiled in. I suggest you try the fsck ramdisks first (boots into initramfs, so raid doesn't matter here). It's true that you need to change the command line for RAID, root=/dev/md0 is not sufficient though. Please have a look at the kernel docs for the details at /usr/src/linux/Documentation/md.txt (or online at http://git.kernel.org/?p=linux/kernel/g … xt;hb=HEAD )

puterboy wrote:

I'm pretty sure I could fix it if I had a sample initrd to play but I have no idea what a base initrd would look like for ffp-reloaded and  I don't know what I would need to include as a base before adding in RAID support.

Assuming SATA works (you can check this in the fsck ramdisk, just try to mount a disk, or run e2fsck), you (most likely) won't need an extra initrd. People confirmed that booting from the raid works if you pass the correct kernel command line options (using 2.6.25.1, however). If I remember correctly, the command line looks sth like:

... md=0,/dev/sda2,/dev/sdb2 root=/dev/md0 init=/ffp/sbin/init

puterboy wrote:

Any ideas on what I can do to fix/debug this? (I don't have a serial connection)

reload.sh should print some more info before booting. Can you post output of that script?

puterboy wrote:

+ ./reload.sh -I md=0,/dev/sda2,/dev/sdb2 root=/dev/md0 init=/ffp/sbin/init
kernel=/mnt/HD_a2/ffp/boot/zImage-2.6.12.6
initrd=
machtype=1542
cmdline=console=ttyS0,115200 md=0,/dev/sda2,/dev/sdb2 root=/dev/md0 init=/ffp/sbin/init ip=192.168.1.138::192.168.1.1:255.255.255.0:raider:egiga0:none

This is the part I'm interested in. The ffp-reloaded reload script was made for recent kernels. Seems I forgot some small, but important detail (that is obviously present in the fsck reload script).

machtype must be 526 for 2.6.12.6 kernels. You can change that in the script or try adding "-m 526" to the reload.sh command line.