Can the buspirate determine the size of a chip? Wondering if it's possible to determine the size of a flash/BIOS chip using just the terminal (putty) + manual commands without needing to cross-reference datasheets or use flashrom.
Secondly, is it possible to do a single READ command that reads (and prints) the entire chip's memory without needing to know the number of bytes the chip has and using that number for the repeat-function (e.g.,
[0x3 0 0 0 r:XXX]
[quote author="Coldblackice"]Can the buspirate determine the size of a chip? Wondering if it's possible to determine the size of a flash/BIOS chip using just the terminal (putty) + manual commands without needing to cross-reference datasheets or use flashrom.[/quote]
I guess that since modern chips of today generally have a unique JEDEC identifier, it should not be very difficult to query them with the Bus Pirate and see what they respond.
By using the Bus Pirate scripting features would be even possible to automate chip identification by providing a list of them sorted by JEDEC numbers, otherwise once acquired the JEDEC number will be the need to manually search the datasheet of the component and get information from there.
So I think the answer is yes, the Bus Pirate can determine the size of a chip.
For example, the 25VF080B chip has the unique JEDEC identifier BFh 25h 8Eh that can be read with the Bus Pirate.
The device information can be read from executing the 8-bit command, 9Fh, that in the case of the Bus Pirate has this syntax:
[0x9F r r r]
Running the command in any terminal, even Putty, will be issued 3 bytes, so that the 8-bit ID manufacturer BFh, is output from the device and after that, a 16-bit device ID is shifted.
The whole thing is as follows:
Byte 1, BFh, identifies the manufacturer as Microchip
Byte 2, 25h, identifies the memory type as SPI Serial Flash
Byte 3, 8Eh, identifies the device as SST25VF080B
However, either in one way or another, you need to connect the chip correctly and to automate it to write appropriate scripts, so a flashrom program or something like that would be a ready-to-use solution.
[quote author="Coldblackice"]Secondly, is it possible to do a single READ command that reads (and prints) the entire chip's memory without needing to know the number of bytes the chip has and using that number for the repeat-function (e.g.,
[0x3 0 0 0 r:XXX]
About of that possibility try to take a look here:
Be seeing you.
Thanks USb, much obliged. I was hoping it might be possible to do a single command and then have the entire memory returned all at once at the terminal. I thought about doing a READ repeat for some super high number beyond what the chip would have, hoping that the read would stop once it reached the end of the chip's memory. But my experiment seemed to show that the READ will loop back around to the first byte of memory and continue.
Why am I wondering this? Mostly for my own future reference, but prompted by a task I'm working on, trying to troubleshoot/diagnose a Western Digital hard drive that suddenly won't appear in Windows or even BIOS anymore -- when trying to dump the drive's controller PCB's chip, Flashrom gets stuck trying to read the chip, BUT I can talk with the chip over the buspirate/putty manually just fine. I think maybe the chip isn't already pre-programmed into flashrom's database.
So I thought I'd do a manual read command in putty and then save the entire output bytes into a file (after cleaning up the hex formatting) and save that as the ROM output. I knew I could look up the chip and actually even had the datasheet already open, but I was hoping there was a simpler way to read an entire chip with a single command without needing to cross-reference any external data or sources. Thanks for the input + post reference!
I am sorry for the problem you are dealing with.
I would like to ask you a question, if possible.
You wrote that actually you can talk with the chip over the buspirate/putty manually, so in the end you know exactly what is the chip you are querying, could you please say it here?
Be seeing you.