Take my double kernel comment with a grain of salt, it's been a good while since I wrote that, and it may not be entirely accurate ^^.

The only thing I'm sure of is that there are two kernels .

The "flash update" utilities are implemented as shell scripts.
I have not studied them enough to know in what order they are called.
But they do share a common organization structure:
They update U-Boot (if available)
They update the uImage (if available)
They update the system image (if available)

And there is scripting for each "set" of U-Boot / uImage
(They could have done with fewer scripts if they had duplicated the thing I labeled: "machine specific data" - but they didn't.

Since all of this is in the mtdblock device, none of which has a file system that could be mounted during normal operation - it should be "safe" to re-write the contents at any time.

In the case of this thread - all that is lacking is the storage addresses as seen from U-Boot and this problem is solved.

There are two DX(G) machines involved - one with a working serial port, reported as booting to u-boot (although I suspect it is actually booting the kernel and the kernel is doing a panic halt) ;

The other machine - without a serial port, that works normally.
Separated by at least 6 time zones.

It isn't exactly a "real-time interactive" troubleshooting session.

It may take a bit of "peeking" into /dev/mem on the working machine for "known values" of the various images.
And then some confirmation by "peeking" from U-Boot (which should be the same - /dev/mem translates from virtual to physical addresses).