Code 207 is issued by aosparser when the .aos upgrade file doesn't
pass the signature check.
This is confusing as I've pulled apart the aosparser in the 1.7.22-patched
.aos package and the check is *definitely* patched out (CMP R0,#0 has
been patched to MOV R0,#0).
So, somehow, this means that the recovery image in flash has been
reverted to a non-patched version
There's more bad news... If the genuine original .aos files are also
giving the same error it means the signing keystore may also have been
In theory, this means the whole device is irrecoverable.... however I've
been doing some thinking about it...
Referring to TI document SPRUF98W (OMAP35x TRM) and
Referring to TI document SPRS507F (OMAP35x Datasheet)
The OMAP3525 boots in a mode called "Fast XIP" which basically means
that the internal OMAP boot ROM *almost* immediately jumps to the beginning
of the 28F320W18 flash chip. This is shown in step 2 of Figure 25-8.
HOWEVER, Table 25-3 seems to indicate that "step 2" above is an over
simplification of what really happens, as row 0b11111 (Fast XIP) is followed
by a 2nd and 3rd preference. After peeking at the OMAP boot ROM, I found
that a check is made to see if the first word of Flash is either 0x00000000
or 0xFFFFFFFF. If it is, then the boot ROM assumes the Flash is broken and
it starts booting from USB or UART3 (the serial port available on the Dock).
I also happened to notice that the Flash chip is NOT mounted "POP" style
on the top the OMAP CPU but they DID use the "POP (CBB)" package
which means the connections to the Flash are easily accessible on the
top of the CPU. See here:http://www.flickr.com/photos/[email protected]/3190177920/sizes/l/in/set-72157612461576128/
Looking at gold contacts at the bottom left quadrant of the CPU:
o o o o o o
o o o o o o
The pin I've marked as 'x' is the nCS0 and if this were temporarily pulled high
then the flash would seem to be broken the the CPU would boot over USB or
UART3. Using the "omap-u-boot-utils-pack" it should be possible to get
x-loader and uboot to run the recovery kernel but with a basic shell instead
of the recovery init script.
To do this I propose to pull the nCS0 line high with a 82ohm resistor for a
couple of seconds after power-on which shouldn't damage the CPU
My main problem at the moment is powering the motherboard without the
battery connected as the CPU faces the motherboard stopping accessing
the nCS0 pin while it's powered on. Might need to solder some teeny wires
If I can get back in then my first job will be to dump the corrupt flash to
find out what the heck has bricked all these units (I've seen several posts
in both the A5 and A7 forums from people who are currently in this trap)
and to see if there's any way out.
More in a couple of days...