【正文】 ation, which looks something like this Code:[ HDR0 ][ length ][ crc32 ][ flags ][ pointers ][ data ... ]HDR0 is a magic value to indicate a trx header, rest is 4 byte unsigned values followed by the actual contents. In short, it39。s a block of data with a length and a checksum. So, our flash usage actually looks something like this:Code:[ CFE ][ trx containing firmware ][ NVRAM ]Except that the firmware is generally pretty small and doesn39。t use the entire space between CFE and NVRAM:Code:[ CFE ][ trx firmware ][ unused ][ NVRAM ](Note: that the model.bin files are nothing more than the generic trx file with an additional header appended to the start to identify the model. The model information gets verified by the vendor39。s upgrade utilities and the remaining data the trx gets written to the flash. When upgrading from within openwrt remember to use the trx file.)So what exactly is the firmware?The boot loader really has no concept of filesystems, it pretty much assumes that the start of the trx data section is executable code. So, at the very start of our firmware is the kernel. But just putting a kernel directly onto flash is quite boring and consumes a lot of space, so we press the kernel with a heavy pression known as LZMA. Now the start of firmware is code for an LZMA depress:Code:[lzma depress][lzma preszsed kernel]Now, the boot loader boots into an LZMA program which depresses the kernel into memory and executes it. It adds a second to the bootup time, but it saves a large chunk of flash space. (And if that wasn39。t amusing enough, it turns out the boot loader does know gzip pression, so we gzip pressed the LZMA depression program)Immediately following the kernel is the filesystem. We use squashfs for this because it39。s a highly pressed readonly filesystem remember that altering the contents of the trx in any way would invalidate the crc, so we put our writable data in a jffs2 partition ouside the trx. This means that our firmware looks like this:Code:[trx (gzip39。d lzma depress)(lzma39。d kernel)(squashfs filesystem)]And the entire flash usage looks like this Code:[CFE][trx (gz39。d lzma)(lzma39。d kernel)(squashfs)][ jffs2 filesystem ][NVRAM]That39。s about as tight as we can possibly pack things into flash.Why squashfs+jffs2?System bootup is as follows kernel boots from squashfs and runs /etc/preinit /etc/preinit runs /sbin/mount_root mount_root mounts the jffs2 partition (/jffs) and bines it with the squashfs partition (/rom) to create a new virtual root filesystem (/) bootup continues with /sbin/init Both squashfs and jffs2 are pressed filesystems using LZMA for the pression. Squashfs is a readonly filesystem while jffs2 is a writable filesystem with journaling and wear leveling. Since squashfs is a readonly filesystem, it doesn39。t need to align the data, allowing it to pack the files tighter for 2030% savings over a jffs2 filesystem.Our job when writing the firmware is to put as much mon functionality on squashfs while not wasting space with unwanted features. Additional features can always be installed onto jffs2 by the user. The use of mini_fo means that the filesystem is presented as one large writable filesystem to the user with no visible boundary between squashfs and jffs2 files are simply copied to jffs2 when they39。re written.It39。s not all without side effects however The fact that we pack things so tightly in flash means that if the firmware ever changes, the size and location of the jffs2 partition also changes, potentially wiping out a large chunk of jffs2 data and corrupting the filesystem. To deal with this, we39。ve implemented a policy that after each reflash the jffs2 data is reformatted. The trick to doing that is a special value, 0xdeadc0de。 when this value appears in a jffs2 partition, everything from that point to the end of the partition is wiped. So, hidden at the end of the firmware images, is the value 0xdeadcode, positioned such that it bees the start of the jffs2 parition.The fact we use a bination of pressed and partially readonly filesystems also has an interesting effect on package management. In particular, you need to be careful what packages you update. While the ipkg util is more than happy to install an updated package on jffs2, it39。s unable to remove the original package from squashfs。 the end result is that you slowly start using more and more space until the jffs2 partition is filled. The ipkg util really has no idea how much space is available on the jffs2 partition since it39。s pressed, and so it will blindly keep going until the ipkg system crashes at that point you have so little space you probably can39。t even use ipkg to remove anything.Can we switch the filesystem to be entirely jffs2?Yes, it39。s technically possible, but a bit of a mess to actually pull off. The firmware has to be loaded as a trx file, which means that you have to put teh jffs2 data inside of the trx. But, as I said above, the trx has a checksum, meaning that if you ever change that data, you invalidate teh checksum. The solution is that you install with the jffs2 data contained within the trx, and then change the trx bounaries at runtime. The end result is a single jffs2 partition for the root filesystem. Why someone would want to do it is beyond me。 it takes more space, and while it would allow you to upgrade the contents of the filesystem you would still be unable to replace the kernel (outside of the filesystem), meaning that it39。s not a seemless upgrade between releases. Having squashfs gives you a failsafe mechanism where you can always ignore the jffs2 partition and boot directly off squashfs, or restore files to their original squashfs versions.I used to have a trick where I could convert a squashfs install to a jffs2 install at runtime by copying all the data onto the squashfs partition and changing the partition boundaries. I never really h