Reverse engineer experts only

[Jane]

There are many flash memory chips in a solid state drive.
Not sure if everyone knows what SSD is.( I did not know it untill recently either).
So, solid state drive( SSD) is a disk with many flash memory chips and that SSD works in a similar way like  a typical  harddisk.

 I suspect  one of that flash chip( or at least a part of it)  works as SSD's BIOS. Is it possible to find out which flash chip it is?
 

[senso]

Possibly the main proprietary controller that speaks to all the flash chips and to the SATA interconnect.

[mikeselectricstuff]

There are many flash memory chips in a solid state drive.
Not sure if everyone knows what SSD is.( I did not know it untill recently either).
So, solid state drive( SSD) is a disk with many flash memory chips and that SSD works in a similar way like  a typical  harddisk.

 I suspect  one of that flash chip( or at least a part of it)  works as SSD's BIOS. Is it possible to find out which flash chip it is?

First thing would be to look at all the chip-selects and see which one goes active first on startup.

[EEVblog]

Is there an odd number of flash chips?
If so, one is likely devoted to the BIOS.
And if that's the case, then it probably stands outs in terms of layout, and maybe even bus (I don't know SSD drive architecture off-hand)

[marshallh]

A ssd is going to have a bunch of NAND flash roms on it. The controller will perform write leveling and fault recovery (bad blocks develop over time and must be worked around).
So while you could have say an ARM binary blob scattered across a nand, it could be inside the SSD controller itself. May even be a mask rom.

Look up any info on the ssd controller IC and any surrounding chips. Without manually dumping each flash separately and carefully looking for arm executables (there may be redundant copies) i don't know.

[Jane]

