XPost: uk.comp.os.linux   
   From: java@evij.com.invalid   
      
   If anyone needs a reminder, the original problem is appended below, this   
   new thread/subthread is about my attempts to fix it.   
      
   The firmware for these Zyxel NSA221 NAS boxes is split into three binary   
   files and a numbers of associated checksums and scripts, described in   
   comments in an unpacking script as follows ...   
      
      # DATA_0000: header version   
      # DATA_0001: firmware version   
      # DATA_0002: firmware revision   
      # DATA_0101: model number 1   
      # DATA_0102: model number 2   
      # DATA_0200: core checksum   
      # DATA_0201: ZLD checksum   
      # DATA_0202: ROM checksum   
      # DATA_0203: InitRD checksum   
      # DATA_1000: kernel file, uImage   
      # DATA_1002: InitRD image, initrd.img.gz   
      # DATA_1004: System disk image, sysdisk.img.gz   
      # DATA_a000: executable, for some jobs before firmware upgrade   
      # DATA_a002: executable, for some jobs after firmware upgrade   
      
   Note that the last two are legacy scripts which with recent builds do   
   not actually do anything.   
      
   To create a firmware file, these are packaged up into a single binary   
   file, which is then unpacked as above when the firmware is applied.  The   
   packing and unpacking are done by shell scripts which call Zyxel   
   cut-down versions of a program called CONV723.EXE, which themselves are   
   called ram2bin and bin2ram.   
      
   I have the software development kit for the NASs, and several years ago   
   built an image which works on both NASs, for which I still have the   
   above component files, but for historical reasons lost in time cannot   
   now seem to replicate that build from any of the existing or backed up   
   build directories.  In fact, rather strangely, none of them now produce   
   anything that will boot, even unpacking the entire SDK afresh from   
   scratch into a new directory and building an image from that, it too   
   doesn't boot!   
      
   So I've been trying a different approach, that of unpacking the working   
   build, modifying the initrd, and repacking it, but this too crashes with   
   a kernel panic.  Even if I simply unpack the initrd, and re-pack it   
   UNCHANGED, EXACTLY AS IT WAS BEFORE, even that gives a kernel panic.   
      
   The packing is done by a script called 'makeras_gpl.sh', the most   
   relevant section from which reads as follows:   
      
   # Updates ROM_CHECKSUM in {METADATA}, generate romfile_checksum,   
   zyconf.tgz and zyconf.rom   
   ./make_zyconf.sh   
      
   # Updates CORE_CHECKSUM in ${METADATA}, generate core_checksum   
   ./make_kernel.sh   
      
   # Update ZLD_CHECKSUM in ${METADATA}, generate sysdisk.img.gz and   
   zld_checksum   
   ./make_sysdisk.sh   
      
   # Update INITRD_CHECKSUM in ${METADATA}, generate initrd.img.gz and   
   initrd_checksum   
   ./make_initrd.sh   
      
   # pack firmware with BETA version   
   ./fw_pack -r ${METADATA} -o tlv.bin   
   ./ram2bin -i tlv.bin -o ras.bin -e "${MODELNAME}" -t 4   
   mv ras.bin ${fBETA}   
   chmod 644 ${fBETA}   
   echo " ==> Beta version file ${fBETA} is created. --> ${vBETA}"   
      
   What I would have readers note is that initrd is the last subcomponent   
   to be built, so it's difficult to see how rebuilding it separately can   
   alter anything else, for example by having a different checksum, because   
   everything else has already been built.  The relevant section of   
   'make_initrd.sh' is as follows:   
      
   echo -e " \033[1;31m>> Enter Critcal Section! DO NOT CTRL+C <<\033[0m"   
      
   mv fs.initrd initrd   
   tar -zcf initrd.tar.gz initrd/   
   mv initrd fs.initrd   
      
   # Create ext2 image   
   mkdir initrd   
   dd if=/dev/zero of=initrd.img bs=1k count=8192   
   /sbin/mkfs.ext2 -F -v -m0 initrd.img   
   sudo mount -o loop initrd.img initrd/   
   sudo tar -zvxf initrd.tar.gz initrd   
   sudo umount initrd/   
      
   echo -e " \033[1;32m<< Exit Critcal Section! >>\033[0m"   
      
   sudo gzip -9 < initrd.img > initrd.img.gz   
   sudo rm -rf initrd   
   sudo rm -f initrd.tar.gz   
   sudo rm -f initrd.img   
      
   INITRDCHECKSUM=`./ram2bin -i initrd.img.gz -e "${MODELNAME}" -t 4 -q -f`   
   sed -i -e "s/^INITRD_CHECKSUM.*/INITRD_CHECKSUM\tvalue\t`echo   
   ${INITRDCHECKSUM}`/g" ${METADATA}   
      
   I've gone through these steps individually a number of times in case I'd   
   made mistakes, but even with unchanged initrd files, I've never got past   
   the kernel panic, the relevant part of the dmesg log from which reads as   
   follows:   
      
   physmap platform flash device: 00400000 at 41000000   
   physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank   
     Amd/Fujitsu Extended Query Table at 0x0040   
   physmap-flash.0: Swapping erase regions for broken CFI table.   
   number of CFI chips: 1   
   cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.   
   7 cmdlinepart partitions found on MTD device physmap-flash.0   
   Creating 7 MTD partitions on "physmap-flash.0":   
   0x00000000-0x00020000 : "uboot"   
   mtd: Giving out device 0 to uboot   
   0x00020000-0x001e0000 : "kernel"   
   mtd: Giving out device 1 to kernel   
   0x001e0000-0x00380000 : "initrd"   
   mtd: Giving out device 2 to initrd   
   0x00380000-0x003f0000 : "etc"   
   mtd: Giving out device 3 to etc   
   0x003f0000-0x003fc000 : "empty"   
   mtd: Giving out device 4 to empty   
   0x003fc000-0x003fe000 : "env1"   
   mtd: Giving out device 5 to env1   
   0x003fe000-0x00400000 : "env2"   
   mtd: Giving out device 6 to env2   
   10 Dec 2004 USB 2.0 'Enhanced' Host Controller (EHCI) Driver@e7000000   
   Device ID register 42fa05   
   oxnas-ehci oxnas-ehci.0: OXNAS EHCI Host Controller   
   oxnas-ehci oxnas-ehci.0: new USB bus registered, assigned bus number 1   
   oxnas-ehci oxnas-ehci.0: irq 7, io mem 0x00000000   
   oxnas-ehci oxnas-ehci.0: USB 0.0 started, EHCI 1.00, driver 10 Dec 2004   
   usb usb1: configuration #1 chosen from 1 choice   
   hub 1-0:1.0: USB hub found   
   hub 1-0:1.0: 3 ports detected   
   USB Universal Host Controller Interface driver v3.0   
   sl811: driver sl811-hcd, 19 May 2005   
   usb 1-1: new high speed USB device using oxnas-ehci and address 2   
   In hub_port_init, and number is 0, retry 0, port 1 .....   
   usb 1-1: configuration #1 chosen from 1 choice   
   hub 1-1:1.0: USB hub found   
   hub 1-1:1.0: 4 ports detected   
   usb 1-1.2: new high speed USB device using oxnas-ehci and address 3   
   In hub_port_init, and number is 1, retry 0, port 2 .....   
   usb 1-1.2: configuration #1 chosen from 1 choice   
   usbcore: registered new interface driver usblp   
   Initializing USB Mass Storage driver...   
   scsi2 : SCSI emulation for USB Mass Storage devices   
   usbcore: registered new interface driver usb-storage   
   USB Mass Storage support registered.   
   mice: PS/2 mouse device common for all mice   
   i2c /dev entries driver   
   pcf8563 0-0051: chip found, driver version 0.4.2   
   pcf8563 0-0051: rtc core: registered pcf8563 as rtc0   
   OXNAS bit-bash I2C driver initialisation OK   
   md: linear personality registered for level -1   
   md: raid0 personality registered for level 0   
   md: raid1 personality registered for level 1   
   TCP cubic registered   
   NET: Registered protocol family 1   
   NET: Registered protocol family 17   
      
   [continued in next message]   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)