A ressuscitação do firmware pela porta serial e a perda do HDMI...

[rictad]

Vocês talvez se surpreendam, mas com o MTKTool via serial, menos setores são apagados no DV397H de chipset S. Na verdade, via serial, nada a partir do endereço #F0000 é apagado pela atualização.

Ué... como então o seu player perdeu a HDMI quando você atualizou por cabo?

Que versão do MTKtool você está usando agora? Sabe dizer se sempre usou essa versão?

Você pode me dizer qual o modelo do chip flash no seu aparelho? Eu não encontrei fotos internas do DV397H. Você tem como tirar algumas?

Pois é, fiquei pensando nisso e vi que estava errado. Com o MTKTool 1.31 (acho que sempre usei essa versão) de fato um maior trecho da FLASH é apagado, mas mesmo assim ainda fica um pequeno setor intacto no final.

Durante aquele tempo em que fiquei com a FLASH "travada", eu postei imagens do meu DV397H aberto e até mesmo o datasheet da FLASH. E no final daquilo tudo cheguei à conclusão que esse aparelho com chipset MT1389S tem lá suas peculiaridades na atualização.

Vamos aos resultados dos testes. Antes de mais nada, descobri em qual operação o player grava a string "MT23" na FLASH e mais alguns bytes a partir do endereço #1F0000. É quando acionamos a opção DivX VOD pela primeira vez, para gerar o código de identificação do reprodutor DivX. Até mesmo bytes isolados são alterados nessa operação! Se essa FLASH não permite gravar bytes isolados, então o player tem que ler um bloco da FLASH, alterar alguns bytes, e regravá-lo inteiro.

O arquivo backup1.bin é o backup inicial da minha FLASH com o firmware Rictad 3.2. Coincidentemente, esse firmware vai até o endereço #1EFFFF (sem considerar o checksum). De #1F0000 a #1F0003 deveria estar o checksum (como está no arquivo do firmware). Porém, no endereço #1F0000 começa a string "MT23" gravada pelo player (mais à frente veremos mais detalhes sobre isso), de modo que se abrirmos esse arquivo no MTKRemaker receberemos aviso de checksum errado. Se o firmware tivesse ficado 1 byte maior , o próprio player teria o corrompido, podendo fazer aparecer sintomas estranhos.

Então peguei o backup1.bin e inseri o código #BB (uma marca, para facilitar a identificação) de #1F0004 até #1FFFFF. Atualizei com o MTKTool 1.31, desliguei o player, religuei, fiz algumas operações (inclusive o VOD) e fiz um novo backup, que está no arquivo backup2.bin. Aqueles poucos bytes que acompanhavam a string "MT23" após o endereço #1F0004 voltaram. Além disso, o trecho de #1F010B a #1F7FFF foi apagado. Foi aqui que eu me confundi anteriormente. Pensei que havia sido o processo de atualização serial que só tinha apagado até #1F7FFF, esquecendo que eu havia gravado até #1FFFFF. Mas foi o player que apagou esse trecho após a atualização, como veremos a seguir.

Em seguida, utilizei o firmware original, que só vai até #1DC917, e adicionei #BB a partir de #1DC914 (passando por cima do checksum) até #1FFFFF. Após reiniciar o player, fiz algumas operações (menos o VOD) e copiei a FLASH novamente. Este novo dump está no arquivo backup3.bin e não há nenhuma alteração. Todos os #BBs que eu adicionei estão lá. Nada de string "MT23". Aí, reiniciei o player novamente e fiz apenas mais 1 operação: o DivX VOD. No arquivo backup4.bin temos o conteúdo da FLASH logo após o VOD. A string "MT23" foi reinserida em #1F0000 seguida de alguns bytes novamente. Podemos ver que alguns #BBs ficaram no meio dos bytes inseridos, dando a idéia de que os bytes podem ter sido mesmo inseridos individualmente! Mas pode ser que o setor tenha sido lido pelo player, modificado na memória e regravado na FLASH. E novamente o trecho de #1F010B a #1F7FFF foi apagado. Tudo isso após o DivX VOD ser selecionado. Fiz esta experiência 2 vezes.

