Jefferson, 
31 de março de 2020, 
Eu estava com esse assunto na fila desde novembro e acabei decidindo falar logo sobre ele por causa dos recentes eventos com SSDs da HPe que sugerem que defeitos que seriam “triviais” em um HDD podem tornar a recuperação de dados em um SSD impossível.
O HDD do cliente estava morto e ele precisava dos dados. Como parece ser habitual em escritórios de contabilidade, não havia qualquer backup. Externamente não se via nada de errado mas após a remoção da placa ficava claro a olho nu que o problema era sério. Observe o canto superior direito.
Para quem não tem familiaridade com eletrônica pode não ser tão visível, então vou deixar mais claro:
Antes mesmo de ver essa ampliação eu decidi procurar uma placa susbstituta. Eu nem mesmo tentei ver qual o papel dos componentes destruídos. Isso não foi inteligente mas acabou funcionando a meu favor, como vocês verão adiante. O HDD é um Seagate Barracuda 7200.12 de 500GB fabricado em 2011.
Eu tenho uma quantidade razoável de HDDs velhos à minha disposição, mas depois de olhar mais de uma centena só encontrei um do mesmo modelo (ou assim me pareceu). Testei o HDD e estava funcionando normalmente. Troquei as placas e… o HDD do cliente ficou batendo cabeças. Esta é a placa do doador:
Alguns componentes são diferentes, mas o layout é idêntico (o componente que falta na placa da esquerda foi removido depois do dano).
O que motivou a destruição dos componente na placa poderia ter danificado o disco, mas também era possível que o problema fosse uma diferença de firmware. Comparando as duas etiquetas isso era claro. No HDD defeituoso a versão de firmware era CC46 (como você pode ver na foto), mas no HDD doador era outro.
Eu decidi pedir ajuda a meu amigo Edlas, que é muito melhor com essas coiss do que eu, para consertar a placa danificada. Chegando lá a primeira coisa que ele me disse quando observou a placa foi desanimadora: o motor do disco estava em curto e o único jeito seria remover os discos e colocar em um equipamento especializado, que ele teria que importar da China. Mas então eu observei que o motor não poderia estar em curto, porque com a placa do HDD doador (eu levei os dois) o HDD defeituoso decolava e ficava batendo cabeças. Após uma rápida olhada nos dois HDDs ele notou uma coisa que eu não havia: não era só a revisão do firmware que era diferente: os modelos também eram. Apesar de ambos serem Barracuda 7200.12, o código em cima do segundo código de barras (defeituoso: ST3500418AS) era outro. Após pensar um pouco ele decidiu colocar o chip de memória flash da placa defeituosa, que provavelmente continha o firmware, na placa do HDD doador. O chip é este:
Winbond 25X40BLS02 (25X40BL). Uma memória flash serial de 4Mbit (512KB)
Trocado o chip e colocada a placa doadora no HDD defeituoso, o HDD inicializou normalmente. Aproveitei para fazer uma cópia dos dados lá mesmo para não correr nenhum risco no transporte para casa, mas o HDD está funcionando até hoje.
Se a placa doadora for colocada no HDD doador, este agora fica batendo cabeças.
Se eu tivesse parado para examinar o dano na placa defeituosa teria percebido que a análise de Edlas era correta. Os três componentes destruídos são indutores em série com as três linhas de +12V que alimentam o HDD. E hoje em dia só o que usa 12V em um HDD é o motor. Um dano desses tinha que ser um curto no motor. Mas no fim não era.
Notas:
- Na foto da placa defeituosa o chip de flash está ausente. A placa foi fotografada depois do transplante;
- Quando eu descobrir onde coloquei o danado do HDD doador eu colocarei uma foto da etiqueta mostrando o modelo diferente;
- Coincidentemente, semanas depois um HDD Seagate Barracuda 7200.11 (fisicamente bem diferente do 7200.12) de 500GB meu entrou em curto. Não há dano visível na placa mas eu sei que é um curto. Eu não consegui recuperar os dados dele porque para este eu ainda estou à procura de um HDD doador.
Outro dia assistindo um vídeo sobre recuperação de HDs falaram que mesmo se for a placa de um HD de modelo e revisão idêntica não vai funcionar, precisa usar a CI com a firmware do disco original.
Isso não é inteiramente verdade. Na semana passada eu consegui ler os dados de um Western Digital WD800BD (SATA 80GB) apenas trocando a placa. O doador tem exatamente o mesmo modelo WD800BD-00LRA1.
Por outro lado o WD800BD-08MRA1 que está batendo cabeças aqui continua batendo cabeças com as placas WD800BD-00LRA1 e um dos WD800BD-00LRA1 até inicializou com a placa WD800BD-08MRA1 sem ficar batendo cabeças (não que eu tenha conseguido ouvir), mas não consegui ver qualquer partição.
Esse HDD foi fabricado em abril de 2007.
Para o bem da credibillidade do autor do vídeo eu espero que ele não tenha sido categórico nessa afirmação, porque apesar de eu fazer isso muito pouco não é a primeira vez que tenho sucesso simplesmente trocando placas.
Para não ficar no ar a impressão de que isso seja exclusivdade da Western Digital, eu procurei e encontrei mais um par de gêmeos na minha caixa. Dois HDDs Samsung HD322GJ (SATA 320GB 7200RPM).
Ambos com Part Number HDD322GJ/SRN
Troquei as placas e ambos continuaram funcionando normalmente. Um deles estava com Linux Ubuntu instalado e continuou dando boot normalmente com a placa do gêmeo. O outro estava vazio mas coloquei um arquivo ISO nele e o arquivo continua “montável” depois da troca.
Esse modelo foi fabricado em julho de 2011. Alguns meses antes da compra da Samsung pela Seagate.
Pelo que eu entendi do seu relato e do que eu já passei por isso, se os discos forem IDÊNTICOS, com o mesmo P/N igualzinho letra por letra, a chance de funcionar é altíssima!
Se a placa for idêntica visualmente como o seu caso inicial, mas o P/N não bate, tem que transplantar ao firmware da placa defeituosa pra placa boa. O firmware pode ser diferente, tem uma geometria INTERNA diferente, tem calibração diferente, a lista de coisa que pode ser diferente é grande.
Desde que não seja um Seagate. Porque aí você precisa olhar também a versão do firmware. Não é à toa que a Seagate é o único fabricante (que eu conheço) que registra a versão do firmware na etiqueta.
Encontrei o vídeo: https://www.youtube.com/watch?v=d6pPVw3zHjo
Em defesa dele, ele diz aos 1m0s que “hoje em dia não é bem assim… varia muito de arquitetura para arquitetura… de cada fabricante…”
E no texto do vídeo ele diz “alguns casos a substituição de placa lógica funciona e em outros casos não”
Tendo dito isso, minhas queixas depois de ter sido obrigado a ouvir 30 minutos dele falando:
Toda vez que ele falou “ROM” (e ele falou várias) me doeu os ouvidos
Apesar de durante o uso normal do HDD a peça que contém o firmware ser para todos os efeitos práticos uma ROM, eu nunca chamaria de ROM porque historicamente ROM é o nome de uma peça cujos dados gravados não podem ser alterados e o que o HDD usa é uma memória Flash (outro bicho) cujos dados podem ser alterados até mesmo com o HDD em funcionamento.
“A Firmware” (18min10s e 28min16s) também doeu
Ninguém diz (se quiser ser levado a sério) “a hardware” e “a software”, diz?
Chamou a flash de “Chip de BIOS” (23min28s) e “Chip da BIOS” (24min22s)
“BIOS” é um termo que eu reservo para motherboards. E mesmo assim, principalmente por causa da confusão entre as definições de “BIOS” e “UEFI”, é melhor chamar o que temos na motherboard de firmware quando essa distinção for irrelevante, para não parecer que é relevante.
Achei ele estranho ele dizer que (8min) uma programação errada poderia fazer a cabeça ter atrito com a mídia
A operação de um HDD é algo muito complexo mas, basicamente, as cabeças sobrevoam o disco a uma distância micrométrica por causa do colchão de ar criado pela rotação do disco (é a aerodinâmica das cabeças que determina isso) então não vejo como, mesmo que o fabricante quisesse, fazer a cabeça tocar o disco programaticamente.
Mas eu posso estar errado nisso.
Pensei numa possibilidade. Em teoria o HDD retrai automaticamente as cabeças caso o disco desacelere, justamente para evitar a aterrisagem das cabeças sobre o disco. Mas onde está a inteligência que determina isso? Se é no hardware (deveria ser) as cabeças vão ser retraídas independentemente do firmware, mas se for no firmware… aí o bicho pega.
Se estiver com tempo ai tem um jeitinho de testar isso com algum HD sucateado ai que esteja pelo menos girando o disco. Dá um jeitinho de desligar a cabeça de leitura e tira fora a flash com o firmware, isso vai matar a inteligência do HD. Liga ele, espera o disco estabelecer o giro e move a cabeça a mão pra alguma posição do disco. Desliga e voilà…
Mas quer minha aposta? Isso deve ser feito por processo do firmware.
@Jefferson
Rapaz. consertei um wd800 que tinha aqui há 12 anos (realmente eu sou uma pessoa que tem paciência). Eu tenho uma hipótese, vou tentar exemplificar ela organizadamente pra não confundir:
Se você pegar um hd A(com placa A), e um hd B(com placa B), sendo que o hd A é o estragado e o hd B é o que está funcionando, considerando que os dois são da Western e de modelos muito próximos. Caso você grave o firmware da placa A na placa B, após isso terá que ligar a placa B no hd B (ao invés de encaixá-la no hd A, que seria o mais sensato, já que é ele que está estragado). Caso faça isso, provavelmente o firmware lerá alguma chave de criptografia ou serial da cabeça de gravação e isso irá bagunçar alguma coisa no firmware e o fará funcionar corretamente quando ligar a placa B no hd A).
Agora, vou repetir, é uma hipótese.
E acho que foi isso que aconteceu comigo, eu testava a placa B no hd A direto, e não funcionava, mas quando liguei a placa B no hd B, chequei no setup que o nome do hd aparecia em branco no setup mas ele era detectado, e o sistema operacional não conseguia montá-lo mas conseguia detectar o link sata.
Você acha que minha hipótese corrobora com alguma situação que já aconteceu com você ou com alguém mais, ou foi só erro meu mesmo e não vi algum detalhe, talvez estivesse detectando tudo normal mesmo?
Acredito que esses firmwares são programados pra falharem em algum momento mas também são programados para detectar se alguém está fuçando neles e podem voltar a funcionar do nada(por qual motivo? porque se fosse provado que são programados pra falhar isso renderia um bom processo contra o fabricante).
e aí funcionou tudo tranquilo quando liguei a placa B no hd A, consegui dumpar tudo pelo linux mesmo, estou rindo de quem usa windows com software específico pra fazer isso kkk…
só deixando esse comentário extra aqui pra ninguém achar que sou maluco e parei na etapa da placa B no hd B kkk (deve haver algum cliente por aí que acredita em transferência de almas, é bom previnir)…
Eu não sei se a minha pergunta vai ser “off topic”, mas como tem haver com BIOS, vou perguntar.
Jefferson, você já utilizou o Gravador de Eeprom EZP2019 (aquele que é vendido no AliExpress)?
Eu queria saber a tua opinião sobre ele porque comprei um e estou esperando chegar. A princípio comprei para estudos e alguns testes no laboratório com placas-mãe antigas.
O único gravador que uso é o Willem. Arcaico e problemático mas tem resolvido meus problemas até agora.