Firmware do conversor digital Zinwell ZBT-620A "tijolão" com função PVR

[rictad]

Depois resolvi fazer o teste de agendamento de gravação e notei o seguinte: ele não liga  o aprelho na hora agendada como um aparelho de DVD com função de gravação, tem que deixar o conversor ligado mesmo para que a gravação inicie, não adianta deixar só o cabo na tomada (eu particularmente não gosto muito dessa forma de iniciar a gravação devido ao gasto de energia). No mais todas as funções parecem funcionar perfeitamente, tanto no painel do tijolão, quanto no controle remoto.

Isso é uma característica do firmware original. Infelizmente, esses aparelhos não têm timer e nem modo standby. A única coisa que fica em standby é o painel frontal, aguardando que se aperte a tecla power para bootar o STB.

[rictad]

Esqueci de dizer que, apesar de agora suportar múltiplos controles remotos, somente a tecla power do controle original do aparelho ou a tecla power do painel frontal serão capaz de desligá-lo. Isso deve estar ligado ao firmware próprio do painel frontal. Quando o painel detecta que a tecla power do seu respectivo controle é acionada, ele repassa o valor da telca ao STB mas também determina o desligamento do aparelho, como se tivéssemos apertado a sua própria tecla power. Já com relação às demais teclas, ele apenas faz um bypass do valor ao aparelho. O resultado é que, se apertamos a tecla power de um controle suportado, mas que não é o original, o aparelho apenas interrompe algumas atividades, ficando em tela preta, como se estivesse num modo standby fajuto.

Rafael_netto, se você estiver pensando em testar o firmware no seu Semp, para ver se o controle funciona, espere um pouco. Ainda tenho que testar o backup do seu firmware, para ver se temos segurança no processo. Provavelmente o zmw_base_zinwell da versão 1.14.4 não é executado com sucesso pelo pen drive no seu aparelho porque ele precisa da estrutura correta do bloco flash0.rootfs. Esse é o quinto bloco, o menor, que completa a base do firmware. Dependo da versão, ele precisa ter algumas características. Acho que se você gravar o bloco flash0.rootfs da versão 1.14.4 (que não está disponível na imagem zim) na sua flash, vai poder executar o binário do Zinwell, mas o seu próprio não será mais executado até restaurarmos o bloco. Os blocos kernel e avail (rootfs maior) não devem fazer diferença pois devem ser idênticos. Depois eu testo isso aqui.

[rafael_netto]

Esqueci de dizer que, apesar de agora suportar múltiplos controles remotos, somente a tecla power do controle original do aparelho ou a tecla power do painel frontal serão capaz de desligá-lo. Isso deve estar ligado ao firmware próprio do painel frontal. Quando o painel detecta que a tecla power do seu respectivo controle é acionada, ele repassa o valor da telca ao STB mas também determina o desligamento do aparelho, como se tivéssemos apertado a sua própria tecla power. Já com relação às demais teclas, ele apenas faz um bypass do valor ao aparelho. O resultado é que, se apertamos a tecla power de um controle suportado, mas que não é o original, o aparelho apenas interrompe algumas atividades, ficando em tela preta, como se estivesse num modo standby fajuto.

Isso nós já havíamos verificado. O pessoal que fez o "transplante" de firmware antes da compatibilização se virou comprando o controle avulso do 633, mas precisou continuar usando o controle prata para ligar/desligar. Alguns recorreram a controle universal com aprendizado (learn).

Eu entendo que a tecla "Power" precisa atuar diretamente no hardware, pois ela deve ser interpretada antes do boot, quando ainda não há nenhum sistema operacional rodando no aparelho.

Rafael_netto, se você estiver pensando em testar o firmware no seu Semp, para ver se o controle funciona, espere um pouco. Ainda tenho que testar o backup do seu firmware, para ver se temos segurança no processo. Provavelmente o zmw_base_zinwell da versão 1.14.4 não é executado com sucesso pelo pen drive no seu aparelho porque ele precisa da estrutura correta do bloco flash0.rootfs. Esse é o quinto bloco, o menor, que completa a base do firmware. Dependo da versão, ele precisa ter algumas características. Acho que se você gravar o bloco flash0.rootfs da versão 1.14.4 (que não está disponível na imagem zim) na sua flash, vai poder executar o binário do Zinwell, mas o seu próprio não será mais executado até restaurarmos o bloco. Os blocos kernel e avail (rootfs maior) não devem fazer diferença pois devem ser idênticos. Depois eu testo isso aqui.