O arquivo backup5.bin é o backup da FLASH logo após a atualização via pen drive com o firmware original (no tamanho certo, sem os #BBs). Vemos que a FLASH foi apagada até o endereço #1FBFFF. O trecho a partir de #1FC000 (HDCP block?) ficou preservado, pois os #BBs da atualização anterior ficaram lá.

Já o arquivo backup6.bin foi dumpado logo após a atualização via serial com o firmware original. A FLASH foi apagada até o endereço #1FFEFF. Apenas o pequeno trecho final a partir de #1FFF00 ficou preservado. Pode ser limitação do MTKTool ou uma peculiaridade da FLASH ou mesmo do MT1389S. Seja como for, eu quase não consegui mais remover esse trecho com #BB. Se preenchesse um firmware com #FF até o final, os #BBs não eram sobrescritos na atualização. Falha do MTKTool? Outra peculiaridade? Só consegui "apagar" o trecho final com #00. Então vi que qualquer valor pode ser usado nestes últimos 256 bytes, menos #FF! . (EDIT: Não é bem assim. Na verdade, é impossível alterar um bit de 1 para 0. Isso só é possível no erase, como será explicado mais à frente pelo Ryan. Por isso foi possível programar alterando #FF para #BB e #BB para #00, mas agora não é mais possível gravar nada, até que o setor seja apagado um dia.) Minha FLASH ficará com esses 0s no finalzinho para sempre.

Também fiz um teste adicionando o HDCP block do DVP5990 em #1FC000 (a princípio, se há uma chave privada e seu correspondente KSV para ser trocado com o KSV da TV, ambos os aparelhos gerarão a mesma chave mestra para compartilharem dados criptografados, mesmo que a chave seja de outro aparelho), mas a HDMI continuou sem funcionar.

[Jefferson]

Durante aquele tempo em que fiquei com a FLASH "travada", eu postei imagens do meu DV397H aberto e até mesmo o datasheet da FLASH. E no final daquilo tudo cheguei à conclusão que esse aparelho com chipset MT1389S tem lá suas peculiaridades na atualização.

Agora me deu um nó...

Seu aparelho (MT1389S) tem uma flash paralela e uma EEPROM . É a configuração "normal".
Já o de Allanzin (MT1389M) tem uma flash serial e nenhuma EEPROM visível . Eu suspeito que de alguma forma esses aparelhos guardem as preferências de usuário na própria flash.

Faria sentido esse comportamento se você tivesse o MT1389M, mas não com o MT1389S...

Tenho que checar se o mesmo acontece nos meus aparelhos.

[Jefferson]

Esqueci de mencionar: Seu aparelho também não tem um chip HDMI externo.

[jmaraujo]

Mas não vi chip HDMI. Ou está do outro lado da placa ou é embutido no MT1389DXE

Está incluido no MT1389S (4ª geração).

[jmaraujo]

Se quiserem analisar outro firmware, no arquivo anexo está o firmware extraido do DVP3962/37 que está postado no fórum do DVP5100, e no seguinte link está o firmware oficial da Philips: http://www.p4c.philips.com/files/d/dvp3962_37/dvp3962_37_fus_aen.zip

O firmware foi extraido por Joel Iglesias, o crédito vai para ele.

[rafalibrenz]

Hoje eu tirei as fotos internas do DVP5990.

No total são 16 fotos.

Eu vou disponibilizar elas de duas formas:

1. Vou anexar todas aqui nesse post, em um arquivo rar de 18,7 MB (dividido em 4 partes). Aí elas estão sem resize. Só passei pelo Photoshop, onde dei um Shapen e salvei em JPG com qualidade 8 (High) (fica bem menor do que a compressão superfine que eu uso na câmera). A minha câmera (Canon SX110IS) tem 9 megapixels, então algumas fotos estão com 3456 x 2592 pixels. As que estão com menos foram cropadas pois tinham áreas totalmente inúteis.

2. Para facilitar a visualização eu também coloquei todas elas em um álbum público do PicasaWeb. Aqui elas estão com aproximadamente 2 megapixels apenas. 1600 pixels na maior dimensão.

Todas as fotos estão com os dados EXIF, para satisfazer aos curiosos.

Hoje mesmo eu ia extrair o firmware, mas não achei a porta serial na placa...

Estou desconfiado com aproximadamente 80% de 'certeza desconfiométrica' de que a serial é aquele soquete branco com 4 pinos bem perto do chip da memória FLASH.

Mas estou em dúvida, pois não enxerguei os escritinhos "TX, RX, GND" perto dos pinos, como estou acostumado.

Alguém me confirma se a serial é ali mesmo? É só alguém me confirmar, que aí eu tento ler o firmware.

Aaaah... Só que eu precisaria, além disso, saber a pinagem (TX, RX, GND) pra saber de que lado eu encaixo o meu cabo (que não tem aquele conector do soquetezinho), já que eu não consigo ler. Existe um padrão para essa pinagem? E se eu colocar virado, corro algum risco?

[Jefferson]

Hoje mesmo eu ia extrair o firmware, mas não achei a porta serial na placa...

Estou desconfiado com aproximadamente 80% de 'certeza desconfiométrica' de que a serial é aquele soquete branco com 4 pinos bem perto do chip da memória FLASH.

Mas estou em dúvida, pois não enxerguei os escritinhos "TX, RX, GND" perto dos pinos, como estou acostumado.

Alguém me confirma se a serial é ali mesmo? É só alguém me confirmar, que aí eu tento ler o firmware.

Muito provavelmente, é. Se você tiver um multímetro pode conferir facilmente.

Com o aparelho desligado da tomada e o multímetro medindo continuidade, coloque uma ponta em cada um dos dois pinos centrais do conector e arraste a outra pelos terminais da CPU. Se houver continuidade, é a porta serial.

Cuidado: NUNCA manipule a porta serial com o aparelho ligado na tomada, se não tiver extraído o firmware original ainda. O "ruído" eletromagnético presente nos seus dedos pode ativar a rotina de apagamento da flash.

Aaaah... Só que eu precisaria, além disso, saber a pinagem (TX, RX, GND) pra saber de que lado eu encaixo o meu cabo (que não tem aquele conector do soquetezinho), já que eu não consigo ler. Existe um padrão para essa pinagem? E se eu colocar virado, corro algum risco?

Se seu cabo só tem três fios (não tem +3.3V), não há risco algum. De qualquer forma GND é facilmente identificável porque dá continuidade para conectores metálicos da placa.

[Jefferson]

Para quem, baseado na simplicidade na operação de pendrives, não entende como uma memória flash seja assim tão "fresca" para se gravar como eu venho dizendo, este artigo na Wikipedia dá alguns esclarecimentos.

Um resumo (acrescentando coisas que eu sei de outras fontes):

• Só é possível mudar um bit qualquer de uma EEPROM (incluindo as flash) para "1" durante uma operação de apagamento. Durante a escrita só é possível gravar "0"s. É por isso que uma memória apagada apresenta "FF"s (11111111 11111111).
• Existem duas tecnologias: "NOR" e "NAND". A "NOR" é mais flexível na programação e leitura (permite até Execute In Place), mas é mais cara e por isso menos comum. Eu acredito que todas as flash usadas em DVD players sejam NAND.
  
• Uma memória NAND só pode ser apagada por setores/blocos. E esses setores não costumam ser menores que 8K, mas em sua maioria tem de 32K a 64K (pelo menos para memórias de 2MB).
• Uma memória NAND pode ser programada por "páginas" tão pequenas quanto 512 bytes, sempre tendo em mente que 1)A página tem que estar apagada antes 2)Se você quiser escrever outra coisa no mesmo lugar precisa apagar o bloco inteiro antes.
• Uma EEPROM que pode ser programada um byte de cada vez chama-se "byte-programmable" (é o caso das memórias que guardam as preferências do usuário). A maioria das flash é "page-programmable".

