A second stage bootloader solution, as mentioned by someone else, sounds like a solution that doesn't change the layout of the flash so it is possible to go back to previous firmware versions or even stock firmware.
I will not be working with a second-stage bootloader: "RAM" boot for mpc85xx is far from usable in mainline U-boot, and the mpc85xx target is already the only target that already needs a 4K TPL to boot the 64K SPL to boot U-boot. It's too many moving parts. I'm going to be building a U-boot replacement; U-boot can be overwritten from a live system, though without proper checks there is a risk of bricking.
Does your solution with a u-boot replacement change the flash layout. in other words, can you go back using older firmwares or even stock or is it a one way street?
It will most likely be a two-way street -- I'll have to look more closely at the partitioning layout to confirm -- but you should just need to
- boot an older, working OpenWrt,
- backup the original u-boot,
insmod mtd-rw i_want_a_brick=yes- Erase and rewrite the bootloader partition with the new, freshly-compiled mainline U-boot
fw_setenvto set change the bootcmdsysupgradeto the target OpenWrt
The reversion to pre-upgrade OpenWrt is the same thing, just booting a newer OpenWrt and writing the old U-boot and U-boot environment, then sysupgrading to the old OpenWrt.
But this all depends on the feasibility of reusing the partition layout; my fix for booting on the Aerohive HiveAP 330 has the same issue; in that case we needed to change the partition layout, because stock U-boot had an upper limit on the size of the compressed kernel which conflicted with the partition size.
Can you give me a rough estimate when you may have a working solution?
I have no idea. It will be around the same time that I get U-boot working for other mpc85xx boards; see this thread.
Is this solution a one time solution or will future OpenWRT images adapt your solution?
My plan is to build U-boot compilation into the OpenWrt buildsystem, sharing the build toolchain, as is done with e.g. kirkwood boards. I will also test U-boot from time to time, and should an updated U-boot brick the board, can recover the board using my BDI2000.
Across the board, vendor mpc85xx u-boots have various issues - another example is on the AP3825i. I really would prefer to unify all of these so we can stop struggling to keep board support going.