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

I confirmed the issue is purely the size of the initrd by constructing two identical initrd's differing only in that one of them had a junk file about 1.3 MB long so that one weighed in at 3.8MB and the other at about 5.1MB. The first booted, the second hung.

Hmmm but this doesn't really explain to me why the version fails where I reduce the size of kernel to 130 (2.1 MB) while increasing the size of initrd to 350 (5.6 MB) which preserves the total number of segments at 480 and should safely fit my kernel (1.3 MB) and my initrd (4.9 MB).

And it shouldn't be an abort on out of memory issue either since the rc.S code loads the 480 segments whether or not there is something there (or at least so i assume). Plus since I am starting loading the initrd now 70 segments (0.9MB) earlier, the end of my initrd is not much past where it was before.

So, it makes me wonder whether there is a separate limit for initrd... (either that or the calculations on segment size are a fair bit off)

Well googling, I found this interesting document that explains the arm boot process http://www.simtec.co.uk/products/SWLIN0 … ticle.html
Indeed it makes the reload.ko module code now much more understandable.

In any case in addition to the ATAG_INITRD2 tag which reload.ko uses to set the size of the *compressed* initrd. It also mentions a tag called ATAG_RAMDISK which sets the size of the *decompressed* initrd. This ATAG is not mentioned in the reload.ko so maybe it assumes a default. And maybe that is part of my problem.

I tried patching the reload.ko to add that tag but either my code is wrong or something else is going on.
Note the code itself works in the sense that it works ok with my smaller initrd but it still hangs when booting the larger 5MB initrd. Note that the smaller initrd decompresses to about 10MB while the larger one decompresses to about 12MB -- both should fit easily within the 16MB ramdisk size I define.