Então o bloco é esse. Como eu já disse anteriormente, até mesmo duas versões do próprio software do Semp são incompatíveis, isto é, se o conversor está com a versão 1.0.14c, ele não roda o zmw_base_zinwell 1.1.0 no pendrive e vice-versa. Eu poderia tentar mexer nesse bloco para ver se as versões ficam compatíveis. Mas ele precisa ter algo escrito nele? Apagá-lo seria suficiente?

Aproveitando, duas questões:

- uma vez que o software rode (isto é, se não tiver incompatibilidade com o flash0.rootfs) para eu trocar de versão bastaria simplesmente copiar o zmw_base_zinwell, ou é preciso fazer a atualização de firmware de dentro da interface (para escrever outras áreas da memória etc)

- uma curiosidade, por que existem duas versões do seu firmware? Não bastaria haver apenas uma, com suporte ao painel? Ou ela causa algum problema rodando no aparelho que não tem painel?

[x-td-d]

Atualizei meu ZBT-620C (tijolão) com controle prata utilizando o firmware disponibilizado no site da Ivision (no site a uma referencia apenas 633/620C) e o controle e o painel pararam, apenas liga/desliga esta funcionando.
Depois pesquisando, encontrei aqui os esclarecimentos e o motivo do problema já está claro.

Ajuda: Há alguma forma de atualizar sem o controle ? Ex: via tftp ou serial ?

[Jefferson]

Esqueci de dizer que, apesar de agora suportar múltiplos controles remotos, somente a tecla power do controle original do aparelho ou a tecla power do painel frontal serão capaz de desligá-lo. Isso deve estar ligado ao firmware próprio do painel frontal. Quando o painel detecta que a tecla power do seu respectivo controle é acionada, ele repassa o valor da telca ao STB mas também determina o desligamento do aparelho, como se tivéssemos apertado a sua própria tecla power. Já com relação às demais teclas, ele apenas faz um bypass do valor ao aparelho.

É assim que funciona o DIYOMATE S9. O receptor infravermelho é conectado diretamente a um microcontrolador que só reconhece o código de POWER do remoto e comanda a chave eletrônica que energiza o resto do aparelho. A intenção disso deve ser permitir que a CPU seja inteiramente desligada. Do contrário teríamos uma situação como a dos aparelhos baseado em MT13X9, onde basta plugar na tomada e a CPU já está "acesa".

Eu imagino que isso também seja o problema que acomete muitos receptores da SKY, que mesmo em standby ficam quentes como se estivesse a "full power".   

[rafael_netto]

Ajuda: Há alguma forma de atualizar sem o controle ? Ex: via tftp ou serial ?

De fato há, mas é um pouco trabalhosa.

Facilita um bocado se você já tiver o cabo conversor serial descrito pelo Rictad no início do tópico, uma vez que obtê-lo ou construí-lo não é muito simples. Ajuda mais um pouco mais se tiver conhecimento de Linux. E é necessária familiaridade com linha de comando.

Além do cabo, você precisa também obter o zmw_base_zinwell (executável da interface) modificado pelo Rictad, isso pode ser extraído do arquivo do firmware usando o Zimview (citado acima no tópico) e depois o Unsquashfs (acho que é nativo no Linux, há uma versão pra Windows, tenho que procurar onde eu encontrei).

É recomendável (não sei se é necessário) que o arquivo do Rictad corresponda à mesma versão do firmware que você instalou.

Uma vez estabelecida a comunicação serial, consegue-se chegar ao prompt do Linux (Busybox). Você deverá ter o zmw_base_zinwell do Rictad num pendrive. Como não é possível operar o aparelho, não se pode usar o recurso de montar o pendrive pela própria interface, então é preciso montá-lo manualmente, eu não sei o comando que faz isso mas deve ser simples.

(OBS: talvez na versão com PVR o pendrive seja montado automaticamente se iniciar o conversor com ele conectado)

Tendo montado o pendrive (em /mnt/usb) você poderá executar a interface do Rictad no próprio pendrive para testar (/mnt/usb/zmw_base_zinwell), e enfim copiar pra dentro do conversor com o comando cp  /mnt/usb/zmw_base_zinwell /mnt/hd

[zeurt]

Quanto ao cabo serial, este aqui funciona e tem preço razoável: http://ryan.com.br/smf/index.php?PHPSESSID=84fe64008fa9097d4951c86a6c3442a9&topic=424.msg9178370#msg9178370

[rictad]

Tendo montado o pendrive (em /mnt/usb) você poderá executar a interface do Rictad no próprio pendrive para testar (/mnt/usb/zmw_base_zinwell), e enfim copiar pra dentro do conversor com o comando cp  /mnt/usb/zmw_base_zinwell /mnt/hd