Thank you ALL for the replies. A problem is that SSD is not detected by BIOS but  voltages ( when compared with the good SSD) seem to be correct. Also some chips were replaced( including the main chip(SSD controller)  SandForce. Yes, SSD is made by OCZ. So I guess the only possibility is BIOS of that SSD.
@marshallh: what do you mean by :May even be a mask rom ? Do you mean the SSD controler should work as a BIOS too?

[kripton2035]

ocz ssd are known for their high failure controller chip rates...
then using a ssd drive without a regular backup is in my mind like suicide ...
then if you have time to loose to try to recover this then it's your own thing !
good luck.

[nctnico]

The first step is to get a datasheet and/or user manual on the controller chip. This will show whether the controller chip has an internal flash or has its firmware in NAND. Due to the nature of an SSD I expect the controller chip to have an internal flash. AFAIK most hard drives and SSDs allow firmware updates performed by the user nowadays.

[free_electron]

The flash pool does not hold the firmware.
The ssd controller has its own flash on board that has the firmware. That gets decompressed into the on-board ram and runs.

Some ssd s have a partial bootloader in the co troller while the rest is stored in an external eeprom like a 25cxxx type. 8 pin spi device.

[mikeselectricstuff]

The flash pool does not hold the firmware.

But does it store other critical stuff like the bad-block info?

[amyk]

That should be stored in the spare area, along with the ECC.

[smashedProton]

I took one of these apart recently.  Look data input and follow the traces to a smaller looking chip.  That chip is probably made by 'sandforce', they're the industry standard with this sort of thing.  It does a whole lot more than just the BIOS.  It's duties include: memory refresh, error correction, housekeeping, and maybe tamper switches.

[Jane]

@smashedProton: Data input from what?
Do you have a picture of that smaller looking chip?
Thanks

[smashedProton]

I will take it apart and get you a picture later today when I have time.  I meant the sata interface

[andersm]

Just about any enthusiast site review will have PCB pictures. Maybe not high-resolution enough to make out all the component markings, but enough to give a good idea about the design. Ex:
http://www.hardocp.com/article/2013/05/28/crucial_m500_480gb_ssd_review/3#.UcMfnOuk1X0
http://www.tomshardware.com/reviews/vertex-450-256gb-review,3517.html
http://www.storagereview.com/sandisk_extreme_ii_ssd_review

[free_electron]

The flash pool does not hold the firmware.

But does it store other critical stuff like the bad-block info?

Bad blocks in flash work differently. The flash chip actually has more than 1024 meg. The built in address decoder translates. I can" t remeber the real numbers off the top of my head but for a 4 gb flash there are 32 extra pages ( 8 per die i believe. A 4gb used to be made from 4 dies).
A failure in a page gets a remap done by the on chip decoder.
This is done at factory to improve yield.

A secondary error map is handled by the FTL (flash translation layer). That marks off bad 'sectors' just like a regular filesystem does. That info is stored in the BAT ( block aging table) So that info is indeed stored on flash.
The BAT lies outside the user flash .

If the ftl has wear leveling of itself the os does not know. If a page is bad we simply set its netry im the bat as 'nad'

[marshallh]

On that HardOCP link there is very clearly a SPI NOR flash rom on the pcb under the controller chip. Labeled 25P16

It's a ST Micro M25P16 16-megabit rom. Probably holds program code for whatever CPU is on the Marvell SoC (MIPSor ARM)

[mariush]

The rom only contains the firmware.

The controller often fails even when the flash memory chips are perfectly fine.

Not only there's extra memory in each memory chip as free_electron says (to get better yields by recuperating chips with a few bad cells) but manufacturers also hide from user a portion of the storage space.. ex a 64 GB drive shows up as a 64.000.000.000 bytes just like regular/classic hard drives would, so that's about 61 GB usable disk space. Some controllers reserve even more space.
This reserved space is used by the controller for various things... the controller has algorithms which spread out the writes to various memory cells to keep the writes even, because each memory page in a flash chip can only be written about 1000-3000 times depending on memory geometry... as it gets close to the maximum writes, the controller just maps the data to one of the reserved unused blocks and therefore user doesn't notice anything.
A part is also used to spread writes when ssd is close to being fully used - imagine having 10-100 MB free space on ssd and user browses various pages and firefox/chrome/etc keeps caching files to disk in those 10-1000 MB. Those 10 megs would get written thousands of times within days. So the controller writes to the reserved space instead to keep the cell write count low.
The reserved space is also used when the ssd tries to recover blocks of memory ... flash memory is arranged in pages of let's say 512 KB and blocks of 4 KB in those pages ... the controller can write a 4 KB block but can only erase a full page of 512 KB.  So for performancee reasons, sometimes the controller works in background searching for pages with just a few 4 KB blocks used in a 512K page, copies them to reserved space and marks the 512 KB page as "can be deleted if needed and filled with 512 K of data"
Anyway.. there's lots of things about ssd that are interesting.

Anandtech did a bunch of articles that have loads of good information :

The SSD Anthology: Understanding SSDs and New Drives from OCZ
http://www.anandtech.com/show/2738/5

The SSD Relapse: Understanding and Choosing the Best SSD
http://www.anandtech.com/show/2829

[Stonent]

On that HardOCP link there is very clearly a SPI NOR flash rom on the pcb under the controller chip. Labeled 25P16

It's a ST Micro M25P16 16-megabit rom. Probably holds program code for whatever CPU is on the Marvell SoC (MIPSor ARM)

Ok that confirms my theory that they weren't going to waste dollars on another NAND flash for something that could be stored on sub 1 dollar SPI prom/eprom/eeprom

[amyk]

Not only there's extra memory in each memory chip as free_electron says (to get better yields by recuperating chips with a few bad cells) but manufacturers also hide from user a portion of the storage space.. ex a 64 GB drive shows up as a 64.000.000.000 bytes just like regular/classic hard drives would, so that's about 61 GB usable disk space. Some controllers reserve even more space.

I remember being very happy when the first flash USB drives came out in power-of-2 sizes that actually had that usable capacity... 16MB would reallly be 16,777,216 bytes.

[Jane]

Here is the mainboard of the SSD I was talking about. Can anyone show me where the BIOS is?
Thank you

[Stonent]

I can't read anything on the chips, the pictures aren't high enough resolution.

[Jane]

Here are better pictures. However we did not find any additional flash/eeprom chip with BIOS, except a possibility that the BIOS is in one of the Hynix flash chip.
Thank you for help

[marshallh]

That controller is a mass market integrated solution so probably has ondie flash (mentions upgradable firmware). The manufacturer (now LSI) mentions that you can use an EEPROM for additional settings storage. It stores data on the nands encrypted with AES-128. The language was vague on whether it contained firmware on the nands themselves, but it is 100% guaranteed that housekeeping, bad block tables etc are stored in set aside space on the nands.

Additiionally there are RS232 debug outputs on the chip! These may be broken out on the pcb. Stick a LA on them while powering up the drive, maybe you'll find some diag. messages

http://www.lsi.com/downloads/Public/Flash%20Storage%20Processors/LSI_PB_SF-1000_RefEvalSSDs.pdf

[free_electron]

Most likely U3. It sits right on top of the jtag traces (to allow factory flashing). The jtag could do double duty.


Remains the question : why do you need access to the firmware ? You cant modify that anyway. Nor do you have the equipment to flash it that way.
All you could do is swap that chip from a known good drive.