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

Mijzelf wrote:

1) It doesn't have EABI support, and as far as I could find this makes it impossible to chroot Debian.

You can't use the armel port, but 'standard' Debian/arm should work.

Mijzelf wrote:

In order to load my own kernel, I was looking at the reloaded module here: http://www.inreto.de/dns323/reloaded/dn … -0.7.167/. Reading the code it seems to me that the new kernel and initrd are loaded to memory, after which the processor reboots. No trace of the previous boot remains in memory. Right? So this doesn't cost any extra memory, besides the difference in size of both kernels and initrd's?

Correct.

Mijzelf wrote:

I have the sources of my firmware kernel, and I want to compile it with the extra stuff I need, by changing .config. Then I load this kernel with the firmware initrd. This should give me the wanted functionality, without disabling the Zyxel firmware.
A few questions:
1) The lack of EABI keeps me from chrooting Debian, can the presence of EABI keep me from running the firmware stuff?
2) The NSA-220 can run a script at boot, comparable to the fun_plug construction, but called much earlier, before the HD's are mounted and the services are started. When I reload the kernel here, I need a way to see if it's reloaded already, to avoid a loop. Any suggestions?
3) The contents of /proc/cmdline is ...Of course I can change the size, but I can't provide a location. The location is on USB stick, which isn't available when boot starts.

1) The kernel can support both EABI and OABI binaries:

CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y

2) You can append a custom string to the kernel version that will be shown in 'uname -r', e.g. '2.6.25.1-ffp'.

CONFIG_LOCALVERSION="-ffp"

I think, for older kernels this setting is in linux/Makefile and not in .config.

3) No idea. Try and error...

Mijzelf wrote:

'Invalid instruction'

Could be a floating point issue. If the debian arm port uses hardware floating point instructions (I think it does), you need matching floating point emulation in the kernel. Does your kernel have CONFIG_FPE_NWFPE enabled?

Mijzelf wrote:

Code:

# CONFIG_FPE_NWFPE is not set
CONFIG_FPE_FASTFPE=y
CONFIG_VFP=y

That's the wrong options for Debian/arm. See below.

Mijzelf wrote:

Is there a way to ask the kernel itself?

Yes, if you have enabled /proc/config.gz:

# zgrep FP /proc/config.gz 
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_FPE_FASTFPE is not set
# CONFIG_VFP is not set

Mijzelf wrote:

And the enabling of /proc/config.gz is done in .config, I suppose? I don't have an /proc/config.gz.

I think it's these two:

CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y

Mijzelf wrote:

Will enabling CONFIG_FPE_NWFPE break my firmware?

Don't know, but that's possible.

Mijzelf wrote:

Does this mean I don't need EABI?

If possible, use EABI. Because of the different floating point and ABI issues, it can be tricky to find a working configuration. Generally, the floating point emulation is awfully slow, really, really slow. That's why ffp is compiled using a soft-float toolchain. ffp also uses OABI for compatibily reasons.

There's some documentation about Debian OABI/EABI and floats here: http://wiki.debian.org/ArmEabiPort

'Comparable' means 'A two drive NAS with the same processor running Linux', in this case. So yes, I should have to do some porting. For the moment that is beyond my scope. One step a time. But thanks for the link, it's interesting reading.

OK, I sorted that part. Had to include <asm/pgtable-hwdef.h> in proc-arm926.S.

- use 'make zImage' to build the kernel. it will compile arch/arm/boot/zImage, pass the zImage file to realoded.ko instead of vmlinux
- also note that reloaded.ko must not be compiled for the kernel it's going to boot, but for the original kernel.

I build a kernel with the .config which is packed with the sources provided by ZyXEL. Tried to reload twice. The first time my both ssh sessions froze, but my (permanent) ping just continued. I rebooted the box after 15 minutes, and retried. This time ssh froze, and ping started to give timeouts. The box didn't come back again.

The kernel in flash is 2490368 bytes. (dd if=/dev/mtd0 of=./kernel.flash). On my build system there are 3 'kernelish' files, linux/vmlinux (4850717 bytes) linux/arch/arm/boot/Image (3792944 bytes) and linux/arch/arm/boot/zImage (1842632 bytes).
I suppose the flash kernel should be one of these, but none of the sizes fit, or comes close. I tried to reload with kernel.flash either, but it didn't work.

I'm pretty sure my build environment (which is provided by ZyXEL) is OK. I have build several kernel modules which just work.

Ideas?

Mijzelf wrote:

How do I find the machtype for my kernel?

Have a look at arch/arm/tools/mach-types
Also, look at the arch/arm/mach-*/*-setup.c files.

You can try to use proc-arm926.S and proc-macros.S off from NSA-220 kernel.

I did attach reboot log to this post.
859 should be correct machtype for zyxel kernel.

mv88fxx81               MACH_MV88fxx81          MV88fxx81               859

---

Attachments:
nsa220-reboot.txt, Size: 21,714 bytes, Downloads: 1,507

Mijzelf wrote:

Wait, wait, now you're going too fast. What did you do to get this bootlog?

I didn't do anything yet, it' simple reboot log. I have had no time to test reloader out. But I am sure that machtype is 859. If you're using initrd you will need to modify some addresses in reload.S as fonz mentioned. But additionally you may try to use proc-arm926.S and proc-macros.S off from zyxel kernel when you're compiling reloader module.