Exemplos flash "byte-programmable"

AM28F020 (256 KB)

Exemplos flash que podem ser programadas byte por byte mas não são "byte-programmable" porque requerem que o setor seja apagado antes.

EN25F80 (2MB - SPI) - Usada no Eletrovision EV-597


Rictad,

A flash do seu aparelho (MXIC MX29LV160C) parece ser capaz de programação byte-por-byte. Isso não está absolutamente claro no datasheet. Mas uma coisa está clara (página 16):

Programming is allowed in any sequence and across
sector boundaries. A bit cannot be programmed from a
"0" back to a "1". Attempting to do so may cause the
device to set Q5 to "1", or cause the Data# Polling algo-
rithm to indicate the operation was successful. However,
a succeeding read will show that the data is still "0".
Only erase operations can convert a "0"  to a "1".

Isso significa que, de qualquer forma, sua flash não é exatamente "byte-programmable". A CPU pode até escrever em algum lugar onde previamente haviam "FF"s, mas não pode mudar esse valor a não ser usando um ciclo "copia, apaga, muda e cola".

Até passou pela minha cabeça uma teoria: Será que o MTKFlash realmente está lendo a flash ou está lendo uma cópia da flash na RAM? Mas eu descartei essa possibilidade porque:

1)O firmware vai para a RAM com o bloco RISC descompactado. Ter duas cópias do firmware na RAM seria um desperdício de memória
2)Para isso o aparelho precisaria estar praticamente todo "ativo". A maioria dos parelhos permite a leitura do firmware mesmo em standby.

