Exibir mensagens

Esta seção lhe permite ver todas as mensagens deste membro. Note que você só pode ver as mensagens das áreas às quais você tem acesso.


Mensagens - Jefferson

291

Considerando que a HDCP key do Philips 5990 não serviu no LG DV397H do rictad, será que essa tal HDCP key tem que ser específica para cada modelo?

Ainda não sabemos sequer se o "HDCP block" da LG fica no mesmo endereço. Nunca vimos um firmware LG "completo".

Se tudo o mais estiver certo, pode ser que o firmware faça alguma espécie de checksum no bloco.

No momento só quem está habilitado a fazer isso é o Rafa, porque ele tem um aparelho que sabidamente perde o HDMI sem o tal bloco (os meus até agora são imunes). Rafa poderia trocar o bloco dele por outro para ver se continua funcionando.

Não estou dizendo que ele deva fazer isso. É arriscado e ele precisa muito do HDMI de seu player.

292

Ela até deve ser uma por modelo, devido à licença.

Isso está me deixando confuso. Segundo o que é dito no artigo na Wikipedia, cada modelo tem um conjunto de keys diferente, para que seja possível revogar a licença de apenas um modelo. Porém a revogação só faz sentido no caso de aparelhos de blu-ray, porque os discos blu-ray também fazem autenticação com o player.

1) Não faz nenhum sentido revogar a licença de um DVD player, porque ele vai continuar funcionando com o hardware que foi fabricado antes de sua licença ser revogada. Faz sentido em um Blu-ray player, porque o aparelho deixará de ser capaz de reproduzir discos novos. É possível até desabilitar o aparelho por comando de um programa no disco blu-ray, para que não possa reproduzir mais nada.

2) Do ponto de vista da fabricação é dificíl ter HDCP keys diferentes para cada modelo sem deixá-las expostas de alguma forma. Você não pode ter um chip HDMI (MT1392, PrismaClear) fabricado sob medida para cada modelo. Então o mais "fácil" é realmente essas HDCP Keys serem gravadas na flash ou em uma EEPROM (até mesmo numa PROM). Porém isso expõe as keys, violando a licença.

Só faria algum sentido para mim se de alguma forma esse "HDCP block" estiver também criptografado por uma rotina embutida no chip MT1389.


293
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):

Citar
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.

294
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.

295
Philips DVP5990 / Re: HDDs na porta USB do DVP5990?
« Online: Setembro 30, 2009, 06:36:07 am »
O link ao artigo é o seguinte: http://www.forodvp5100.com.ar/viewtopic.php?f=47&t=2341 e 2ª parte

Parte do que é dito lá me soa bastante estranho. Diodos não são limitadores de corrente. Substituir um diodo por outro de maior capacidade vai evitar que ele queime. Só isso.
Faz menos sentido ainda conferindo no datasheet que a corrente máxima do tal SR240 é 2A (o autor do post confirma isso). Já é quatro vezes a corrente de uma porta USB.

Para mim, não faz nenhum sentido. Entretanto, talvez eu não esteja familiarizado com alguma particularidade do uso de diodos Schottky.

Já a idéia de se colocar um regulador 7805 é uma gambiarra óbvia para qualquer um com conhecimento elementar de eletrônica. Porém continua sendo estranho, porque o 7805 é um danado de um desperdiçador de energia. Se você colocá-lo ligado a uma linha de 12V e drenar 500mA dele (seu limite é 1A) , vai estar usando 2.5W e desperdiçando 3.5W como calor. No total são 6W.

Se você levar em conta que o consumo nominal total desses DVD players costuma ser de apenas 10W, não posso deixar de imaginar que esse tipo de gambiarra não vá ser muito saudável para a fonte do aparelho.    

Peço desculpas se for muito offtopic... ;D

Não é.

296
Philips DVP5990 / Re: HDDs na porta USB do DVP5990?
« Online: Setembro 29, 2009, 02:10:23 pm »
A suspeita veio do fato de que supostamente HDDs maiores, ainda que de notebooks, pediriam mais corrente para trabalhar.


Que eu saiba, tentar relacionar consumo com capacidade nos HDDs de notebook é total perda de tempo.

Vejam estas tabelas de consumo:

http://techreport.com/articles.x/17010 (HDDs de 500GB)
http://www.xbitlabs.com/articles/storage/display/160gb-25inch-roundup_2.html#sect0 (HDDs de 160GB)
http://www.xbitlabs.com/articles/storage/display/25-inch-roundup.html (HDDs de 80GB)

O HDD de maior consumo de 80GB consome 2.8W
O HDD de maior consumo de 160GB consome 2.5W
O HDD de maior consumo de 500GB consome 2.5W

E os três podem falhar alimentados pela USB, porque 2.5W é exatamente o máximo que pode ser fornecido por uma porta só*.

Ainda olhando a tabela de 500GB pode-se observar que o Hitachi Travelstar consome apenas 1.7W.

Eu acho muito difícil afirmar que capacidade influencia quando claramente esse não é o fator mais importante.


*Oficialmente. Um DVD player pode fornecer mais que isso em sua porta USB se o fabricante quiser.

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

298
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.

299
Mais fontes de informação (não estão na lista do primeiro post):

Site de VB6ROCOD (não deixe de ver o fórum)
http://vb6rocod.euracks.com/

Site de HEJ456 (não deixe de ver o fórum)
http://hej456.com/

300
É bom também tomar cuidado com as posições 0x01, 0x02 e 0x03. Mudar qualquer um dos valores nessas posições faz com que o aparelho execute uma espécie de RESET onde dezenas de bytes são alterados e as posições 0x04 e 0x05 recebem os valores correspondentes ao DVP5980K_78.
A explicação para isso está em um documento de Cachirulo chamado "Eeprom-Info-1Nov2004". Os quatro primeiro bytes da EEPROM são um HEADER que o player verifica para validar seu conteúdo através da função "EPR_CheckHeader()". Segundo Cachirulo esses quatro primeiros bytes tem a string "MT37", mas isso deve ser coisa de versões antigas. Notem que os bytes 0x03 e 0x04 do DVP5980 formam a string "39".

Eu ainda estou tentando descobrir como se lê o conteúdo da EEPROM diretamente na shared memory. Até agora eu não consegui acertar a localização, pois os valores de offset como 0x1999 simplesmente não conferem.
http://ryan.com.br/smf/index.php?topic=179.msg9171930#msg9171930