search

PeterPawn / modfs

modify firmware for NAND-flash based FRITZ!Box routers and install it on such a device
GNU General Public License v2.0
62 stars 15 forks source link

modfs update <firmware.image> <modded firmware.image> does not work as expected #26

Closed MAnantharaman closed 7 years ago

MAnantharaman commented 7 years ago

Peter, I completely understand that modfs is "as-is" and all the many code-paths are neither necessarily documented or tested, but in case it is of interest to you, I want to report that the code-path used by the above command does not create a new firmware-image as expected, rather (after checking modfs-code in the path activated by create_image_only) just creates an image of the root-filesystem. The reason I used this command was that I wanted to create a modded firmware-image and then practice uploading it with eva_to_memory - after having to revert too often to 6.51 and work my way back to 6.80:-(

Regards, Martin

PeterPawn commented 7 years ago

This is also by intention ... the whole part to modify a "foreign firmware" was added to support the smaller equipped models like 7412, where the missing USB port makes modifications on the device a pain (due to missing memory and the inability to add swap space).

The idea was, that only a new SquashFS image is needed in such a case, while the existing kernel and yaffs2 content may remain unchanged (or may be copied/installed with simple commands).

If you want to create an image to be started from memory, you have to create an ext2 image (instead of the yaffs2 image from /wrapper, the scanner code from kernel doesn't recognize yaffs2 images at boot time) first for the "wrapper" content and add the "dummy header" for a SquashFS image (256 bytes of (usually) zeroes, starting with "sqsh" in the first four bytes) in front of it. This ext2 image may be copied after a kernel image (without TI checksums in both files) and the resulting file may be used as input for EVA uploads to memory.

That would be a vast effort for an (unusual) case inside of "modfs" ... it's easier to wrap this also into an additional script, which takes the steps from above to create an image to be run from memory and includes only the SquashFS image created by "modfs" into the new "wrapper" filesystem.

Feel free to reopen (I'll close this issue now) ... and I'm ready to point it out further, if you need more explanations; but that's a theme for the IPPF discussion board in my opinion and I'd like to take it up there.

MAnantharaman commented 7 years ago

Thank you for the explanation - but in the method to inject mod-starter with eva_to_memory you described on IPPF you actually create a squashfs (not ext2) filesystem.image. I am confused ...

Regards, Martin

PeterPawn commented 7 years ago

That was (a) for an earlier firmware version and (b - more important) it was only used as a "standalone" system to make independent changes to the yaffs2 partition content.

If you want to install the newly created version using AVM's "/sbin/flash_update" script (that's what I understood or at least thought), you have to create a "compatible structure" (look into the mentioned script) or the copy process will fail.

MAnantharaman commented 7 years ago

When I think of it, I actually want to inject a) a custom-image for modfs-starter (when I update with an AVM image and want to re-start modding) or b) a new root-filesystem (when I completely screwed up with my mods but have a configuration as root-filesystem that is known to work). Could that be done with the EVA+update_yaffs2 method? Though for a root-filesystem I would probably have to tweak update_yaffs2 a bit as it seems to expect a custom-image ...

Regards, Martin

PeterPawn commented 7 years ago

Sure, you may use it this way ... if you only want to use the new system to change some data, there's no need to provide a compatible filesystem structure for "/sbin/flash_update".

The kernel scanner code (in arch/mips/lantiq/common/ifxmips_mtd.c) can detect SquashFS, JFFS2 and ext2 (with the mentioned "dummy sqsh header") formats, while it searches for partitions.

But I don't understand your other problems ... if you use one partition set as a "safe harbor" and revert your system to this point every time, before you start a new "critical" modification, there's always a way back.

But nevertheless ... if you copy the output image of "modfs" behind a kernel image, you may load the result into memory and run it from there.

But this needs deep knowledge (or some time for own experiences) of the boot process and I don't really see, why "modfs" should be used here. If you create your own system, which is able to carry out the operations you want it to do, you can pack this directory tree (the "rootfs" for your stand-alone system) simply with one call to "mksquashfs".