Rambling Thought Dump....
Even though Fairchild designed the fsa9480 explicitly to allow cell phone makers to implement a factory programming mode which kicks in automaically when it senses the correct R value, maybe Samsung just didn't use the chip that way.
So the question is, how do we get into UART boot mode?
I started out feeling like it was a no-brainer. We know the UART boot mode exists, we know there is a chip (the fsa9480) explicitly designed to enable it, so had to be a piece of cake.
Now my thinking is, since it isn't easy, just how hard is it?
My understanding is that mass-produced devices usually have their chips flashed before they are assembled. In-system programming is handy for development, but there is always JTAG for that. So it could be that our dear friend OM5 is merely soldered to ground. Or possibly it is just pulled weakly to ground and there is some way of physically accessing it, like a test point somewhere on the main board. Maybe this is venturing into crazyland, but one way to find out would be to disassemble a phone : actually unsolder the CPU and go at the board with probes. I'm not saying I plan to; just that the idea is kicking around upstairs. If it turns out that there is a convenient access point, we would have a way to procede. Not as nice as a magic resistor on the usb connector, but still preferable to JTAG as a cheap, repeatable, open-source method of rescuing a phone.
Another idea I've had kicking around is finding a way to block or corrupt the IBL code as it travels from the OneNAND to the CPU's internal RAM. If the IBL isn't copied perfectly, the iROM code will detect the error and fail over to UART.
How to mess up the IBL? We've already tossed around the idea of modifying it as it is stored in the OneNAND, but that is guaranteed to permanently brick a phone until a (never before attempted) method of recovery based on UART is perfected. And in order to do this, we'd have to start with a working (non-bricked) phone.
But if the transfer of the IBL can be made to fail "on demand", that would be a reasonable way to go forward.
TBH, I don't even know where the OneNAND is or what kind of physical access we have to it. The trick is to mess with the data without breaking anything. I'm thinking of a longish wire (not connected to anything) as a noise source. Touching it to every possible contact near the OneNAND chip is bound to turn up something (clock, chip select, power, enables,???) with enough noise sensitivity to corrupt at least one bit.
Anyway, enough rambling. Time for SNL.
Sent from my SAMSUNG-SGH-I897 using XDA App