Não, assim não funciona. A partição flash0.app está montada em /mnt/hd, mas é somente leitura porque não dá para gravar diretamente nela como se fosse um dispositivo de disco. É possível fazer gravações na flash via Linux, mas isso vai ser um pouco complicado.

A melhor maneira para ele recuperar o STB é pelo CFE. Ele deve usar o Zimview, abrir o firmware versão 1.14.4a beta disponível aqui no tópico e extrair (exportar) apenas o bloco CODE. Aí, com o cabo, deve apertar CTRL-C no Putty antes que o Kernel seja chamado para entrar no prompt do CFE. No prompt, vai ter que gravar o bloco CODE exportado na partição flash0.app. Para isso tudo, além do cabo, vai precisar configurar o Putty e um servidor para transferência de arquivos, de preferência tftp. Mas aqui no tópico e naquele criado por você no htforum há informações que podem ajudar a ele.

De qualquer forma, para poder montar o pen drive sem que o zmw_base_zinwell o faça antes, há um script que sobe os módulos do Kernel necessários:

/usr/sbin/usbhd-start

É esse script que o binário chama quando detecta que algo foi conectado na USB. Depois que os módulos subirem e o dispositivo for reconhecido, é possível usar o comando mount.

Então o bloco é esse. Como eu já disse anteriormente, até mesmo duas versões do próprio software do Semp são incompatíveis, isto é, se o conversor está com a versão 1.0.14c, ele não roda o zmw_base_zinwell 1.1.0 no pendrive e vice-versa. Eu poderia tentar mexer nesse bloco para ver se as versões ficam compatíveis. Mas ele precisa ter algo escrito nele? Apagá-lo seria suficiente?

Aproveitando, duas questões:

- uma vez que o software rode (isto é, se não tiver incompatibilidade com o flash0.rootfs) para eu trocar de versão bastaria simplesmente copiar o zmw_base_zinwell, ou é preciso fazer a atualização de firmware de dentro da interface (para escrever outras áreas da memória etc)

- uma curiosidade, por que existem duas versões do seu firmware? Não bastaria haver apenas uma, com suporte ao painel? Ou ela causa algum problema rodando no aparelho que não tem painel?

São duas versões porque uma inicializa o painel do ZBT-633 e outra o do ZBT-620A. O único problema é que instalar as versões a e c trocadas deixa o painel do STB sem funcionar (mas o controle continuará respondendo, sendo possível instalar a versão correta depois).

Eu fiz os testes agora com o firmware do seu Semp e descobri para que serve o bloco rootfs nesses aparelhos. Ao contrário do nome, não é o sistema de arquivos (este está em flash0.avail). Ele é uma extensão da eeprom e, portanto, guarda configurações do aparelho. Mais especificamente, a programação de canais é guardada nesse bloco. Ao gravar o backup da flash do seu Semp no meu ZBT-620A (mais especificamente os blocos CODE, KERNEL, AVAIL e ROOTFS, já que não quis sobrepor o bloco com o CFE), o aparelho reiniciou e foi direto para o canal 4.1 Globo, que provavelmente está em sua programação aí e você não apagou antes de copiar a flash. Claro, não houve sinal algum, já que o sintonizador é diferente. Ao tentar rodar o meu zmw_base_zinwell pela USB ocorre erro, pois ele não entende as configurações que estão em flash0.rootfs. Exatamente o que acontece quando você tenta rodar aí.

Ao gravar apenas a flash0.rootfs do ZBT-620 versão 1.14.4, eu consigo rodar o meu zmw_base_zinwell pelo pen drive. Mas eu tenho que interromper o Busybox antes que o zmw_base_zinwell do Semp rode, pois ele detectada que a partição flash0.rootfs é diferente e a reformata, entrando na tela de procura de novos canais. Quando ele a reformata (é possível vermos mensagens "write flash" entre as mensagens "write eeprom"), o zmw_base_zinwell da versão 1.14.4 não irá rodar mais até que gravemos a flash0.rootfs dele novamente.