--- main.c.jorig        2007-06-13 17:59:00.905733382 -0400
+++ main.c      2011-01-07 10:58:38.596675379 -0500
@@ -147,6 +147,15 @@
         t->u.mem.start = mem_start;

         if (initrd_size > 0) {
+                 int ramdisk_size=16384; /* 16MB ram disk (size is in K) */
+                printk("RAMDISK: start %08lx size %d KB\n", 0x0lu, ramdisk_size);
+                t = tag_next(t);
+                t->hdr.size = tag_size(tag_ramdisk); /* size tag */
+                t->hdr.tag = ATAG_RAMDISK; /* Ramdisk tag */
+                t->u.ramdisk.flags = 0;  /* Load the ramdisk */
+                t->u.ramdisk.size = ramdisk_size; /* Decompressed ramdisk size */
+                t->u.ramdisk.start = 0;  /* Unused */
+
                 printk("INITRD: start %08lx size %d\n", 0x800000lu, initrd_size);
                 t = tag_next(t);
                 t->hdr.size = tag_size(tag_initrd);


In any case according to the docs, the only limitations that arm booting seems to have are:
1. The decompressed kernel size must be <4MB
2. There must be enough memory to decompress the initrd on booting
3. The decompressed initrd must align within a single memory region
4. The decompressed initrd must be aligned to a page boundary (typically 4K)
5. The decompressed initrd must not conflict with the memory the zImage head code uses to decompress the kernel or it will be overwritten

#2 seems like the only one that could even potentionally be the problem here.
Is it possible that there is not enough free memory to decompress my larger initrd (and this wouldn't show up in the logs since it would presumably cause issues so early in the boot process - though I imagine if I had a serial console, I might be able to see it)

Now if I am understanding things correctly:
1. There *is* enough memory to load the compressed kernel and initrd into memory as shown by my dmesg debug code in the previous message. I.E., the reload module seems to run just fine up until the reboot is actually triggered.
2. Once the reboot is triggered, I would think that *all* of the memory from the initial boot is cleared except for the area that the ATAGs reserve for the compressed kernel, the initrd, the tag table and perhaps some small boot code fragments.  My point is that once you get to this point, I would think that 64MB would be sufficient to hold a 1.3MB compressed kernel, a less than 4MB decompressed kernel, a 5MB compressed initrd and a 12MB decompressed initrd. And I would think there would be enough memory to go through the boot process until the kernel chroot's to the real root and frees up the 12MB ram disk memory.

Now I'm probably wrong here, but I wanted to lay out my thinking of why I don't see where the memory problem would be once we know that reload.ko has enough memory to get up to the reboot...

3

Fonz is there potentially a trivial error in your code in the reloaded_init() function.
Specifically, should the line:
flush_icache_range((unsigned long)dns323_reboot_code, (unsigned long)dns323_reboot_code + dns323_reboot_size);
really instead be:
flush_icache_range((unsigned long)dns323_reboot_code, (unsigned long)dns323_reboot_code + dns323_reboot_size-1);

Not sure it makes any real difference but I noticed it in the code. I'm assuming that the arguments of the function are start and end but you are giving start and end+1 (I think)

puterboy wrote:

Any pointers on documentation of how to get it to work with ARM and the dns-323?

I've attached the script I use to start ffp in qemu. You may need to change the kernel command line or the /ffp/... paths to your initrd to start.

---

Attachments:
qemu-arm.sh, Size: 797 bytes, Downloads: 535

Thanks Fonz.
Unfortunately, I am having trouble getting the NFS mount of root to work.
I get the following error message:

eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
IP-Config: Complete:
     device=eth0, addr=192.168.1.101, mask=255.255.255.0, gw=192.168.1.100,
     host=qemu, domain=, nis-domain=(none),
     bootserver=255.255.255.255, rootserver=192.168.1.145, rootpath=
Looking up port of RPC 100003/3 on 192.168.1.100
rpcbind: server 192.168.1.100 not responding, timed out
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/3 on 192.168.1.100
rpcbind: server 192.168.1.100 not responding, timed out
Root-NFS: Unable to get mountd port number from server, using default
Root-NFS: Server returned error -5 while mounting /mnt/share/qemu/arm-sysroot

where I changed the append line to:
-append "root=/dev/nfs nfsroot=192.168.1.100:$sysroot,nfsvers=3 ip=192.168.1.101::192.168.1.100:255.255.255.0:qemu:: console=ttyAMA0 rw init=$init panic=1 $extra"

-------
NFS itself is working since I am able to mount the volume directly from the command line from any machine on my LAN
I have tried both with and without my firewall so that is not a problem (and indeed /var/log/messages shows nothing)

I am wondering whether this is a networking issue since:
1. I can't ping 192.168.1.101 (even though the console says eth0 is up)
2. I don't get any messages in /var/log/messages (so nothing is wrongly hitting my firewall and no problems with tcp wrappers).

Any thoughts on what could be wrong?
And if it is a network issue do I need to be doing anything special on my server?

(note: I added the option nfsvers=3 since I run NFS version 3, but the issue occurs with or without that parameter)

yes, 10.0.2.0/24 is built into qemu.

Now everything boots *except* I keep getting the error message:

tty '': '/ffp/sbin/getty -L ttyS0 115200 vt100'
     qemu auth.err getty[344]: can't open '/dev/ttyS0': No such device or address

I tried copying over /dev/ttyS0 from my dns-323 to sysroot/dev but it still doesn't work.

Then I tried changing the line in /ffp/etc/inittab to: ttyAMA0
but now I get the same error with ttyAMA0:
    qemu auth.err getty[345]: can't open '/dev/ttyAMA0': No such device or address
And /dev/ttyAMA0 does exist in arm-sysroot/dev

I also tried using minicom to open /dev/ttys0 on the *host*
So what do I need to do to get the console working so that I can log in over a console from the host.
i.e. how do I set up and access the emulated arm using a serial console

------

Also, I can't seem to ping the machine @10.0.2.15
I did the following
     sudo tunctl -u $(whoami) -t tap0
     sudo ifconfig tap0 10.0.2.2 netmask 255.255.255.0

I also tried:
    sudo route add -net 10.0.2.0 netmask 255.255.255.0 gw <my host computer ip>

But while I can ping 10.0.2.2 (which is the address on my computer now), I can't ping 10.0.2.15 which should be the address of the arm machine.

Last edited by puterboy (2011-01-09 23:16:38)

Thanks Fonz. [IGNORE THIS MESSAGE - CORRECTED LATER]
By the way as an UPDATE on the original size of the reloaded and kernel initrd.
Here are some observations.
1. The zImage is loaded starting at 0x8000 (=32KiB) while the initrd is loaded starting at -0x800000 (=8MiB).

2. The limit on the initrd seems more to do with the later decompression of the initrd than the size of the compressed initrd.
In fact, I tried the following experiments:
- Base initrd (3.88 MB compressed, 10MB decompressed --> works
- Base initrd + 2.5MB file of zeros (3.88MB compressed, 12.4MB decompressed -->hangs
So the issue seems to be more whether it is able to decompress a larger initrd since the compressed 2.5MB file of all zeros doesn't add any space to the compressed base initrd.
Also, I can verify using printk's that the reloaded.ko module runs seemingly fine in both cases until the dns323_reboot() statement.

So I guess I am wondering whether there is a limit on the size of the decompressed initrd.
But it seems like total free memory is not the issue since if it can get through the reloaded.ko code (or at least up to the final printk), I would think that then all the memory is cleared so that in the 64MB of RAM there should be space for the kernel (<4MB) and the 12MB decompressed initrd

I really need to figure this out since I need the bigger initrd in order to get lvm and raid working on debian.

But I am at a loss what to do.

Any suggestions on how to debug further?
(I don't think qemu can help me further since I'm close to 100% sure it is a size of the decompressed initrd issue and not to do with the content or the size of the compressed initrd)

Thanks

Last edited by puterboy (2011-01-11 04:27:52)

CORRECTION. I reran my experiments more carefully:
initrd-base: [3.88 MB compressed, 10.1 MB decompressed] --> WORKS
initrd-base prepended with archive of zeros (using cpio):  [3.88 MB compressed, 12.7 MB decompressed] --> WORKS
initrd-base postpended with archive of zeros (using cpio):  [3.88 MB compressed, 12.7 MB decompressed] --> WORKS
initrd-base prepended with archive of non-zero files (using cpio):  [5.03 MB compressed, 12.7 MB decompressed] --> HANGS
initrd-base postpended with archive of non-zero files (using cpio):  [5.03 MB compressed, 12.7 MB decompressed] --> HANGS

So CONTRARY to what I mistakenly said before, the issue seems to be the size of the decompressed initrd which makes more sense since it needs to be crammed in while the system is still more or less running. Plus with the initrd starting at 3.2MB [0x800000], perhaps it overwrites something critical.
I wish I had a serial port to verify what is happening...

So, it seems to boil back down to what Fonz said earlier that there is a limitation in how reboot.S works. Because again, it all seems to work fine up until reboot.S is called and based on the above experiments, it seems to work fine after the decompression...
Now if only I understood assembler better, I could play with that code...

Note the appended file(s) *do not* mess with the *function* of the initrd itself since they are stored in ./temp2 and hence only contribute to the size of the decompressed and compressed initrds.

After spending the day learning arm assembly language and figuring out the basics of kernel memory management ,  I finally figured out how to at least get it to boot with my bigger initrd.
This required changing the start of the kernel initrd from 0x8000000 (8MiB) to 0x600000 (6MiB) leaving enough room for my compressed initrd to be copied by reboot.S  (changes needed to be made to both reboot.S and to main.c)

I also made a slew of changes to main.c and reboot.S that both automate some of this and allow more efficient memory allocation.

1.  I added an assembler constants INITRD_START and INITRD_SIZE and associated global variable dns323_initrd_start and dns323_initrd_size to allow one to change the start and maximum size of the initrd by just changing these 2 constants in reboot.S
For completeness, I similarly added constants TAG_START and KERNEL_START along with the corresponding global variables dns323_tag_start and dns323_kernel_start to allow changing the start point of the tag list and the kernel, respectively.

2. I changed the .rept number to be 50 times INITRD_SIZE (the maximum expected initrd in MiB) and left a corresponding 200 repeats for the kernel (since the maximum kernel size on arm systems is 4MiB). This corresponds to 25 segments per MiB and a total of 100 segments for the kernel. This leaves plenty of room (unless your memory is really fragmented) since this gives an average of 40K per segment compared with the attempted kmalloc segment size of 32 * PAGE_SIZE = 128KiB. NOTE: Any compile-time limitation on the sum of the .rept's for kernel and initrd is due to the fact that page-relative addressing is used. (If for some reason you ever need to increase them beyond the limits of page-relative addressing you can move each global section to follow immediately it's respectively copy routine)

3. I changed the order in reboot.S, so that the order of re-writing is first tag list, then kernel, then initrd -- this is parallel to the physical ordering and technically would allow the initrd to write over space that was formally used to store the kernel code (though it probably doesn't happen that often).

4. In main.c, I changed the load_file routine so that you can give it a minimum memory address that with each segment increases by the size of the segment. This is consistent with the fact that the memory is copied over in reboot.S in segment order. Specifically, you can start allocating zImage anywhere above 0x8001u and initrd anywhere above 0x800001u (actually as above I change that to 0x600001u) again since the memory segments are transferred in order.

5. In main.c, I also noticed that the kmalloc's for the tag list and for the dns323_reboot_code kmalloc returns were not tested to make sure they don't collide with code the reboot.S needs to relocate. So, I added the limitation that the tag list be allocated above 0x101u (although I imagine this constraint won't ever be an issue) and that the dns323_reboot_code starts beyond the end of the max initrd final location (INITRD_START + INITRD_SIZE + 1)

5. I made a minor change or two to the printk's in main.c

6. I put the final global variables dns323_reboot_size outside of the relocatable code in reboot.S

I will post the final code when I am done tweaking...

Any news in the front?

Could you please make your code available?