what do you mean about back to the drawning board? do you need a new flash utility becasue the one you have wont put the right signal to the write enable pin?
Nah... I took another look at the traces, and you're right -- I was tired and distracted when I was looking before, and so I was looking at pin 12, not pin 11. I see now that pin 11 is hooked up to the write enable pin on the SDRAM, and the two of them are connected to the CPU, like you said.
I meant, back to the drawing board, as in I now don't have an explanation as to why my flashing code doesn't work. So I need to come up with another one ... but I still don't see a reason why it can't work.
The way it should work is that you write out a special sequence to the "rom" chip (it's like 0xA0 to address 0xAAA, then 0xFF to 0xFFF, then 0x90 to 0xAAA, or something -- it's spelled out in the datasheet). It then spits back out an ID code so you can identify what kind of chip it is. You should be able to read back 0x20 0x57 from the first two bytes of the flash chip... instead, what we're getting back is the first two bytes of the ROM image itself, which means it ignored the command sequence.
I took some code that is known to work with other flash chips, and just modified the command sequence, so I don't know why it won't work!
In the mean time, i'm going to try to completely nail down how the boot rom image functions. I'm having trouble getting IDA Pro to handle the address references correctly, but I've identified the crypto functions as well as the IDE interface functions.
It's possible (but not horribly likely) that there is a way we can corrupt the drive signature in a way that will force it to pass ... that'd be the only way to avoid having to flash the chip.
Ben
