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.