Isso é interessante, pois mostra que o firmware do Semp é o mais compatível até agora com todos os rootfs que eu testei. Por exemplo, os zmw_base_zinwell das versões 1.13.6 e 1.14.4 são compatíveis com o rootfs das versões 1.5.5 e posteriores, por isso é possível instalar essas versões sem o bloco rootfs diretamente em cima da 1.5.5. O novo firmware não vai usar a rootfs antiga. Vai reformatá-la antes. Mas não vai acusar erro. Agora, se instalarmos a versão 1.13.6 (ou 1.14.4) diretamente em cima da versão 1.3.2 (o caso do Cassien) vai ocorrer incompatibilidade total com a partição rootfs, o zmw_base_zinwell não vai executar e o STB não vai inicializar. Mas a 1.5.5 pode ser instalada em cima da 1.3.2, pois ela não dá erro e reformata a partição. A 1.14.4 também não é compatível com a rootfs do Semp. Mas o firmware do Semp é compatível com todas os tipos de partição rootfs que testei. Isso tudo é estranho, mas acho que a melhor maneira de evitar problemas de incompatibilidade nas atualizações é já disponibilizar o firmware com o quinto bloco flash0.rootfs, com as informações apagadas. Não sei porque, mas os fabricantes não costumam fazer isso.

Para que você possa fazer o teste do controle, estou enviando um arquivo zipado com duas partições flash0.rootfs e o binário da versão 1.14.4a. Uma partição possui as configurações apagadas e o outro possui o canal 10.1 Globo (aqui de Brasília) programado. Enviei duas partições para mostrar que não faz diferença se está apagada ou não. Você deve gravar apenas uma das duas partições pelo CFE no lugar da sua flash0.rootfs. Após isso, reinicie seu aparelho e fique pressionando CTRL-\ para interromper o Busybox, pois senão o seu zmw_base_zinwell irá reformatar a partição rootfs transformando-a em uma padrão do Semp novamente. Para poder montar o pen drive no Busybox sem antes entrar na interface do STB, execute o script que sobe os módulos necessários:

/usr/sbin/usbhd-start

O pen drive deve ser reconhecido como dispositivo /dev/sda e a primeira partição como /dev/sda1. Você poderá montá-la em /mnt/usb com o comando:

mount /dev/sda1 /mnt/usb

Aí é só rodar o zmw_base_zinwell da versão 1.14.4 de dentro de /mnt/usb.

Ao final, é só você deixar o seu firmware bootar totalmente que ele mesmo vai reformatar a partição flash0.rootfs, zerando as configurações. Por isso é totalmente seguro, pois você só gravará um bloco da flash pelo CFE, o qual o seu próprio aparelho se encarregará de reparar quando bootar. E também é possível restaurar o bloco pelo CFE.

[rictad]

Esqueci de dizer que, apesar de agora suportar múltiplos controles remotos, somente a tecla power do controle original do aparelho ou a tecla power do painel frontal serão capaz de desligá-lo. Isso deve estar ligado ao firmware próprio do painel frontal. Quando o painel detecta que a tecla power do seu respectivo controle é acionada, ele repassa o valor da telca ao STB mas também determina o desligamento do aparelho, como se tivéssemos apertado a sua própria tecla power. Já com relação às demais teclas, ele apenas faz um bypass do valor ao aparelho.

É assim que funciona o DIYOMATE S9. O receptor infravermelho é conectado diretamente a um microcontrolador que só reconhece o código de POWER do remoto e comanda a chave eletrônica que energiza o resto do aparelho. A intenção disso deve ser permitir que a CPU seja inteiramente desligada. Do contrário teríamos uma situação como a dos aparelhos baseado em MT13X9, onde basta plugar na tomada e a CPU já está "acesa".

Eu imagino que isso também seja o problema que acomete muitos receptores da SKY, que mesmo em standby ficam quentes como se estivesse a "full power".

O mais estranho é que antes de desligar o STB, o painel envia a informação da tecla power ao aparelho. Este ainda tenta realizar algumas operações, como interromper a exibição da imagem, mas é subitamente desligado. Deveria levar 1 ou 2 segundos para dar tempo do desligamento ser feito corretamente. Inclusive desmontando o dispositivo USB para sincronizar os dados de gravação.

[Jefferson]

O mais estranho é que antes de desligar o STB, o painel envia a informação da tecla power ao aparelho. Este ainda tenta realizar algumas operações, como interromper a exibição da imagem, mas é subitamente desligado. Deveria levar 1 ou 2 segundos para dar tempo do desligamento ser feito corretamente. Inclusive desmontando o dispositivo USB para sincronizar os dados de gravação.

Para mim isso é erro de projeto. Só faz sentido o microcontrolador tomar uma atitude ao receber o código POWER se o aparelho estiver em standby. Com o aparelho ligado quem deveria processar esse comando é a CPU, que depois de fazer o "housekeeping" mandaria um sinal para o microcontrolador desligar o aparelho.

Acho que o firmware "não sabe" que nesse aparelho o microcontrolador faz isso, por isso ainda tenta fazer o shutdown corretamente.

Infelizmente, se é mesmo o microcontrolador que desliga o aparelho não há muito que possa ser feito.