Originally Posted by AdamOutler

I just wanted to post this so that there is no more confusion.. from the processor manual page 2400.

The OM pins are INPUTS. INPUTS cannot be changed by software running on that chip. The OM registers are tied to hard lines. if the pin goes high, the register goes high, if the pin goes low, the register goes low... You can't override an input which is a part of the processor. it's a hardware thing.

If you were to find something on the board, look for resistors in a pattern like this...

0X00X0... The 0s or Xs might be resistors or opens, but it would be in that pattern to make the OM=0X9 which would be binary 010010 for a 6 bit register.

0x9 is 001001 in binary.

Originally Posted by midas5

0x9 is 001001 in binary.

**** you're right. I had been under the assumption we were dealing with 5 bits until I looked it up... then I took my precious misconception and added a 0 to the end.... my bad..

My logic analyzer should be here soon... its in the state according to my tracking info. Too bad it dosent analyze my logic.... lol... binary.. logic... get it?

Originally Posted by AdamOutler

The BOOT line from the FSA chip is documented to go to the call processor, not the application processor.

On this block diagram it's shown going to the AP (BOOT_MODE). Also on this diagram there is no documented connection from the SIM socket to any UARTs. That doesn't necessarily mean there isn't one, but the connection on the S8500 that was shown going through the SIM socket is shown as a direct connection here (AP_FLM_TX).

I have been looking at the irom code. With om = 9 it tries to load bootloader from onenand, then sd card, then download over usb / uart . The onenand has a power control registers, so we might be able to power down the onenand, forcing it to boot from sd card.

I also looked at the IBL , but it does not seem to do much more than boot the PBL .

I have not seen the irom talk to the sim card yet. It would be easier if i knew which uart was connected to it. Does anybody know?

The interesting bit of the irom is what it does if the boot is not a cold boot. It needs further investigation.

Finding a way to disrupt the onenand during boot still seems to be the best option.

TheBeano.. the FSA documentation says the line goes to the baseband/call processor... Not saying that either is wrong, but we've got conflicting documentation... If it does go to the call processor, It would suggest the difference between charge and "on" is the call processor activation though.


I found a really high quality picture of both sides of the I-9000 boards and that gave me an idea...

I reversed the processor image and lined it up over the top of the back side of the board..




Then I overlaid the pins on top of that.



hrm.... his may deserve some more analysis... I've got a captivate junker comming as soon as it's sent from Connexxion2005

Originally Posted by AdamOutler

TheBeano.. the FSA documentation says the line goes to the baseband/call processor... Not saying that either is wrong, but we've got conflicting documentation...

That's the chip manufacturer's data sheet though, it's up to the phone designer how they hook up the signals from the chip.

True....

I tried disconnecting that large resistor above OM2,4, and 5... no change to the OM register. Just wanted to make that known.

I also sliced a small trace which would be above OM5.. nothing. So, I'm putting it back together now. :/

Edit: also tried joining those two test points by creating a trace with a #2 pencil

Hrm.... I had it aligned wrong.. and I was working with the antenna amplifier...



Could it be as simple as popping off that resistor?


Will someone please check my work?
here are the images I used

Back side: http://guide-images.ifixit.net/igi/qQmVNHFgsuFRgSVo
Processor side: http://guide-images.ifixit.net/igi/qyIdQVxAcDcLE3nl This should be inverted
Pins as shown from bottom of processor: Note: pin 1 is top right

It looks to me that those resistors are more to do with the display than om pins.

the Cell Processor boot is controlled by toggling a GPIO, rild handles this and so does Sbl in userfault and unknown upload modes