The problem:
On brcm63xx some routers check the CRC of the firmware on every
boot. The JFFS2 EOF marker (DEADC0DE) is part of the image that is
flashed. That means the CRC changes when DEADC0DE is moved, and then
whenever those same bytes where it was are modified (e.g. on an inode
change), it changes again. That means that after firstboot and
creation of the jffs2 filesystem, the routers refuse to boot.
Solution:
I would like to solve this by making the EOF marker not be part
of the firmware image. The current solution for other platforms is to
modify the kernel. I'm not comfortable with that solution because it
involves modifying and reflashing the erase block with the imagetag (CRC
and record of the offsets and length of the kernel and rootfs). I
think that's kind of dangerous and an ugly hack.
To do it the way I am suggesting, we would:
1) instead of putting the DEADC0DE in the firmware image, add
it in mount_root. I've got some test code with this, but it has to be
redone because the patch was combined with other changes
2) for sysupgrade we add a new parameter that is like -j but
instead of looking for DEADC0DE it looks for another magic that we use
to indicate the end of the rootfs (this also could be used to ensure
that rootfs_data parition starts after the rootfs, not after the
squashfs, which isn't necessarily the same thing, but is what current
happens)
3) To get an equivalent functionality to the current situation
where flashing the firmware erases and rewrites the jffs2 (in the case
of a squashfs or jffs2 filesystem), we would introduce an NVRAM
variable that is created on firstboot. If the variable disappears (the
reset button is held down for long enough to reset the nvram), we do
firstboot again, which would recreate the flash filesystem. Basically
a deadman switch.
I'd like comments on this approach or reasons why the kernel hack isn't
as bad as it seems. I'd prefer my approach because I think it's easier
to change and understand, and it paves the way for an easy way to
achieve a usb rootfs. (I've written code but not tested it yet for the
usb rootfs, and I see things I'd like to change, so I consider the code
not ready to release, but I know it can be done).
Regards,
Daniel
--
And that's my crabbing done for the day. Got it out of the way early,
now I have the rest of the afternoon to sniff fragrant tea-roses or
strangle cute bunnies or something. -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org
The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore
signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
