Quote:
Originally Posted by NiLuJe
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).
At this point -
getting closer to that noob's DX cure.