XPost: uk.comp.os.linux   
   From: java@evij.com.invalid   
      
   On 2025-05-31 20:55, Paul wrote:   
   >   
   > On Sat, 5/31/2025 11:30 AM, Java Jive wrote:   
   >>   
   >> 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   
      
   [continued in next message]   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)