[rictad]

Rictad,

A flash do seu aparelho (MXIC MX29LV160C) parece ser capaz de programação byte-por-byte. Isso não está absolutamente claro no datasheet. Mas uma coisa está clara (página 16):

Programming is allowed in any sequence and across
sector boundaries. A bit cannot be programmed from a
"0" back to a "1". Attempting to do so may cause the
device to set Q5 to "1", or cause the Data# Polling algo-
rithm to indicate the operation was successful. However,
a succeeding read will show that the data is still "0".
Only erase operations can convert a "0"  to a "1".

Isso significa que, de qualquer forma, sua flash não é exatamente "byte-programmable". A CPU pode até escrever em algum lugar onde previamente haviam "FF"s, mas não pode mudar esse valor a não ser usando um ciclo "copia, apaga, muda e cola".

Então é como eu cheguei a dizer. Aquele trecho a partir de #1F0000 deve ser copiado na memória, ter alguns bytes alterados e regravado no setor da FLASH após este ter sido apagado. Isso justifica alguns bytes #BB ainda sobrarem em meio aos modificados, já que essa FLASH não permite o erase por byte, só por setores (apesar de permitir gravar por bytes). Caso fosse uma tentativa de gravar os bytes individuais, o trecho ficaria errado. Por exemplo, o byte correspondente ao "M" da string "MT23" gravado em #1F0000 tem valor #4D, quem em binário é 01001101. Se tiver um #FF na posição, obviamente #4D pode ser gravado, alterando os bits 7, 5, 4 e 1 da posição de "1" para "0". Mas se tiver o #BB na posição, que em binário é 10111011, uma tentativa de gravar #4D na posição, resultaria em 00001001 = #09 (os bits "0" não podem ser mudados para "1"). Como isso não ocorre, temos certeza que o setor foi apagado antes.

E também está claro o porquê de não conseguir "apagar" o setor final, de 256 bytes. Esse setor é o único não apagado pelo erase do MTKTool. Mas é possível programá-lo. Depois de programá-lo com #BB, tentei programá-lo com #FF, mas está mais do que claro que isso é algo impossivel de se fazer nessas FLASH's (é o mesmo que tentar rodar os bits 0 de cada #BB para 1, algo feito apenas no erase). Agora, como programei com #00 esse setor final, será impossível gravar qualquer valor naquelas posições. Só se um dia conseguir um erase total.

[rafalibrenz]

Depois de horas de vai-e-vem, consegui extrair o firmware do DVP5990.

Um pouco de história:

Primeiro não achei a serial. Aí o Jefferson me deu as dicas aqui no tópico e eu fui lá com o multímetro e constatei que o que eu achava que era a serial, era mesmo! Aí outro problema: meu conector do "o cabo" não encaixava no conector da serial. Tive que encontrar um (tirei de um cabo de áudio de drive de CD, que tinha uma das pontas duplas. A branca foi a que serviu) e trocar a ponta do meu cabo. Feito isso, testei o cabo (queria ter certeza se havia ligado certo o GND, TX e RX) com o DVP5980 antes de metê-lo no DVP5990. Leu direitinho a flash.

Aí fui pegar o firmware oficial do DVP5990 no site da Philips. Não consegui. Minha internet está maluca hoje à tarde. Então minha irmã, que mora bem longe, baixou o arquivo e me mandou por e-mail. Aí beleza: atualizei o firmware para a versão oficial. Testei. Tudo certo. Aí fui ler o firmware pela porta serial... E o programa (Mtk Flasher) não reconheceu a flash. Lá vou eu, com as unhas, tirar o adesivo... ficou uma meleca... lá vou eu, com um paninho com álcool, limpar a meleca... Ok! Consegui ler!

O chip de memória FLASH do meu DVP5990 é o ESMT F49L160BA-70T.

Com um pouco de Google consegui isso:

0x8C,  0x49,  0x200000, 0x10000, 4, EFST(F49L160BA)

Foi só adicionar no arquivo INI e aí consegui ler a Flash.

Abri o arquivo extraído no MtkReMaker, e abriu direitinho, sem erros.

Testei a HDMI do DVP5990 depois de tudo isso e continua ok.

Ou seja: tudo certo!

Segue o arquivo oficial que usei e o extraído via serial.