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

[rictad]

O STB Zinwell ZBT-620A começou a ser vendido no Brasil há uns 2 anos e pouco, eu acho. É chamado de "tijolão", pois tem uma carcaça do tamanho de um vídeo cassete, apesar de ter uma pequena placa Zinwell 620 dentro. O "tijolão", devido a novas versões de firmware e uma carcaça um pouco diferente, também chegou a ser vendido como "620C" ou "620CZ", mas o hardware ainda era o do 620A, com o mesmo controle remoto. Porém, a empresa que comercializava os aparelhos Zinwell aqui no Brasil (Ekotech) foi descredenciada pela marca taiwanesa e passou a se autodenominar Zinwellbr (apesar de não ter mais nenhuma ligação com a Zinwell) e vender aparelhos chineses similares com nomes parecidos (ZBT 620N, ZBT 650N). Bom, a Zinwell licenciou uma nova empresa no Brasil, chamada Ivison, que herdou a assistência aos equipamentos Zinwell vendidos anteriormente e também passou a comercializar o aparelho como ZBT-620C numa versão "slim", mas que depois foi rebatizado de ZBT-633, para não ser confundido com o 620N da Zinwellbr. O problema é que o ZBT-620C/ZBT-633 slim, apesar de ter o hardware ainda identificado como "620A" na informação do firmware, possui algumas pequenas diferenças que não permitem o intercâmbio total do firmware. Seu painel frontal é diferente e seu controle remoto é do padrão Zinwell, preto e menor.

No site da Ivison passaram a oferecer um firmware para o ZBT-633 slim com função PVR (ainda que sem agendamento: a gravação é somente OTR e começa ao se apertar a tecla vermelha do controle). Como o 620C slim é exatamente o mesmo aparelho, essa versão também serve nele. Já o antigo 620A "tijolão" não pode ser atualizado com ela, devido às diferenças apontadas acima. Ou seja, ficou fora do suporte, apesar de ter sido herdado pelo nova licenciada. A atualização praticamente mata o aparelho: além do controle remoto não funcionar, o painel frontal não é inicializado e não funciona mais. A única forma de operá-lo é conseguir o controle remoto do slim. Mas não tem como voltar para a versão de firmware anterior, pois a nova versão é incompatível com desatualizações. Futuramente vou explicar o porquê. Algumas pessoas caíram nessa "armadilha" e tiveram que mandar seus aparelhos para a assistência técnica.

Devido a essa confusão de nomes e modelos, vou usar sempre os termos "ZBT-620A" ou "tijolão" para designar o Zinwell ZBT-620A/C/CZ versão "tijolão" de controle remoto grande prateado e os termos "ZBT-633" ou "slim" para designar o Zinwell ZBT-620C/633 versão slim de controle remoto menor preto.

A última versão do firmware do ZBT-620A é a 1.7.2. Essa versão está disponível também para o ZBT-633, mas elas não são intercambiáveis por causa das diferenças de hardware descritas acima (controle remoto e painel frontal). Já a última versão para o slim, com suporte a PVR, é a 1.13.6.

Basicamente o que eu fiz foi pegar os firmwares 1.7.2 do ZBT-633 e do ZBT-620A, extrair os executáveis principais de ambos e comparar seu código MIPS com o IDA. Achei as rotinas do remoto e de inicialização do painel frontal. A partir daí, extraí o executável do firmware 1.13.6 do ZBT-633, que tem a função PVR.  Então incluí no código suporte ao controle remoto e ao painel frontal do ZBT-620A e suporte ao controle de TV Samsung BN59-00604A, com função STB. Ou seja, 3 controles remotos funcionam com o firmware agora e ele inicia o painel frontal do ZBT-620A. Assim, montei um firmware para o "tijolão", com PVR e funcional.

O controle Samsung deve ser programado com o código 015 na função STB para funcionar. Essa codificação foi escolhida porque é das primeiras que possui mais teclas funcionando e mais fabricantes correspondentes, segundo a lista de códigos disponível no manual Samsung (Philips, DirecTV...). Provavelmente outros controles universais para STB devem ter alguma codificação correspondente e também funcionem. Algumas teclas têm função extra caso continuem sendo apertadas por mais de 1 segundo. Segue a tabela de correspondência de teclas desse controle que eu incluí no firmware:

Tecla	Função	Função ao segurar
Source	Resolução	Resolução
Channel +/-	Channel +/-	Channel +/-
Menu	Menu	Audio
Exit	Sair	Picture
Enter	Enter	Tecla vermelha - REC
Info	Info	Subtitle
Teclas de Navegação	Teclas de Navegação	Teclas de Navegação

Também deixei uma versão com a inicialização original do painel frontal do ZBT-633, mas com o suporte aos 3 controles, de forma que os firmwares tornaram-se razoavelmente intercambiáveis. O máximo que acontece ao se instalar o firmware modificado no aparelho errado é que o painel frontal não funciona. Mas como os controles de ambos os aparelhos são suportados, o usuário ainda poderá operar normalmente o STB e atualizar com o firmware correto.
A atualização da versão 1.7.2 para a 1.13.6 seria, a princípio, irreversível, devido à estrutura do arquivo de firmware, como vou explicar em outro post. Mesmo quando se atualiza com o firmware original, a documentação diz que não é possível retornar. Mas eu criei uma versão especial de retorno para a 1.7.2 apenas para o ZBT-620A "tijolão", para quem quiser voltar para a versão oficial, seja qual for o motivo. Já quem possuir o ZBT-633 poderá voltar normalmente para versão 1.13.6 oficial baixada no site da Ivision, mas não poderá voltar para a 1.7.2, como já não era possível mesmo.

Existem alguns clones Zinwell no mercado brasileiro (como os Aiko, Zirok, Semp etc) que talvez possam funcionar com os firmwares disponibilizados aqui. Mas só atualize se tiver absoluta certeza de que o firmware Zinwell é compatível com o seu aparelho e que você tenha ao menos um controle compatível com os 3 mencionados aqui. Tem alguns que são clones do "tijolão", com o controle prata grande. Outros são clones do slim. E tem outros que não tem correspondência de controle remoto e você pode ficar sem operar o STB. Então, se não for Zinwell ZBT-620/633, tenha cuidado! Mas se você já usa ou usou um firmware Zinwell ZBT-620, ou o do "tijolão" ou o do slim, poderá atualizar.

Posteriormente vou postar mais informações neste tópico. Vou fazer um resumo sobre a estrutura geral do firmware, vou mostrar como eu fiz as alterações e postar as rotinas do IDA. Aparentemente, a Ivision está terminando uma nova versão com agendamento de gravação. Deve ser só para o slim novamente. Se o padrão do firmware se mantiver, talvez eu possa criar uma versão com agendamento de gravação para o "tijolão" também.

Seguem os arquivos de firmware. Lembre-se, atualizar o firmware é uma operação segura, mas envolve alguns riscos. Tenha certeza de não desligar o aparelho enquanto o processo não terminar totalmente. De preferência, use no-break para evitar quedas de energia. Caso aconteça alguma falha que provoque a interrupção do processo, você precisará levar seu aparelho para a assistência técnica.


ATENÇÃO:

EDIT: Você só deve atualizar para as versões 1.13.6, inclusive a oficial da Ivision, se o aparelho estiver, no mínimo, com a versão 1.5.5. Caso a versão seja inferior a essa, como a 1.3.7 ou a 1.3.8, você deve atualizar primeiro para a versão 1.5.5 ou versões superiores que estão disponíveis na rede. Explicação nos próximos posts.

A versão 1.13.6a deve ser preferencialmente instalada no Zinwell ZBT-620A "tijolão", de controle grande e prateado. Mas se você instalar no aparelho errado, ainda poderá atualizar com a versão c depois.
Após a atualização, você não poderá instalar as versões antigas 1.7.2 e 1.5.5 oficiais. Caso, por algum motivo, isso seja necessário, você só poderá voltar se utilizar a versão 1.7.2_back especial disponibilizada aqui.

A versão 1.13.6c deve ser preferencialmente instalada no Zinwell ZBT-620C/633 slim, de controle Zinwell menor e preto. Mas se você instalar no aparelho errado, ainda poderá atualizar com a versão a depois. Após a atualização, você só poderá voltar para a versão oficial 1.13.6 disponibilizada no site da Ivision. Não poderá voltar para a versão antiga 1.7.2.

A versão 1.7.2_back só pode ser instalada no Zinwell ZBT-620A "tijolão" e só deve ser instalada se tiver algum motivo para voltar para a versão antiga oficial. Se você instalar no slim, vai precisar achar o controle do "tijolão" para operá-lo e atualizá-lo corretamente ou enviá-lo para a assistência técnica.

EDIT: Eu montei uma nova versão 1.7.2_back (1.7.2_back2), menor e mais segura, disponível alguns posts mais à frente. Prefira utilizar a nova versão 1.7.2_back2 em vez dessa 1.7.2_back aqui do post. Também incluí uma variação para ser usada exclusivamente no Zinwell ZBT-620C/633 slim.

Quando você atualizar para a versão 1.13.6, serão gravados 4 blocos na flash. Então você deverá esperar a barra de gravação encher 4 vezes! Se você atualizar a partir da versão 1.7.2 (ou 1.5.5), o STB será reiniciado 2 vezes, a primeira é para apagar a EPROM.
Se você voltar o ZBT-620A "tijolão" para a versão 1.7.2_back, o aparelho poderá travar após as 4 gravações. É normal! Somente quando tiver certeza que a barra encheu e travou, após a quarta gravação, você deverá desligar o aparelho da tomada, depois religá-lo e esperar o mesmo reiniciar 2 vezes.

[rictad]

Seguem fotos do ZBT-620A "tijolão" e seu controle, do ZBT-633 (idêntico ao ZBT-620C slim) e seu controle e, ainda, do controle Samsung que agora é reconhecido pelo firmware.

[zeurt]

Basicamente o que eu fiz foi pegar os firmwares 1.7.2 do ZBT-633 e do ZBT-620A, extrair os executáveis principais de ambos e comparar seu código MIPS com o IDA. Achei as rotinas do remoto e de inicialização do painel frontal. A partir daí, extraí o executável do firmware 1.13.6 do ZBT-633, que tem a função PVR.  Então incluí no código suporte ao controle remoto e ao painel frontal do ZBT-620A e suporte ao controle de TV Samsung BN59-00604A, com função STB. Ou seja, 3 controles remotos funcionam com o firmware agora e ele inicia o painel frontal do ZBT-620A. Assim, montei um firmware para o "tijolão", com PVR e funcional.

(...)

Posteriormente vou postar mais informações neste tópico. Vou fazer um resumo sobre a estrutura geral do firmware, vou mostrar como eu fiz as alterações e postar as rotinas do IDA. Aparentemente, a Ivision está terminando uma nova versão com agendamento de gravação. Deve ser só para o slim novamente. Se o padrão do firmware se mantiver, talvez eu possa criar uma versão com agendamento de gravação para o "tijolão" também.

Parabéns, rictad! Muito interessante o seu trabalho. Eu já estava ficando com saudades das modificações de firmware, da engenharia reversa, e dos seus excelentes relatos. Os "alunos" aqui aguardam ansiosamente novas aulas! Obrigado!
P.S.: Me parece que você é o único no Brasil a modificar um firmware de STB de TV digital aberta (na extensão e profundidade com que você modificou). Posso estar errado, mas realmente não me lembro de nenhuma ação parecida com a sua nesse campo...

[edufaria4]

Muito legal cara, parabéns!!!

Não sei se seria possível, mas os conversores SEMP modelo 2008H usam o mesmo Hardware do Zinwell, só mudando o tuner, o controle remoto e o painel frontal.

Na época em que eu estava mexendo com conversores, consegui instalar o firmware do Semp em um Zinwell e vice-versa.... tudo funcionava bem, porém ele não conseguia encontrar os canais, já que os tuners são diferentes....

Será que daria para fazer um firmware para o SEMP com PVR, baseado no que você fez do slim para o tijolão?

Abs,
Eduardo

[rictad]

Basicamente o que eu fiz foi pegar os firmwares 1.7.2 do ZBT-633 e do ZBT-620A, extrair os executáveis principais de ambos e comparar seu código MIPS com o IDA. Achei as rotinas do remoto e de inicialização do painel frontal. A partir daí, extraí o executável do firmware 1.13.6 do ZBT-633, que tem a função PVR.  Então incluí no código suporte ao controle remoto e ao painel frontal do ZBT-620A e suporte ao controle de TV Samsung BN59-00604A, com função STB. Ou seja, 3 controles remotos funcionam com o firmware agora e ele inicia o painel frontal do ZBT-620A. Assim, montei um firmware para o "tijolão", com PVR e funcional.

(...)

Posteriormente vou postar mais informações neste tópico. Vou fazer um resumo sobre a estrutura geral do firmware, vou mostrar como eu fiz as alterações e postar as rotinas do IDA. Aparentemente, a Ivision está terminando uma nova versão com agendamento de gravação. Deve ser só para o slim novamente. Se o padrão do firmware se mantiver, talvez eu possa criar uma versão com agendamento de gravação para o "tijolão" também.

Parabéns, rictad! Muito interessante o seu trabalho. Eu já estava ficando com saudades das modificações de firmware, da engenharia reversa, e dos seus excelentes relatos. Os "alunos" aqui aguardam ansiosamente novas aulas! Obrigado!
P.S.: Me parece que você é o único no Brasil a modificar um firmware de STB de TV digital aberta (na extensão e profundidade com que você modificou). Posso estar errado, mas realmente não me lembro de nenhuma ação parecida com a sua nesse campo...

Olá zeurt! Pois é, eu pretendo colocar as informações aqui tão logo seja possível. Já rascunhei um monte de coisa. Espero que isso abra portas para novas modificações. Existem muitos outros modelos de STB que usam a mesma placa Zinwell, mas com outros controles e outros sintonizadores. Dependendo das contribuições de outros usuários, pode ser que consigamos aumentar o leque de aparelhos compatíveis com o firmware.

[Ricardo]

Olá Ryan Rictad, preciso da sua ajuda!

Estou precisando DESESPERADAMENTE e com muita BREVIDADE (se possível para esta semana, já que espero há quase 3 meses, desde que meu gravador de DVD de mesa, Panasonic ES15 morreu em dezembro) de um conversor com PVR para poder gravar os programas e editá-los no HD do micro.

Queria comprar um 633, mas como terei muitas despesas tendo que comprar muitos Hard Disks pra isso (um pro conversor com PVR, outro pro micro pra editar os arquivos MPG TS's, outro para armazenamento definitivo dos arquivos editados... se tudo correr como imagino) prefiro então fazer este update no meu conversor Aiko (que é um Zinwell). Seja para poupar $ (da empreitada dos HDs), seja pq porque ficaria com 2 "iguais" aqui e o Aiko parado sem serventia mais (se usar o 633 com PVR).

Soube que o Aiko poderia se fazer este updatde update do 633 com PVR, mas com o custo de perder-se o painel frontal e de ter que arranjar um CR extra do 633 para usar nele, perdendo-se o CR do mesmo (Aiko). Muita confusão.

Vc Você, nosso herói salvador, hackeando este firmaware firmware matou a questão. Então eu teria meu Aiko com o PVR do 633, como quero, com suas funcionalibilidades funcionalidades intactas (painel frontal, visor) e continuando usando o controle remoto do Aiko (que vcs vocês chamam de "prateado", pra mim parecia ser... cinza... hehe) sem precisar correr atrás um CR do 633 (outra dor de cabeça, se fosse o caso).

Me ajuda aí, meu Aiko é:

- CR (controle remoto) "prateado" (pra mim parece cinza), igual vc você colocou aqui do 620A

como consta em informação do Sistema:
- Versão H/W: ZBT-620A V1.2
  Versão S/W: ZBT-620E v1.3.8
  Data: Nov-19-2007 02:35 PM

Qual meu firmaware firmware ? O 1.2 ou 1.3.8 ?

Pergunta: será que vai funcionar ? Se sim, qual arquivo devo usar. E, ele gerará um arquivo mpg TS igual os relatos (no htforum) que o 633 usa ? Se comportará igual ? Formatação FAT32 ou ext3 ? Lerá no PC ?

Outra: Não tenho aqui em casa (claro, posso comprar...) um pen drive para atualizar (o pen drive precisa estar formatado em FAT 32? E qq qualquer marca e tipo ?), posso usar uma Memória MicroSD (Kingston, 4Gb) com adaptador para pen drive (na ponta) ? Ou melhor não arriscar e comprar qq qualquer pen drive xing ling para a atualização ?

Por favor, ME AJUDE! E preciso dessa ajuda rápido! Desesperado aqui e ter um conversor com PVR e gravar o Carnaval da TV e talz etc..

[Jefferson]

Ricardo,

Você está confundindo "Rictad" com "Ryan" (eu).

[rictad]

Muito legal cara, parabéns!!!

Não sei se seria possível, mas os conversores SEMP modelo 2008H usam o mesmo Hardware do Zinwell, só mudando o tuner, o controle remoto e o painel frontal.

Na época em que eu estava mexendo com conversores, consegui instalar o firmware do Semp em um Zinwell e vice-versa.... tudo funcionava bem, porém ele não conseguia encontrar os canais, já que os tuners são diferentes....

Será que daria para fazer um firmware para o SEMP com PVR, baseado no que você fez do slim para o tijolão?

Abs,
Eduardo

Olá Eduardo,

Eu vi esse seu relato. Inclusive você foi um dos primeiros a postar informações em português a respeito do cabo serial para esses aparelhos, lá no HT Forum.

Se você ainda tiver como repassar os códigos de teclas do controle remoto do SEMP usando o cabo, seria totalmente viável acrescentá-lo ao firmware. Também é possível tentarmos identificá-los com as rotinas do firmware, mas fica bem mais difícil. Quando eu postar informações sobre as rotinas, a gente pode tentar ver isso. O maior problema será o sintonizador. Não sei se é possível incluí-lo, mas eu quero estudar com calma o firmware depois para ver se localizo rotinas para os sintonizadores.

[rictad]

Estou precisando DESESPERADAMENTE e com muita BREVIDADE (se possível para esta semana, já que espero há quase 3 meses, desde que meu gravador de DVD de mesa, Panasonic ES15 morreu em dezembro) de um conversor com PVR para poder gravar os programas e editá-los no HD do micro.

(...)

Soube que o Aiko poderia se fazer este updatde update do 633 com PVR, mas com o custo de perder-se o painel frontal e de ter que arranjar um CR extra do 633 para usar nele, perdendo-se o CR do mesmo (Aiko). Muita confusão.

(...)

Me ajuda aí, meu Aiko é:

- CR (controle remoto) "prateado" (pra mim parece cinza), igual vc você colocou aqui do 620A

como consta em informação do Sistema:
- Versão H/W: ZBT-620A V1.2
  Versão S/W: ZBT-620E v1.3.8
  Data: Nov-19-2007 02:35 PM

Qual meu firmaware firmware ? O 1.2 ou 1.3.8 ?

Pergunta: será que vai funcionar ? Se sim, qual arquivo devo usar. E, ele gerará um arquivo mpg TS igual os relatos (no htforum) que o 633 usa ? Se comportará igual ? Formatação FAT32 ou ext3 ? Lerá no PC ?

Ricardo,

Infelizmente eu não posso te ajudar com o desespero. Eu tenho outras coisas para fazer também e vou postar as coisas com calma. Esse fórum é construtivo. Se você mesmo pudesse ajudar, seria válido. Por exemplo, acho que vi em algum lugar que esse Aiko pode ser atualizado com o firmware do Zinwell tijolão. Não tenho certeza disso, mas seria interessante você procurar essa informação na Internet para ver se está correta. Se tiver, você poderá atualizar tranquilamente com a versão 1.13.6a, que é a feita para o tijolão, e reportar aqui no fórum. Seria uma informação muito bem-vinda. E a versão 1.7.2 não tem PVR e não deve ser usada a não ser no caso que expliquei no post inicial.

Essa função PVR é bem limitada. É a mesma do firmware 1.13.6 original do 633 e algumas informações sobre ela estão no site da Ivision e no HT Forum. Você só pode usar dispositivos acima de 16GB. Você pode usar FAT32, desde que o dispositivo esteja previamente formatado. Mas, neste caso, tem o problema de limitação do tamanho do arquivo (4GB). Se você formatar pelo próprio STB, o sistema de arquivos será ext3. De qualquer forma, a utilização da gravação no PC depois é bem pouco prática. Os arquivos são MPEG-TS. Você até consegue reproduzir ou converter o vídeo com alguns softwares disponíveis na Internet, mas só vídeo, sem som. Eu não sei ao certo, mas parece que ainda não tem como reproduzir o padrão de áudio adotado na TV digital brasileira no PC.

Outra: Não tenho aqui em casa (claro, posso comprar...) um pen drive para atualizar (o pen drive precisa estar formatado em FAT 32? E qq qualquer marca e tipo ?), posso usar uma Memória MicroSD (Kingston, 4Gb) com adaptador para pen drive (na ponta) ? Ou melhor não arriscar e comprar qq qualquer pen drive xing ling para a atualização ?

O pendrive deve ser FAT32 e pode utilizar o adaptador USB sim.

E, por favor, leia as Regras da Casa. Você recebeu o link ao se cadastrar.

[Jefferson]

As inscrições para o fórum estão temporariamente reabertas, para atender a pessoas interessadas neste tópico de Rictad.

Não vou aceitar mais replys como "guest" neste tópico, a não ser que estejam contribuindo com informação útil.

E todo mundo deve respeitar as Regras da Casa, como Rictad lembrou.

[Jefferson]

Se eu entendi corretamente a explicação de Rictad, ele pegou um firmware da Zinwell para aperfeiçoar um aparelho da Zinwell. Eu não vejo nada de fundamentalmente errado nisso. Porém quem quiser aplicar esse firmware em um aparelho que não seja de fabricação Zinwell deve ter em mente que a Zinwell pode não gostar nem um pouco. Como este é um site técnico, se você quiser relatar se funciona ou não e por quê, ótimo. Mas não recomendo a Rictad, por enquanto, fazer qualquer esforço no sentido de compatibilizar o firmware com outras marcas de aparelho.

Se ele quiser ensinar como fazer a compatibilização, já é outra estória. Fornecer o binário é que complica.

 

[rictad]

Estrutura do firmware

Vou fazer um resumo sobre a estrutura do firmware e como acessá-lo via cabo serial. O usuário MCNeto e o pessoal no HT Forum falam sobre isso aqui.
Os STBs baseados no Zinwell têm um sistema Linux embarcado. O arquivo de firmware .zim é estruturado em blocos que correspondem a partições da flash que serão montadas sob o Linux. Podemos visualizar e extrair esses blocos com o programa ZimView disponível aqui (no site do projeto há também informações sobre a estrutura do firmware). Se um arquivo de firmware aberto no ZimView possuir apenas um bloco, é porque apenas aquele bloco será atualizado, mantendo os demais intactos na flash. Ou seja, nem sempre o arquivo de firmware possui um firmware inteiro. Os principais blocos são: Load, Root, Kernel e Code. O bloco Load contém o CFE (Common Firmware Environment), que é aberto, sob licença da Broadcom. O bloco Root contém uma imagem de sistema de arquivos Linux, em formato Squashfs, com o BusyBox incorporado, compilado com apenas alguns dos principais comandos. O bloco Kernel contém o Kernel Linux compactado com gzip e o bloco Code contém o binário executável zmw_base_zinwell que será carregado na memória após a inicialização do sistema e fará todas as operações do STB. Esse bloco geralmente possui mais 2 arquivos, um pequeno script inicial preparatório para ser chamado antes do executável e um módulo (driver) Broadcom, e também está em formato Squashfs.

Quando o STB é ligado, o CFE é carregado e inicia a CPU, a memória e demais sistemas. Logo em seguida, chama o Kernel Linux, que monta todo o sistema de arquivos do bloco Root na raiz. Depois que o Kernel e seus módulos são carregados, os scripts de inicialização são executados. Por último, o bloco Code é montado e o executável é chamado. O executável inicializa o painel frontal, o sintonizador, mostra o logo na tela e passa a realizar todas as operações do STB. Isso tudo leva alguns segundos. Com um cabo serial é possível acessar o console do aparelho e interromper a inicialização para entrar no prompt do CFE, que possui comandos "Unix like", ou, após o Kernel Linux ser carregado, interromper a execução do binário zmw_base_zinwell para entrar no shell do BusyBox.

Se abrirmos a versão 1.7.2 no ZimView, veremos que só há o bloco Code. Podemos extrair o bloco e teremos uma imagem Squashfs que aparentemente está comprimida com zlib. Seria possível montar essa imagem no Linux ou extrair seu conteúdo, incluindo o binário zmw_base_zinwell, com o squash-tools. O problema é que ninguém conseguiu ainda fazer isso com esse padrão de versão (1.7.2, 1.5.5, etc). Sempre gera um erro com o gzip, o que sugere que deve ter sido usada alguma criptografia na compressão. Uma solução, então, é utilizar o cabo serial, para acessar o shell do BusyBox após a imagem Squashfs ter sido montada pelo Linux do aparelho e copiar o binário via pendrive.

Assim, para chegar ao binário zmw_base_zinwell da versão 1.7.2 do ZBT-620A, utilizei um cabo para celulares Siemens, mais precisamente um USB baseado no chip Prolific, de forma similar ao descrito pelo Ryan para extrair o firmware dos DivX Players Mediatek. Na placa do aparelho, podemos identificar um conector de 4 pinos com a identificação "J1 Debug Message". Uma vantagem desse tipo de cabo é que você não precisa usar o pino de +5V. Basta usar 3 pinos, RX, TX e GND.

Com o cabo feito, e com um aplicativo de terminal instalado no PC, como o Putty, é possível acessar às mensagens de console e entrar no prompt, tanto no do CFE, como no do shell do BusyBox. Há um tutorial feito pelo edufaria4 no HT Forum. Para entrar no prompt do CFE, assim que o aparelho for ligado, deve-se apertar CTRL+C no Putty. São só 1 ou 2 segundos para fazer isso, antes do Kernel Linux ser carregado e a inicialização prosseguir. Uma vez no prompt, podemos digitar "help" e ver a lista de comandos disponíveis. Um dos comandos é o "show devices", que mostra os dispositivos montados, inclusive as partições da flash. As partições correspondem aos blocos do arquivo de firmware .zim. A tabela abaixo mostra as principais partições e a quais blocos de firmware estão destinadas:

Partição	Tamanho	Bloco
flash0.avai0	3584KB	ROOT
flash0.rootfs	512KB	ROOT
flash0.cfe	320KB	LOAD
flash0.app	2048KB	CODE
flash0.kernel	1664KB	KERNEL

O ZBT-620 parece utilizar apenas a partição maior para o bloco Root, devido ao tamanho do sistema de arquivos.

Com o CFE, é possível gravar na flash ou fazer cópia dela via rede. Para levantar a ethernet do STB, usamos o comando "ifconfig". Para fazer uma rede ponto a ponto com o PC com uma placa de rede configurada para negociar o IP de forma automática, bastaria digitar "ifconfig eth0 -auto", como apontado pelo edufaria4. Porém, no meu caso não funcionou. Tive que usar uma configuração manual. Como exemplo, "ifconfig eth0 -addr=172.168.0.1 -mask=255.255.255.0", que levanta a placa de rede com IP 172.168.0.1. Aí, temos que configurar a rede do PC também manualmente, com Gateway 172.168.0.1 (o STB) e um IP na mesma faixa, por exemplo, 172.168.0.100. Além de ter a rede funcionando, é necessário ter um servidor FTP ou TFTP rodando no PC para receber e enviar os arquivos. Eu usei o tftpd (TFTP Server do Fedora 14), que é bem fácil configurar. Com rede e servidor FTP funcionando, podemos gravar e copiar as partições da flash com os comandos "flash" e "save". Algumas informações são necessárias para estas operações, como endereço de início do bloco e tamanho. Por exemplo, o comando "show devices" citado acima mostra, para a partição flash0.avail0, as seguintes informações:

flash0.avail0   New CFI flash at   1E000000   offset   00000000   size   3584KB

Assim, esse bloco se inicia em 1E000000 (primeiro bloco, já que o offset é 0) e tem o tamanho hexadecimal em bytes 380000 (3584*1024, transformado em hexadecimal). Para gravar essa partição no servidor FTP, usamos o seguinte comando (considerando que o PC esteja configurado com o IP 172.168.0.100):

save 172.168.0.100:flash0.avail 1E000000 380000

Isso irá gerar um arquivo flash0.avail no diretório compartilhado do servidor FTP, correspondente a um bloco de firmware, mais especificamente ao bloco Root, sem o header.

Se for necessário recuperar a flash, usa-se o seguinte comando:

flash -noheader 172.168.0.100:flash0.avail flash0.avail

Quer dizer, pegamos o arquivo flash0.avail no servidor FTP que está rodando no IP 172.168.0.100 e o gravamos na partição flash0.avail.

Para a partição flash0.app, as informações mostradas pelo "show devices" são as seguintes:

flash0.app   New CFI flash at   1E000000   offset   00450000   size   2048KB

O bloco começa em 1E000000+450000. Então, para copiar, usamos:

save 172.168.0.100:flash0.app 1E450000 200000

E, se precisarmos recuperar a flash:

flash -noheader 172.168.0.100:flash0.app flash0.app

Eu copiei todas as partições para eventual recuperação, pois iria "brincar" com o firmware. O único cuidado é não danificar a partição flash0.cfe, que é onde fica justamente o CFE. Não sei como o sistema acha o CFE na flash. Talvez no momento do boot os headers dos blocos são lidos à procura do CFE. Mas eu não vou me arriscar a movê-lo a outro bloco. 

Bom, mas isso nos dá apenas acesso aos blocos de firmware. Por exemplo, o arquivo flash0.app será exatamente o mesmo bloco Code extraído do arquivo .zim com ZimView. Não podemos, assim, acessar o binário zmw_base_zinwell. Para isso, precisamos esperar o STB bootar completamente e montar a imagem Squashfs do bloco Code para entrarmos no prompt do Busybox e copiarmos o binário do sistema de arquivos para um pendrive via USB.

Copiar o zmw_base_zinwell via USB

O MCNeto posta informações a respeito aqui. Quando o STB termina de iniciar, devemos apertar CTRL+\ no Putty. Isso interrompe a execução do zmw_base_zinwell e nos mostra o shell do BusyBox. Aí sim, podemos navegar pelo sistema de arquivos com comandos Linux. O comando "mount", sem opções, vai listar os pontos de montagem atuais. Podemos ver que /dev/mtdblock3 está montado em /mnt/hd. "mtblock" é como o Linux identifica os dispositivos flash. mtdblock3 é o quarto bloco (começa em 0) e corresponde a flash0.app listado pelo CFE. Para listarmos o conteúdo de /mnt/hd, basta digitarmos "ls -al /mnt/hd" e veremos 3 arquivos: bcmdriver.ko, settop e zmw_base_zinwell. O que nos interessa é o zmw_base_zinwell, o binário que realiza todas as operações próprias do STB. Podemos copiá-lo para um pendrive (ou HD externo) na USB. Porém, nem sempre conectar um pendrive na USB garante que o mesmo seja montado automaticamente. No caso da versão 1.7.2, ao conectar um pendrive, o dispositivo é reconhecido, mas não podemos montá-lo nem manualmente sem que antes subamos alguns módulos do Kernel. Não é muito difícil montá-lo manualmente, mas existe uma maneira mais fácil de acessar um pendrive: sair para o BusyBox (com CTRL+\) depois de montar o pendrive pelo próprio STB. Assim, com o STB ainda funcionando (zmw_base_zinwell rodando), colocamos o pendrive na USB e apertamos a tecla arquivo (file) no controle remoto. Quando o pendrive for reconhecido pelo aparelho, interrompemos com CTRL+\ e já entramos no prompt com o pendrive montado em /mnt/usb (pode-se verificar com o comando "mount"). Pronto, copiamos o zmw_base_zinwell com o comando "cp /mnt/hd/zmw_base_zinwell /mnt/usb" e depois desmontamos o pendrive com "umount /mnt/usb" para garantir a sincronização do sistema de arquivos antes de retirá-lo.
 
Após copiar o zmw_base_zinwell 1.7.2 do "tijolão", copiei o do slim também. Para isso, eu instalei a versão 1.7.2 slim no meu aparelho "tijolão". Como esperado, o STB ficou inoperativo (sem controle remoto e sem painel frontal). Mas com o cabo feito e com o firmware original copiado pelo CFE, não foi problema restaurar a versão anterior após copiar o binário.

Squash-tools para a versão 1.13.6 e correlatas

A versão 1.13.6, ao ser aberta no ZimView, possui os 4 blocos principais. Esse é um dos motivos que a atualização para essa versão impede a volta para a 1.7.2. Os 4 blocos são atualizados na flash. Voltar para a versão 1.7.2 apenas atualizaria o bloco Code, que é incompatível com o novo sistema de arquivos e o novo Kernel, e "mataria" o STB.

Para essa versão (e outras mais novas semelhantes), os blocos Code e Root continuam sendo imagens Squashfs, mas comprimidas com LZMA. Neste caso, é possível usar a versão correta do squash-tools com LZMA para extrair os arquivos da imagem do bloco Code (após o mesmo ser extraído do arquivo .zim pelo ZimView). A versão que usei foi a 3.3-4 de 64 bits do Mandriva. Provavelmente a de 32 bits também funciona. Como eu uso Linux Fedora (com uma versão do squash-tools LZMA mais nova mas incompatível) eu apenas extraí os binários do pacote RPM para usá-los diretamente, sem instalar. E com essa versão do squash-tools, também é possível recriar a imagem do bloco Code com o zmw_base_zinwell modificado e depois montar o novo arquivo .zim com o ZimView.

Há também muitas informações sobre a estrutura do firmware, o cabo serial e o zmw_base_zinwell no N.Z. Digital TV Forum, principalmente a partir deste post do tópico do Zinwell 620 HD.

Início da explicação das modificações

Por fim, fiquei com 3 binários zmw_base_zinwell. Um da versão 1.7.2 do "tijolão" e outro da mesma versão, mas do slim. Comparei rotinas destes binários no IDA Disassembler. O código usado nos binário é MIPS 32 bits little endian. Então o processador escolhido no IDA foi o mipsl. Com base nas descobertas, modifiquei o binário da versão 1.13.6 (que era só para slim) em um editor hexadecimal. Não é preciso corrigir nenhum checksum. O legal é que, com o cabo, você pode executar o binário modificado a partir do pendrive, sem precisar gravá-lo na flash. Se o código travar, é só desligar e religar o STB. Para isso, coloca-se diretamente o zmw_base_zinwell no pendrive. Com o pendrive já montado no STB, entramos no shell do Busybox e pedimos para executar o binário com o comando "/mnt/usb/zmw_base_zinwell", ou qualquer outro nome que você tenha dado temporariamente a ele. É muito mais prático!

A primeira coisa que procurei no IDA foram bytes que correspondessem aos códigos das teclas do controle. Esses códigos são mostrados no console do Busybox (visualizado com o Putty) quando o STB está rodando. Quando a tecla é reconhecida, aparece a mensagem "Key XXXXYYYY" (onde XXXX são 2 bytes que identificam o controle e YYYY 2 bytes que identificam a tecla) seguida de mensagens relacionadas à função correspondente (vol +, channel etc). Quando o controle não é reconhecido, mas ao menos é identificado, aparece só a mensagem "Key XXXXYYYY". Na maioria dos controles, o bit mais significativo do grupo XXXX é resetado quando a tecla é premida de forma rápida e setado quando a tecla é pressionada por mais de 1 segundo, o que torna possível a utilização de duas funções para cada tecla. Além desses bytes, deve existir ao menos mais 1 para identificar a função do controle, pois testando com o controle universal da Samsung, nas funções TV e VCR não consegui nenhum retorno. Alguns poucos retornos para algumas programações de controles de DVD e Cable. E vários retornos (mas não todos) para programações da função STB, como esperado.

Para o controle prata do "tijolão", os códigos são 38C7YYYY quando o aperto de tecla é simples e B8C7YYYY quando o aperto é constante. Para o controle preto do slim, os códigos são 009FYYYY e 809FYYYY, respectivamente. Então procurei pelos bytes C738 no binário do "tijolão" e 9F00 no do slim. Bom, tem ainda mais coisas em relação ao IDA, às rotinas e ao MIPS que quero explicar no próximo post. Inclusive tem um script IDAPython, o mips-analyser, que facilita a visualização do código MIPS, mas que só foi necessário para a achar as rotinas de inicialização do painel frontal. No entanto, se tivesse ele antes, achar as rotinas do remoto teria sido mais fácil.

[rictad]

Se eu entendi corretamente a explicação de Rictad, ele pegou um firmware da Zinwell para aperfeiçoar um aparelho da Zinwell. Eu não vejo nada de fundamentalmente errado nisso. Porém quem quiser aplicar esse firmware em um aparelho que não seja de fabricação Zinwell deve ter em mente que a Zinwell pode não gostar nem um pouco. Como este é um site técnico, se você quiser relatar se funciona ou não e por quê, ótimo. Mas não recomendo a Rictad, por enquanto, fazer qualquer esforço no sentido de compatibilizar o firmware com outras marcas de aparelho.

Se ele quiser ensinar como fazer a compatibilização, já é outra estória. Fornecer o binário é que complica.

Foi isso mesmo, Ryan. Apenas consegui atualizar uma versão de um aparelho da Zinwell (que foi deixada de lado pela própria) com o firmware de outra versão do mesmo aparelho da marca. E, por enquanto, apenas seguirei com as explicações de como foi feito.

[edufaria4]

rictad,

Ficarei bem atento às explicações.... parabéns pelo que já postou!!!

Bom saber que as informações que postei lá no HTForum há tempos foi útil para algo.

Abs,
Eduardo

[rictad]

Sobre a versão 1.7.2_back

A versão 1.7.2_back foi gerada com as partições que eu copiei da flash do "tijolão" antes de mexer no firmware. Mais precisamente, é formada apenas pela cópia das 4 partições principais. O ZimView foi usado para criar a imagem .zim, com sua função "Import Block". Portanto, a versão 1.7.2_back não contém todos os blocos do firmware, mas, assim como as versões 1.13.6, possui os blocos LOAD, KERNEL, ROOT e CODE, que são as partes que de fato formam o firmware. Ainda no ZimView, o "customer number" utilizado foi o 262, pois é o correspondente ao firmware do Zinwell ZBT-620/633. Se não for colocado exatamente esse número, o aparelho não reconhece o firmware. A imagem ficou maior que as imagens das versões 1.13.6 porque as 4 partições da flash foram copiadas em seu tamanho total. Só a partição flash0.avail0 tem 3,5 MB. Mas o bloco Root ocupa só uns 600 KB na partição. Acabei não me preocupando em cortar as imagens das partições para reduzi-las ao tamanho real utilizado pelo bloco.

EDIT: a nova versão 1.7.2_back2 disponibilizada mais à frente é menor e mais segura, pois não congela após a atualização. Além disso, também possui uma variação para o ZBT-633/620C slim.

[zeurt]

Pré-requisitos para entender com mais profundidade o que o rictad fez, e o que ele vem explicando:

1- Conhecimento Básico de Linux:
Aqui vai uma boa introdução: http://tldp.org/LDP/intro-linux/html/index.html
1a- Buzybox: http://www.busybox.net/about.html
1b- Formatos de Compressão de dados:
     gzip: http://www.gzip.org/
     zlib: http://zlib.net/
     LZMA: http://www.7-zip.org/sdk.html
1c- Sistemas de arquivos:
     Squashfs (comum em Linux embarcado) http://squashfs.sourceforge.net/ e Squashfs tools: http://tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html

2- Conhecimento de Redes:
    Emulador de Terminal, que permite a comunicação pela porta serial (Putty): http://www.chiark.greenend.org.uk/~sgtatham/putty/
    Configuração de rede (Intranet)
    Protocolo IP
    Protocolo TFTP

3- Conhecimento de Assembly (em geral):
O melhor guia introdutório que eu encontrei foi este aqui (voltado para ARM Assembly, porém com muitas explicações introdutórias sobre Assembly em geral): http://www.peter-cockerell.net/aalp/

4- Conhecimento de MIPS Assembly (já que o processador principal do chipset Broadcom BCM7402 tem arquitetura MIPS):
Encontrei este guia introdutório aqui: http://en.wikibooks.org/wiki/MIPS_Assembly
E aqui um MIPS Assembler gratuito (que eu ainda não testei: pode ser útil para facilitar a criação de "patches" no firmware): http://courses.missouristate.edu/KenVollmar/MARS/
Obs: O MIPS é um RISC - Reduced Instructions Set Computer (como o ARM). Portanto, fica mais fácil pra quem já tem um pouco de familiaridade com o ARM Assembly.

5- Familiaridade com o IDA Pro Disassembler: http://www.hex-rays.com/idapro/
Quem chegou a acompanhar as modificações de firmware Mediatek MT13x9, provavelmente não terá tantas dificuldades...

6- Quem quiser se aventurar a tentar fazer suas próprias investigações e modificações, deverá ter um conhecimento mínimo em eletrônica (ex: soldagem eletrônica):
Aqui as explicações do Ryan sobre o cabo serial (conversor RS232-TLL): http://ryan.com.br/wp/mtk-porta-serial/

Quem quiser complementar essas recomendações, adicionar mais links, etc., fique à vontade...

[zeurt]

Oi rictad,

Obrigado pelas excelentes explicações até o momento!!! 

Além das rotinas do controle remoto e do painel frontal, você chegou a encontrar outras coisas interessantes ou promissoras (ex: Fontes das Legendas e dos Menus, Trechos do firmware responsáveis pelo Media Player, ou outras coisas que nem imagino...)?

[rictad]

Oi rictad,

Obrigado pelas excelentes explicações até o momento!!! 

Além das rotinas do controle remoto e do painel frontal, você chegou a encontrar outras coisas interessantes ou promissoras (ex: Fontes das Legendas e dos Menus, Trechos do firmware responsáveis pelo Media Player, ou outras coisas que nem imagino...)?

Não, zeurt. O media player dele é muito limitado, não tem suporte a legendas. Mas tem a legenda de closed caption, com fonte muito ruim, como em quase todos os aparelhos. Talvez essa fonte possa ser alterada. Mas não procurei por fontes. Eu também acho que existem rotinas para vários sintonizadores, mas ainda não confirmei. Agora se pudesse achar e entender as rotinas de menu, seria algo promissor. Imagina um menu em que pudéssemos escolher o tipo de painel frontal e o tipo de sintonizador?

[rictad]

Atenção:

Após relatos de uma atualização mal sucedida a partir da versão Aiko 1.3.8 e após vários testes verifiquei que a versão 1.13.6, inclusive a oficial da Ivison, só pode ser instalada com segurança se você já tiver uma versão 1.5.5 ou superior. Eu alternei várias vezes da versão 1.7.2 para a versão 1.3.7 do Aiko (que pode ser encontrada aqui, disponibilizada pelo wuemura) e para a 1.5.5, em várias ordens de atualização e não houve problema algum, como esperado. Essas versões só possuem o bloco Code e são atualizáveis entre si. Porém, ao atualizar direto da versão 1.3.7, o aparelho trava exatamente no momento em que o logo Zinwell é exibido na tela. Com o cabo serial, é possível ver que o binário zmw_base_zinwell encontra um erro e é interrompido, voltando para o prompt do Busybox. A única forma de atualizar com segurança é atualizar, ao menos, para a versão 1.5.5 antes de atualizar para as versões padrão 1.13.6.

O que eu notei é que mais um bloco na flash é alterado após as atualizações: o bloco ROOT menor, correspondente à partição flash0.rootfs. Como acontece com outros aparelhos, não só a eeprom é modificada quando o firmware roda pela primeira vez, mas algumas partes da flash também. Há mensagens no console que indicam isso quando o aparelho é iniciado pela primeira vez após uma atualização: eeprom saved, flash saved...

Descobri que esse é o bloco alterado pois, ao ser restaurado apenas ele após o problema ser detectado, o aparelho volta a funcionar. As modificações nesse bloco feitas pelo próprio firmware são compatíveis entre as versões antigas. Mas, de alguma forma, a versão 1.13.6 não é compatível com as modificações feitas diretamente pelas versões 1.3.7 e 1.3.8. Por isso deve-se atualizar para as versões 1.5.5 (ou 1.7.X), que irão modificar novamente a flash e torná-la receptível às versões com PVR. Outra forma de contornar o problema talvez seja incluir um quinto bloco (o segundo bloco Root) em versões futuras do firmware.

[rafael_netto]

O Rictad merece todos os parabéns do mundo. Conseguiu fazer algo que "o HTForum inteiro" vem sonhando desde 2007!

Eu tenho um Semp DC2008H e consegui fazer as tarefas descritas aqui e no HTF, consegui fazer a cópia dos blocos de memória e também chegar ao prompt do Linux. Verifiquei as mensagens no console e obtive os códigos do controle remoto. Mas não mais que isso.

Estou aguardando o restante das explicações. Tentei me aventurar no IDA e não consegui descobrir nada! Não encontrei nada que fizesse sentido pra mim buscando pelos códigos que ele mencionou. Realmente para fazer isso é preciso um conhecimento que eu ainda não tenho. Apesar de ter experiência de mais de 20 anos com programação em várias linguagens, Assembly pra mim é mais ou menos como holandês, eu "reconheço" a linguagem e as instruções, mas não compreendo o que o código faz.

A esperança que eu tinha em relação ao Semp era debugar as rotinas dos medidores de sinal. O Semp ainda tem o mesmo bug das versões iniciais da Zinwell, que mostra um valor máximo de 98%, indica algo ligado à qualidade do sinal no lugar da "intensidade" e a outra medida não faz sentido. A Zinwell consertou o problema na versão 1.5.5 ou 1.7.1 (não tenho certeza) mas isso jamais foi implementado no Semp.

[Carneiro]

@rictad saiu a versão com agendamento.
http://www.ivision.net.br/uploads/product/file/ZBT-633/ZBT-633_1.14.4.zim

[rafael_netto]

@rictad saiu a versão com agendamento.
http://www.ivision.net.br/uploads/product/file/ZBT-633/ZBT-633_1.14.4.zim

É bom lembrar que essa versão tem pelo menos um bug, o closed-caption é ativado toda vez que o drive USB é montado.

Enquanto o Rictad não traz novidades, resolvi fazer umas experiências com o Semp, rodando "versões alternativas" do zmw_base_zinwell a partir do pendrive. Não consegui nenhum sucesso. Tendo a versão 1.1.0 instalada, qualquer outra versão, mesmo a 14c do Semp, é interrompida com um erro, e quando isso acontece, mesmo tentar rodar a versão instalada a partir do prompt também dá erro. Felizmente tudo volta ao normal religando o conversor. Só funciona rodar uma cópia da versão que está instalada no conversor.

Ao executar a interface do Rictad, ela chega a mostrar o logo Zinwell (lembrando que o Semp não tem logo). No terminal aparecem mensagens indicando que o tuner não foi encontrado, como era de se esperar, mas ao que parece não é isso que impede a execução.

No fim das contas, eu tinha esperança que alguma configuração do hardware não estivesse no executável da interface e sim em algum outro arquivo, em especial o bcmdriver.ko que vem no mesmo bloco, ou talvez no próprio sistema operacional. Mas parece que não é bem assim.

[rictad]

O MIPS utilizado no STB da Zinwell é um MIPS 32 (aparentemente R1 - revisão 1). Suas instruções são, em geral, de 4 bytes (palavras de 32 bits), mas existem algumas poucas que o IDA mostra como sendo de 8 bytes (2 palavras). As instruções precisam começar em endereços múltiplos de 4, pois são contadas de palavra em palavra. Como o zeurt já explicou acima, é um processador RISC, assim como ARM. A arquitetura RISC tem como algumas características uma quantidade reduzida de instruções e uma tentativa de fazer com que as instruções ocupem o mesmo espaço de memória e levem aproximadamente o mesmo tempo de execução. Isso faz com que um código mais enxuto seja quase sempre mais eficiente. Ao contrário da arquitetura CISC, usada nos x86, às vezes um código mais enxuto pode ser até bem mais lento, apesar de o programador ter um leque de instruções bem mais amplo à sua disposição.

Outra característica do MIPS é que ele é bi-endian: o código pode ser tanto little-endian como big-endian. O endiannes, também chamado de byte sex, neste caso específico, determina como é a ordem de armazenamento na memória dos bytes das palavras. No big-endian, os bytes mais significativos são armazenados primeiro, fazendo com que a referência às palavras no código seja feita na ordem direta. É assim no 8032 usado nos media player Mediatek. Já em um código little-endian, os dados são referenciados na ordem inversa. Então, se você quer guardar o valor 1A124C hexadecimal (0x1A124C) na memória usando um compilador little-endian de palavras de 32 bits, isso será escrito no código hexadecimal como 4C121A00. O ARM usa esse sistema por padrão, apesar de também ser bi-endian.

Bom, o MIPS do Zinwell está em modo little-endian. O compilador que o zeurt indicou acima também parece usar apenas esse modo. Apesar de não ser padrão, parece ser o modo mais utilizado. Nesse modo, o processador também é chamado de mipsel ou mips-ls ou, ainda, mipsl. Isso é importante, pois se mudarmos parte do código ou mesmo parte do sistema Linux embarcado (como eu já fiz e vou divulgar futuramente) devemos manter a arquitetura mipsel. Só daria para deixar em big-endian se mudássemos o sistema inteiro.

Uma outra característica do MIPS é um "cara" chamado delay slot. Achei muito estranho quando analisava algumas rotinas e via que instruções que carregavam valores em registradores localizadas imediatamente após um salto condicional eram executadas mesmo quando o salto era realizado. Como exemplo, temos o seguinte trecho de uma rotina que analisa códigos de tecla dos remotos (vou falar mais sobre essas rotinas depois):

Código: [Selecionar]

            loc_43DF74:                              # CODE XREF: sub_43DC2C+5C_j
.text:0043DF74 26 00 82 10                 beq     $a0, $v0, locret_43E010
.text:0043DF78 00 00 00 00                 nop
.text:0043DF7C C5 3A 02 24                 li      $v0, 0x3AC5
.text:0043DF80 49 FF 82 14                 bne     $a0, $v0, locret_43DCA8
.text:0043DF84 00 00 00 00                 nop
.text:0043DF88 08 00 E0 03                 jr      $ra
.text:0043DF8C 22 00 02 24                 li      $v0, 0x22
.text:0043DF90              # ---------------------------------------------------------------------------
.text:0043DF90
.text:0043DF90             locret_43DF90:                           # CODE XREF: sub_43DC2C:loc_43DDC4_j
.text:0043DF90 08 00 E0 03                 jr      $ra
.text:0043DF94 36 00 02 24                 li      $v0, 0x36

A sexta instrução é um jr (jump register). Ela faz um salto para o endereço guardado no registrador. No caso, $ra é o típico registrador de retorno de sub rotinas do MIPS. Toda vez que fazemos um salto para uma rotina, ele guarda o endereço de retorno em $ra para voltarmos com um jr $ra à rotina principal, no endereço imediatamente posterior ao da chamada. Esse registrador não é pilha. Se você fizer um salto após o outro, apenas será guardado o endereço do último retorno, perdendo-se o anterior. Para saltos recursivos, portanto, é preciso usar a pilha. No caso desta rotina, temos várias saídas possíveis (que vai depender do código de tecla identificado no trecho anterior). A saída leva o código da função identificada carregado em $v0. Mas notem que a instrução de atribuição, li $v0, xx é escrita após o jump. Isso acontece porque o MIPS irá ler a instrução de salto mas, antes de fazer o salto, ainda vai executar a instrução seguinte (e apenas ela). No caso de saltos condicionais, como os dois branchs do início do trecho (beq e bne), a instrução no delay slot será executada de qualquer forma. Daí, quando não se quer levar nenhum conteúdo novo após o salto que possa interferir na execução, usa-se um nop no delay slot. É estranho isso para quem não está acostumado, pois parece que contraria a ordem de execução. Um palpite meu para isso, pois não pesquisei a fundo, é que os saltos levam 3 ciclos do processador para se concretizar, enquanto uma operação store leva 4 ciclos e uma load, 5. Para manter a relação aproximadamente constante entre ciclos e instruções (um dos objetivos da arquitetura RISC), especialmente no caso dos saltos condicionais, optou-se por executar uma instrução a mais antes do salto ser realizado (que também será executada se o salto não for realizado), totalizando 2 instruções e 8 ou 9 ciclos, média de 4 ou 4,5 ciclos por instrução. Esse delay slot é comum em vários processadores RISC, sendo que alguns chegam a ter 2 slots. Mas alguns outros, como é o caso do ARM, não o possui.

Alguns compiladores corrigem a ordem das instruções para o programador não se preocupar com o delay slot. Podemos ver isso nessa dúvida de um programador que foi esclarecida. Também é possível desligar esse reordenamento, já que alguns vão querer programar no modo real. O IDA também tem uma opção "noreorder", que fica selecionada por padrão. Se você alterar essa opção, eu imagino que o código será mostrado na forma "mais humana", como se a instrução do delay slot viesse antes do salto.

Outra característica comum aos processadores RISC é a existência de pseudoinstruções. Uma delas é a "instrução" move $s0, $v0. Significa mover o valor que está no registrador $v0 para o registrador $s0. Mas isso não acontece dessa forma. A instrução real correspondente é add $s0,zero,$v0, que significa somar o valor de $v0 ao valor do registrador especial zero (que sempre tem valor 0) e colocar o resultado em $s0. Nesse caso, não há muitos problemas, pois equivale a apenas uma instrução real. Mas outras pseudoinstruções, como o mult, podem equivaler a várias instruções reais. O padrão do IDA é desassemblar com pseudoinstruções. Deve haver como mudar, mas isso não é importante para nós, já que não estamos preocupados com eficiência máxima.

Além disso tudo, o código MIPS costuma conter uma GOT (global offset table), criada pelos compiladores. É uma tabela anexada ao código que contém os endereços de todas as rotinas internas e também chamadas externas a bibliotecas. Os saltos entre as subrotinas não são referenciados diretamente. Ao contrário, um registrador, chamado $gp (global pointer, às vezes GOT pointer) fica apontando para as entradas da GOT. Quando se deseja saltar para outra rotina, o valor da GOT é carregado em algum registrador temporário, normalmente $t9, e o salto é feito para o endereço guardado nesse registrador. Na nova rotina, $gp é atualizado para apontar às próximas entradas. A vantagem dessa tabela é que permite que o código seja não dependente de posição. Em outras palavras, o código pode ser definido para rodar em outra posição de memória e o compilador apenas atualiza com o mesmo offset todas as entradas na GOT, sem mexer no código das rotinas. A desvantagem é que a desassemblagem fica mais difícil de ler. E aí que entra o script que citei no meu terceiro post do tópico. Ele percorre o código verificando as atualizações em $gp e remarcando os saltos para $t9 com o endereço real da rotina lido da GOT. Por enquanto, isso não é importante para entendermos as rotinas de teclas do controle remoto. Só será necessário para as rotinas do painel frontal. Mais informações sobre a GOT pode sem lidas aqui.

[rictad]

Rotinas de identificação de teclas do controle remoto

Após abrir o zmw_base_zinwell no IDA, selecionar o processador mipsl e esperar o software percorrer o código e marcar todas as rotinas (demora um pouco), podemos ver que o código é automaticamente endereçado com um offset de 0x400000, pois deve rodar a partir deste endereço na memória. Para uma melhor visualização, é melhor irmos em options, general e colocarmos 8 bytes para o opcode (algumas instruções têm 8 bytes). Para achar as rotinas do controle remoto do ZBT-620A versão 1.7.2, eu primeiro procurei pela sequência de bytes do código mestre do controle, que, como dito nos posts anteriores, é 0x38C7. Como o código é little-endian, devemos procurar pela sequência de bytes (apertando "b") C7 38. A primeira correspondência foi a seguinte:

Código: [Selecionar]

_text:0043E3DC 37 C8 02 34                             li      $v0, 0xC837
_text:0043E3E0 8C 00 82 10                             beq     $a0, $v0, locret_0_43E614

Olhando melhor a rotina, já que isso poderia ser qualquer outra coisa, ainda mais que são apenas 2 bytes, descobri que, coincidentemente, essa é a rotina que analisa a segunda parte do código do remoto, a parte do código das teclas e não o código mestre. Isso aconteceu pois o código para a tecla de navegação direita é 37C8 37C8.  A rotina começa em 0x43E28C. Segue o trecho inicial dela:

Código: [Selecionar]

_text:0043E28C                          # inicio interpretacao de teclas do controle remoto
_text:0043E28C
_text:0043E28C                         sub_0_43E28C:                            # DATA XREF: _got:00BC7E30_o
_text:0043E28C 24 20 85 00                             and     $a0, $a1
_text:0043E290 8D 72 02 24                             li      $v0, 0x728D      # tecla canal abaixo
_text:0043E294 37 00 82 10                             beq     $a0, $v0, locret_0_43E374
_text:0043E298 00 00 00 00                             nop
_text:0043E29C 8E 72 82 2C                             sltiu   $v0, $a0, 0x728E
_text:0043E2A0 1B 00 40 10                             beqz    $v0, loc_0_43E310
_text:0043E2A4 4D B2 02 34                             li      $v0, 0xB24D
_text:0043E2A8 CD 32 02 24                             li      $v0, 0x32CD
_text:0043E2AC 59 00 82 10                             beq     $a0, $v0, locret_0_43E414
_text:0043E2B0 00 00 00 00                             nop
_text:0043E2B4 CE 32 82 2C                             sltiu   $v0, $a0, 0x32CE
_text:0043E2B8 30 00 40 10                             beqz    $v0, loc_0_43E37C
_text:0043E2BC AF 50 02 24                             li      $v0, 0x50AF
_text:0043E2C0 E7 18 02 24                             li      $v0, 0x18E7
_text:0043E2C4 89 00 82 10                             beq     $a0, $v0, locret_0_43E4EC
_text:0043E2C8 00 00 00 00                             nop
_text:0043E2CC E8 18 82 2C                             sltiu   $v0, $a0, 0x18E8
_text:0043E2D0 6B 00 40 14                             bnez    $v0, loc_0_43E480
_text:0043E2D4 F5 0A 02 24                             li      $v0, 0xAF5
_text:0043E2D8 D7 28 02 24                             li      $v0, 0x28D7
_text:0043E2DC C3 00 82 10                             beq     $a0, $v0, locret_0_43E5EC
_text:0043E2E0 00 00 00 00                             nop
_text:0043E2E4 D8 28 82 2C                             sltiu   $v0, $a0, 0x28D8
_text:0043E2E8 8D 00 40 10                             beqz    $v0, loc_0_43E520
_text:0043E2EC D5 2A 02 24                             li      $v0, 0x2AD5
_text:0043E2F0 E5 1A 02 24                             li      $v0, 0x1AE5      # tecla arquivo
_text:0043E2F4 D9 00 82 10                             beq     $a0, $v0, locret_0_43E65C
_text:0043E2F8 00 00 00 00                             nop
_text:0043E2FC DF 20 02 24                             li      $v0, 0x20DF
_text:0043E300 76 00 82 10                             beq     $a0, $v0, locret_0_43E4DC
_text:0043E304 00 00 00 00                             nop
_text:0043E308
_text:0043E308                         locret_0_43E308:                         # CODE XREF: sub_0_43E28C+D8_j
_text:0043E308                                                                  # sub_0_43E28C+12C_j ...
_text:0043E308 08 00 E0 03                             jr      $ra
_text:0043E30C 21 10 00 00                             move    $v0, $0
_text:0043E310                          # ---------------------------------------------------------------------------
_text:0043E310
_text:0043E310                         loc_0_43E310:                            # CODE XREF: sub_0_43E28C+14_j
_text:0043E310 42 00 82 10                             beq     $a0, $v0, locret_0_43E41C
_text:0043E314 00 00 00 00                             nop
_text:0043E318 2B 10 44 00                             sltu    $v0, $a0
_text:0043E31C 2A 00 40 14                             bnez    $v0, loc_0_43E3C8
_text:0043E320 1D E2 02 34                             li      $v0, 0xE21D
_text:0043E324 6D 92 02 34                             li      $v0, 0x926D
_text:0043E328 72 00 82 10                             beq     $a0, $v0, locret_0_43E4F4
_text:0043E32C 00 00 00 00                             nop
_text:0043E330 2B 10 44 00                             sltu    $v0, $a0
_text:0043E334 3B 00 40 10                             beqz    $v0, loc_0_43E424
_text:0043E338 85 7A 02 24                             li      $v0, 0x7A85
_text:0043E33C 57 A8 02 34                             li      $v0, 0xA857
_text:0043E340 B6 00 82 10                             beq     $a0, $v0, locret_0_43E61C
_text:0043E344 00 00 00 00                             nop
_text:0043E348 2B 10 44 00                             sltu    $v0, $a0
_text:0043E34C 9E 00 40 14                             bnez    $v0, loc_0_43E5C8
_text:0043E350 55 AA 02 34                             li      $v0, 0xAA55
_text:0043E354 67 98 02 34                             li      $v0, 0x9867
_text:0043E358 CA 00 82 10                             beq     $a0, $v0, locret_0_43E684
_text:0043E35C 00 00 00 00                             nop
_text:0043E360 65 9A 02 34                             li      $v0, 0x9A65
_text:0043E364 E8 FF 82 14                             bne     $a0, $v0, locret_0_43E308
_text:0043E368 00 00 00 00                             nop
_text:0043E36C 08 00 E0 03                             jr      $ra
_text:0043E370 14 00 02 24                             li      $v0, 0x14
_text:0043E374                          # ---------------------------------------------------------------------------

Continuando a pesquisa pela sequência C7 38, a próxima encontrada finalmente estava na rotina que verifica o código mestre e funciona como filtro antes de chamar a rotina que analisa as teclas acima. Eu a chamei de "valida controle", já que é ela que faz a verificação inicial do código do controle antes de repassar para a rotina de interpretação de teclas. Segue início da rotina:

Código: [Selecionar]

_text:0043E694                          # valida controle
_text:0043E694
_text:0043E694                         sub_0_43E694:                            # DATA XREF: _got:00BC61C4_o
_text:0043E694
_text:0043E694                         var_28          = -0x28
_text:0043E694                         var_20          = -0x20
_text:0043E694                         var_1C          = -0x1C
_text:0043E694                         var_18          = -0x18
_text:0043E694                         var_10          = -0x10
_text:0043E694                         var_C           = -0xC
_text:0043E694                         var_8           = -8
_text:0043E694                         arg_57B8        =  0x57B8
_text:0043E694
_text:0043E694 79 00 1C 3C 5C DF 9C 27                 la      $gp, unk_0_78DF5C
_text:0043E69C 21 E0 99 03                             addu    $gp, $t9
_text:0043E6A0 C8 FF BD 27                             addiu   $sp, -0x38
_text:0043E6A4 30 00 BF AF                             sw      $ra, 0x38+var_8($sp)
_text:0043E6A8 2C 00 B1 AF                             sw      $s1, 0x38+var_C($sp)
_text:0043E6AC 28 00 B0 AF                             sw      $s0, 0x38+var_10($sp)
_text:0043E6B0 10 00 BC AF                             sw      $gp, 0x38+var_28($sp)
_text:0043E6B4 3C 80 90 8F                             lw      $s0, -0x7FC4($gp)
_text:0043E6B8
_text:0043E6B8                         loc_0_43E6B8:                            # CODE XREF: sub_0_43E694+C0_j
_text:0043E6B8                                                                  # sub_0_43E694+120_j ...
_text:0043E6B8 94 BE 99 8F                             lw      $t9, -0x416C($gp)
_text:0043E6BC 54 A1 04 8E                             lw      $a0, -0x5EAC($s0)
_text:0043E6C0 1C 00 A5 27                             addiu   $a1, $sp, 0x38+var_1C
_text:0043E6C4 01 00 06 24                             li      $a2, 1
_text:0043E6C8 09 F8 20 03                             jalr    $t9
_text:0043E6CC 20 00 A7 27                             addiu   $a3, $sp, 0x38+var_18
_text:0043E6D0 14 00 40 14                             bnez    $v0, loc_0_43E724
_text:0043E6D4 10 00 BC 8F                             lw      $gp, 0x38+var_28($sp)
_text:0043E6D8
_text:0043E6D8                         loc_0_43E6D8:                            # CODE XREF: sub_0_43E694+88_j
_text:0043E6D8 20 00 A2 8F                             lw      $v0, 0x38+var_18($sp)
_text:0043E6DC 11 00 40 10                             beqz    $v0, loc_0_43E724
_text:0043E6E0 1C 00 A5 8F                             lw      $a1, 0x38+var_1C($sp)
_text:0043E6E4 35 00 A0 04                             bltz    $a1, loc_0_43E7BC
_text:0043E6E8 3C 80 82 8F                             lw      $v0, -0x7FC4($gp)
_text:0043E6EC 3C 80 83 8F                             lw      $v1, -0x7FC4($gp)
_text:0043E6F0 58 A1 40 AC                             sw      $0, -0x5EA8($v0)
_text:0043E6F4
_text:0043E6F4                         loc_0_43E6F4:                            # CODE XREF: sub_0_43E694+144_j
_text:0043E6F4 5C A1 62 8C                             lw      $v0, -0x5EA4($v1)
_text:0043E6F8 0F 00 40 10                             beqz    $v0, loc_0_43E738
_text:0043E6FC 3C 80 82 8F                             lw      $v0, -0x7FC4($gp)
_text:0043E700 94 BE 99 8F                             lw      $t9, -0x416C($gp)
_text:0043E704 54 A1 04 8E                             lw      $a0, -0x5EAC($s0)
_text:0043E708 5C A1 40 AC                             sw      $0, -0x5EA4($v0)
_text:0043E70C 1C 00 A5 27                             addiu   $a1, $sp, 0x38+var_1C
_text:0043E710 01 00 06 24                             li      $a2, 1
_text:0043E714 09 F8 20 03                             jalr    $t9
_text:0043E718 20 00 A7 27                             addiu   $a3, $sp, 0x38+var_18
_text:0043E71C EE FF 40 10                             beqz    $v0, loc_0_43E6D8
_text:0043E720 10 00 BC 8F                             lw      $gp, 0x38+var_28($sp)
_text:0043E724
_text:0043E724                         loc_0_43E724:                            # CODE XREF: sub_0_43E694+3C_j
_text:0043E724                                                                  # sub_0_43E694+48_j
_text:0043E724 30 00 BF 8F                             lw      $ra, 0x38+var_8($sp)
_text:0043E728 2C 00 B1 8F                             lw      $s1, 0x38+var_C($sp)
_text:0043E72C 28 00 B0 8F                             lw      $s0, 0x38+var_10($sp)
_text:0043E730 08 00 E0 03                             jr      $ra
_text:0043E734 38 00 BD 27                             addiu   $sp, 0x38
_text:0043E738                          # ---------------------------------------------------------------------------
_text:0043E738
_text:0043E738                         loc_0_43E738:                            # CODE XREF: sub_0_43E694+64_j
_text:0043E738 24 80 84 8F                             lw      $a0, -0x7FDC($gp)
_text:0043E73C 90 D5 99 8F                             lw      $t9, -0x2A70($gp)
_text:0043E740 09 F8 20 03                             jalr    $t9
_text:0043E744 F0 57 84 24                             addiu   $a0, 0x57F0
_text:0043E748 1E 00 A3 97                             lhu     $v1, 0x38+var_1C+2($sp)  # carrega inicio do código da tecla para conferir controle
_text:0043E74C C7 38 02 24                             li      $v0, 0x38C7      # codigo mestre controle prata
_text:0043E750 FF 7F 63 30                             andi    $v1, 0x7FFF
_text:0043E754 D8 FF 62 14                             bne     $v1, $v0, loc_0_43E6B8
_text:0043E758 10 00 BC 8F                             lw      $gp, 0x38+var_28($sp)
_text:0043E75C 3C 80 91 8F                             lw      $s1, -0x7FC4($gp)
_text:0043E760 D4 B2 99 8F                             lw      $t9, -0x4D2C($gp)
_text:0043E764 18 00 A5 27                             addiu   $a1, $sp, 0x38+var_20
_text:0043E768 09 F8 20 03                             jalr    $t9
_text:0043E76C 50 A1 24 8E                             lw      $a0, -0x5EB0($s1)
_text:0043E770 18 00 A3 8F                             lw      $v1, 0x38+var_20($sp)
_text:0043E774 97 00 63 28                             slti    $v1, 0x97
_text:0043E778 19 00 60 14                             bnez    $v1, loc_0_43E7E0
_text:0043E77C 10 00 BC 8F                             lw      $gp, 0x38+var_28($sp)
_text:0043E780 00 C0 99 8F                             lw      $t9, -0x4000($gp)
_text:0043E784 09 F8 20 03                             jalr    $t9
_text:0043E788 00 00 00 00                             nop
_text:0043E78C 10 00 BC 8F                             lw      $gp, 0x38+var_28($sp)
_text:0043E790 1C 00 A4 8F                             lw      $a0, 0x38+var_1C($sp)  # carrega em $a0 o código da tecla inteiro para ser interpretado.
_text:0043E794 FF FF 05 34                             li      $a1, 0xFFFF      # carrega 0xFFFF em $a1 para o 'and $a0, $a1' na rotina de interpretação
_text:0043E798 40 B8 99 8F                             lw      $t9, -0x47C0($gp)
_text:0043E79C 09 F8 20 03                             jalr    $t9              # chama rotina de interpretação
_text:0043E7A0 50 A1 22 AE                             sw      $v0, -0x5EB0($s1)
_text:0043E7A4 10 00 BC 8F                             lw      $gp, 0x38+var_28($sp)

Essas rotinas funcionam em conjunto. A rotina "valida controle" primeiro acessa o código mestre da tecla e testa para saber se vem do controle remoto certo. Em 0043E748 lhu $v1, 0x38+var_1C+2($sp) , a instrução lhu carrega a meia palavra (half word = 16 bits) em $v1, a partir de um endereço guardado na pilha. Aquela é uma variável de pilha criada pelo IDA. É importante notarmos que a base da variável esta sendo somada a dois. Se quisermos saber o valor correto, basta apertarmos a tecla k para alternarmos a exibição entre valor hexadecimal e variável de pilha do IDA. Assim, temos que a instrução é lhu $v1,0x1E(sp) . Isso é só para ilustrar que o valor carregado, portanto, está na memória, no endereço que está guardado na pilha, apontado por sp+0x1E (offset de 0x1E a partir do stack pointer). É aí que está a primeira parte do código da tecla, que deve ser igual ao código mestre do controle para ser validada. O código total da tecla (32 bits) está a partir de 0x1C (sp). Por isso que a variável de stack, no IDA, estava com +2 de deslocamento. E também por isso foi usado o lhu em 0x1E(sp). Para carregar apenas a meia palavra com o código mestre. Como $v1 é um registrador de 32 bits, seu valor será algo como 0x0000XXXX, em que XXXX é a meia palavra carregada. Em seguida temos 43E74C li $v0, 0x38C7 , que carrega o valor para comparar o código mestre do controle em $v0. Depois, temos um AND do valor que está em v1$ com 0x7FFF (o bit mais significativo ressetado). Isso é para deixar passar também o código mestre quando se mantém a tecla do remoto segurada por mais de 1 segundo (0xB8C7). Somente nesses dois casos o resultado do AND será 0x38C7. Finalmente, ele compara o resultado que está em $v1 com o valor esperado em $v0. (0043E754 bne $v1, $v0, loc_0_43E6B8. Se não for igual, vai embora. Se for, ele irá fazer mais algumas operações, chamar algumas rotinas e, em  0043E790 lw $a0, 0x38+var_1C($sp) ele irá carregar $a0 com a palavra inteira referente ao código de teclas (bastaria a primeira meia palavra, mas o compilador deixou assim). Em seguida, carrega $a1 com 0x0000FFFF para que seja feito um and $a0, $a1 na rotina de análise do código da tecla, que é justamente para eliminar a meia palavra com o código mestre do controle, ficando só o código de 16 bits refente à tecla. Em seguida ele vai na GOT procurar o endereço da rotina de interpretação e carrega o seu valor em $t9, fazendo o salto em 43E79C jalr $t9 . Descobrir que esse é o salto para a outra rotina dependeu de intuição e testes, já que ainda não conhecia o mips-analyser. O fato de que a rotina de interpretação começa justamente com um AND entre os dois últimos registradores ($a0 e $a1) foi decisivo. Só para adiantar como fica mais fácil a visualização com o mips-analyser (que eu vou explicar em outro post), segue o mesmo trecho após rodar o script:

Código: [Selecionar]

.text:0043E738                         loc_43E738:                              # CODE XREF: sub_43E694+64_j
.text:0043E738 24 80 84 8F                             lw      $a0, offset aKeyX  # "key %x\n"
.text:0043E73C 90 D5 99 8F                             lw      $t9, offset sub_65CCE0
.text:0043E740 09 F8 20 03                             jalr    $t9
.text:0043E744 F0 57 84 24                             addiu   $a0, 0x57F0      # "key %x\n"
.text:0043E748 1E 00 A3 97                             lhu     $v1, 0x38+var_1C+2($sp)
.text:0043E74C C7 38 02 24                             li      $v0, 0x38C7
.text:0043E750 FF 7F 63 30                             andi    $v1, 0x7FFF
.text:0043E754 D8 FF 62 14                             bne     $v1, $v0, loc_43E6B8
.text:0043E758 10 00 BC 8F                             lw      $gp, 0x38+var_28($sp)
.text:0043E75C 3C 80 91 8F                             lw      $s1, 0xbda150
.text:0043E760 D4 B2 99 8F                             lw      $t9, offset sub_4504C0
.text:0043E764 18 00 A5 27                             addiu   $a1, $sp, 0x38+var_20
.text:0043E768 09 F8 20 03                             jalr    $t9
.text:0043E76C 50 A1 24 8E                             lw      $a0, -0x5EB0($s1)
.text:0043E770 18 00 A3 8F                             lw      $v1, 0x38+var_20($sp)
.text:0043E774 97 00 63 28                             slti    $v1, 0x97
.text:0043E778 19 00 60 14                             bnez    $v1, loc_43E7E0
.text:0043E77C 10 00 BC 8F                             lw      $gp, 0x38+var_28($sp)
.text:0043E780 00 C0 99 8F                             lw      $t9, offset sub_43C788
.text:0043E784 09 F8 20 03                             jalr    $t9
.text:0043E788 00 00 00 00                             nop
.text:0043E78C 10 00 BC 8F                             lw      $gp, 0x38+var_28($sp)
.text:0043E790 1C 00 A4 8F                             lw      $a0, 0x38+var_1C($sp)
.text:0043E794 FF FF 05 34                             li      $a1, 0xFFFF
.text:0043E798 40 B8 99 8F                             lw      $t9, offset sub_43E28C
.text:0043E79C 09 F8 20 03                             jalr    $t9

Agora, indo para a rotina de interpretação, vemos o AND citado anteriormente sendo realizado em 0x43E28C. Em seguida, em $v0 é carregado o código da tecla "canal menos". Ele compara o valor com $a0 e, se for igual, salta para locret_0_43E374 (observe o NOP logo abaixo do salto, no delay slot). Em 0x43E374, temos um jump de retorno, com a instrução li $v0, 0x24 no delay slot. Quer dizer que a rotina devolverá o valor 0x24 (código da função) em $v0, caso a tecla "canal menos" seja pressionada. Caso essa não seja a tecla pressionada, demais comparações são feitas, buscando-se outras teclas. A maior parte das comparações são feitas como a anterior. Carrega-se o valor que se quer comparar em $v0 e depois compara-se com o valor de $a0. Mas algumas são realizadas entre operações matemáticas especiais de rotação de bits. Isso é feito automaticamente pelo compilador, quando possível, para tentar enxugar o código.

Então, praticamente é isso. Uma rotina que filtra o código mestre antes de repassar o código inteiro a outra que retira o código mestre e analisa o código restante procurando códigos de teclas e devolvendo o valor da função correspondente. Ao final, se o controle for reconhecido mas nenhuma tecla for, a rotina sai em 43E30C move $v0, $0 com o valor 0 em $v0. Esse não é o final da rotina, as demais saídas estão após esta, devido a saltos internos.

Procurei as mesmas rotinas no zmw_base_zinwell versão 1.13.6 do ZBT-633. Buscando os bytes 9F 00 02 24 (procurar o mesma instrução li da rotina "valida controle" do outro aparelho, mas agora com o código mestre do controle preto, ou seja, li $v0, 9F . Nessa outra versão, a rotina pode ser encontrada em sub_0_43A5A8. O trecho que nos interessa é este:

Código: [Selecionar]

_text:0043A65C                         loc_0_43A65C:                            # CODE XREF: sub_0_43A5A8+6C_j
_text:0043A65C 28 80 84 8F                             lw      $a0, -0x7FD8($gp)
_text:0043A660 28 8A 99 8F                             lw      $t9, -0x75D8($gp)
_text:0043A664 09 F8 20 03                             jalr    $t9
_text:0043A668 50 76 84 24                             addiu   $a0, 0x7650
_text:0043A66C 1E 00 A3 97                             lhu     $v1, 0x40+var_24+2($sp)  # carrega inicio do código da tecla para conferir controle
_text:0043A670 9F 00 02 24                             li      $v0, 0x9F        # codigo mestre do controle preto
_text:0043A674 FF 7F 63 30                             andi    $v1, 0x7FFF
_text:0043A678 D6 FF 62 14                             bne     $v1, $v0, loc_0_43A5D4
_text:0043A67C 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)
_text:0043A680 2C 80 93 8F                             lw      $s3, -0x7FD4($gp)
_text:0043A684 CC A2 99 8F                             lw      $t9, -0x5D34($gp)
_text:0043A688 18 00 A5 27                             addiu   $a1, $sp, 0x40+var_28
_text:0043A68C 2C 80 92 8F                             lw      $s2, -0x7FD4($gp)
_text:0043A690 09 F8 20 03                             jalr    $t9
_text:0043A694 30 30 64 8E                             lw      $a0, 0x3030($s3)
_text:0043A698 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)
_text:0043A69C 1C 00 A4 8F                             lw      $a0, 0x40+var_24($sp)  # carrega código inteiro da tecla para ser interpretado.
_text:0043A6A0 9C A1 99 8F                             lw      $t9, -0x5E64($gp)
_text:0043A6A4 09 F8 20 03                             jalr    $t9              # chama rotina de interpretação
_text:0043A6A8 FF FF 05 34                             li      $a1, 0xFFFF      # carrega a1 para o "and a0, a1" na rotina de interpretação
_text:0043A6AC 21 80 40 00                             move    $s0, $v0
_text:0043A6B0 18 00 A2 8F                             lw      $v0, 0x40+var_28($sp)
_text:0043A6B4 5E 01 42 28                             slti    $v0, 0x15E
_text:0043A6B8 04 00 40 10                             beqz    $v0, loc_0_43A6CC
_text:0043A6BC 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)

E a rotina que verifica os códigos de teclas começa em sub_0_43A18C. Foi possível achá-la buscando algum código de tecla final do controle preto em instruções similares às da rotina do controle prateado. O importante nela foi verificar se os códigos de retorno das funções das teclas ainda são os mesmos. E são.

Assim, o que eu fiz foi criar minha própria rotina no zmw_base_zinwell do ZBT-633 para verificar as teclas dos três controles (o preto, o prateado e o da Samsung). Tive que achar um lugar vazio no binário para colocá-la, depois modificar o filtro do código mestre na rotina "valida controle" e, por fim, alterar na GOT o apontamento para o endereço da rotina de verificação, da rotina antiga para a nova.

Primeiro, achei uma região vazia no código (com vários zeros) grande o suficiente para inserir algumas rotinas. No código hexadecimal puro (sem o offset de 0x400000), este espaço começa em 0x389165. Mas como as rotinas devem começar em endereços múltiplos de 4 (e também para garantir realmente estar num local vazio) marquei para começar a nova rotina em 0x389170 (que é 0x789170 na memória).

Antes de fazer a nova rotina, fiz as alterações na rotina "valida controle". A primeira delas foi no filtro. Antes o filtro era assim, como mostrado anteriormente:

Código: [Selecionar]

_text:0043E75C 1E 00 A3 97                             lhu     $v1, 0x38+var_1C+2($sp)  # carrega inicio do código da tecla para conferir controle
_text:0043E760 9F 00 02 24                             li      $v0, 0x9F        # inicio codigo controle preto
_text:0043E764 FF 7F 63 30                             andi    $v1, 0x7FFF
_text:0043E768 D8 FF 62 14                             bne     $v1, $v0, loc_0_43E6CC/code]

Pela forma como eu implementei a nova rotina de análise de teclas, bastaria ter eliminado esse trecho colocando 4 NOPs. Como não sabia como seria a nova rotina, acabei implementando um filtro que ficou redundante. Na próxima versão do firmware eu vou eliminá-lo. Mas o filtro redundante ficou assim:

[code].text:0043A66C 1E 00 A3 97                             lhu     $v1, 0x40+var_24+2($sp)
.text:0043A670 85 00 02 24                             li      $v0, 0x85
.text:0043A674 85 47 63 30                             andi    $v1, 0x4785
.text:0043A678 D6 FF 62 14                             bne     $v1, $v0, loc_43A5D4

Como os códigos mestres permitidos agora são B8C7 e 38C7 (controle prata, mantendo e não mantendo a tecla pressionada por mais de 1 segundo), 809F e 009F (controle preto, idem) e B0FD e 30FD (controle samsung), fiz alguns ANDs com os bits desses códigos. O resultado é que se fizermos um AND entre qualquer um desses códigos e 0x4785, o resultado será 0x85. Mas esse filtro meia boca que eu fiz acaba permitindo outros códigos passarem, o que poderia fazer com que outros controles remotos interferissem no funcionamento do STB. Além disso, os próprios controles possuem alguns códigos de teclas trocados entre si. Por exemplo, a tecla numérica 2 no controle prateado tem código 38C7 906F. Já a tecla 1 do controle preto tem código 009F 906F. Então, esse filtro não resolveria esse conflito se apenas deixasse passar ambos os códigos. A solução foi fazer um filtro determinístico no início da nova rotina (como veremos a seguir), o que acabou por fazer esse filtro redundante (mas que eu esqueci de retirar).

A segunda modificação nessa rotina é mais importante:

Código: [Selecionar]

_text:0043A69C 1C 00 A4 97                             lhu     $a0, 0x40+var_24($sp)
.text:0043A6A0 9C A1 99 8F                             lw      $t9, -0x5E64($gp)
.text:0043A6A4 09 F8 20 03                             jalr    $t9
.text:0043A6A8 1E 00 A5 97                             lhu     $a1, 0x40+var_24+2($sp)

As mudanças são os dois lhu. O primeiro guarda a meia palavra referente ao código individual da tecla em $a0 e o segundo, no delay slot, guarda o código mestre em $a1 antes do salto para $t9 (rotina de análise das teclas) ser realizado.

Após isso, modifiquei o apontamento na GOT para o início da nova rotina de análise. Se originalmente a rotina começava em sub_0_43A18C, fiz uma busca binária pelos bytes 8C A1 43 00 (os endereços são de 32 bits) e achei em _got:00BAF84C a entrada apontando para a rotina. Em um editor hexadecimal, se procurarmos pela sequência, encontraremos no endereço 0x7ABB7C. Além do offset de 0x400000, há um outro offset de mais 0x3CD0 na GOT. Não pesquisei o porquê disso. Mas foi só alterar essa sequência para 70 91 78 00 (0x789170) para apontar para o início da nova rotina.

Por fim, a nova rotina foi feita em parte digitando diretamente no editor hexadecimal e em parte copiando e colando trechos das rotinas originals do ZBT-620A e 633, sem ajuda de compilador, a partir do endereço 0x389170 (devido ao offset de 0x400000). Como as instrução são simples (eu não procurei nenhum tipo de otimização) e os opcodes puderam ser encontrados buscando instruções idênticas no próprio código aberto no IDA, não tive muitos problemas. Basicamente, a rotina analisa o que foi repassado em $a1 para saber de qual controle se trata (filtro determinístico). Se não for nenhum código mestre esperado, ela retorna sem nada. Se for, é chamado o desvio para analisar as teclas de cada controle. Segue o início e o fim da rotina, pois é enorme:

Código: [Selecionar]

_rodata:00789170                         loc_0_789170:                            # DATA XREF: _got:00BAF84C_o
_rodata:00789170 FD 30 02 24                             li      $v0, 0x30FD
_rodata:00789174 14 02 A2 10                             beq     $a1, $v0, loc_0_7899C8
_rodata:00789178 FD B0 02 34                             li      $v0, 0xB0FD
_rodata:0078917C 6A 02 A2 10                             beq     $a1, $v0, loc_0_789B28
_rodata:00789180 00 00 00 00                             nop
_rodata:00789184 FF 7F A5 30                             andi    $a1, 0x7FFF
_rodata:00789188 9F 00 02 24                             li      $v0, 0x9F
_rodata:0078918C 05 00 A2 10                             beq     $a1, $v0, loc_0_7891A4
_rodata:00789190 C7 38 02 24                             li      $v0, 0x38C7
_rodata:00789194 0A 01 A2 10                             beq     $a1, $v0, loc_0_7895C0
_rodata:00789198 00 00 00 00                             nop
_rodata:0078919C 08 00 E0 03                             jr      $ra
_rodata:007891A0 21 10 00 00                             move    $v0, $0
_rodata:007891A4                          # ---------------------------------------------------------------------------
_rodata:007891A4
_rodata:007891A4                         loc_0_7891A4:                            # CODE XREF: _rodata:0078918C_j
_rodata:007891A4 65 9A 02 34                             li      $v0, 0x9A65
_rodata:007891A8 37 00 82 10                             beq     $a0, $v0, locret_0_789288
_rodata:007891AC 00 00 00 00                             nop
_rodata:007891B0 2B 10 44 00                             sltu    $v0, $a0
_rodata:007891B4 1B 00 40 14                             bnez    $v0, loc_0_789224
_rodata:007891B8 1D E2 02 34                             li      $v0, 0xE21D
_rodata:007891BC B7 48 02 24                             li      $v0, 0x48B7
_rodata:007891C0 59 00 82 10                             beq     $a0, $v0, locret_0_789328
_rodata:007891C4 00 00 00 00                             nop
_rodata:007891C8 B8 48 82 2C                             sltiu   $v0, $a0, 0x48B8
_rodata:007891CC
_rodata:007891CC                         loc_0_7891CC:                            # DATA XREF: sub_0_42C4E4_o
_rodata:007891CC 30 00 40 10                             beqz    $v0, loc_0_789290
_rodata:007891D0 8D 72 02 24                             li      $v0, 0x728D
_rodata:007891D4 ED 12 02 24                             li      $v0, 0x12ED
_rodata:007891D8 8E 00 82 10                             beq     $a0, $v0, locret_0_789414
_rodata:007891DC 00 00 00 00                             nop
_rodata:007891E0 EE 12 82 2C                             sltiu   $v0, $a0, 0x12EE
_rodata:007891E4 6E 00 40 14                             bnez    $v0, loc_0_7893A0
_rodata:007891E8 FD 02 02 24                             li      $v0, 0x2FD
_rodata:007891EC CF 30 02 24                             li      $v0, 0x30CF
_rodata:007891F0 D2 00 82 10                             beq     $a0, $v0, locret_0_78953C
_rodata:007891F4 00 00 00 00                             nop
_rodata:007891F8 D0 30 82 2C                             sltiu   $v0, $a0, 0x30D0
_rodata:007891FC BA 00 40 10                             beqz    $v0, loc_0_7894E8
_rodata:00789200 C7 38 02 24                             li      $v0, 0x38C7
_rodata:00789204 E5 1A 02 24                             li      $v0, 0x1AE5
_rodata:00789208 E0 00 82 10                             beq     $a0, $v0, locret_0_78958C
_rodata:0078920C 00 00 00 00                             nop
_rodata:00789210 D7 28 02 24                             li      $v0, 0x28D7
_rodata:00789214 79 00 82 10                             beq     $a0, $v0, locret_0_7893FC
_rodata:00789218 00 00 00 00                             nop
_rodata:0078921C
_rodata:0078921C                         locret_0_78921C:                         # CODE XREF: _rodata:00789278_j
_rodata:0078921C                                                                  # _rodata:007892CC_j ...
_rodata:0078921C 08 00 E0 03                             jr      $ra
_rodata:00789220 21 10 00 00                             move    $v0, $0
_rodata:00789224                          # ---------------------------------------------------------------------------
..........................
..........................
..........................
_rodata:00789BD4
_rodata:00789BD4                         locret_0_789BD4:                         # CODE XREF: _rodata:00789B6C_j
_rodata:00789BD4 08 00 E0 03                             jr      $ra
_rodata:00789BD8 25 00 02 24                             li      $v0, 0x25
_rodata:00789BDC                          # ---------------------------------------------------------------------------
_rodata:00789BDC
_rodata:00789BDC                         locret_0_789BDC:                         # CODE XREF: _rodata:00789B74_j
_rodata:00789BDC 08 00 E0 03                             jr      $ra
_rodata:00789BE0 24 00 02 24                             li      $v0, 0x24
_rodata:00789BE4                          # ---------------------------------------------------------------------------
_rodata:00789BE4
_rodata:00789BE4                         locret_0_789BE4:                         # CODE XREF: _rodata:00789B7C_j
_rodata:00789BE4 08 00 E0 03                             jr      $ra
_rodata:00789BE8 43 00 02 24                             li      $v0, 0x43
_rodata:00789BEC                          # ---------------------------------------------------------------------------
_rodata:00789BEC
_rodata:00789BEC                         locret_0_789BEC:                         # CODE XREF: _rodata:00789B84_j
_rodata:00789BEC 08 00 E0 03                             jr      $ra
_rodata:00789BF0 40 00 02 24                             li      $v0, 0x40

Agora estão faltando as rotinas de inicialização do painel frontal. Para essas, é importante explicar como usar e instalar o mips-analyser que eu citei no meu terceiro post. Vou fazer isso com mais calma depois.

[rictad]

Sobre a nova versão 1.14.4 com PVR e agendamento

Exatamente como eu vi em alguns relatos espalhados pela rede, essa versão tem um bug que liga o closed caption (CC) quando você conecta alguma coisa na porta USB. Esse seria apenas um pequeno bug inconveniente se não houvesse outro mais perigoso atrelado, que eu verifiquei. Quando o CC está ligado, o progresso de atualização de firmware some da tela em menos de 1 segundo (só reaparece se alguma legenda de CC é apresentada, alternando junto com ela). Então, se o usuário instalar a versão 1.14.4 e for fazer uma nova atualização no futuro, quando ele conectar o pendrive, o CC será ativado. Quando a atualização começar (e se não tiver passando nada na TV com closed caption), a tela de atualização irá sumir, mas a atualização continuará sendo feita! O usuário, sem saber o que está acontecendo, pode acabar desligando o STB antes da atualização acabar e matar o aparelho. Por isso, apesar de já ter feito as primeiras alterações para esta nova versão, só vou publicá-la se conseguir resolver este bug.

Mini modo de desenvolvimento

Além de adaptar essa nova versão para o ZBT-620A "tijolão", eu criei um mini modo de desenvolvimento de firmware por USB. Entre os principais recursos desse modo está a capacidade de se testar um binário zmw_base_zinwell gravado em uma pasta específica no pendrive, sem precisar gravar nada na flash antes e, portanto, com total segurança. O script bash que criei detecta o binário e o executa para testar.

Outras funções automáticas, que dependerão de uma determinada estrutura de pastas pré-criada no pendrive, são:

• Copiar o conteúdo do bloco code montado no Linux para o pendrive, para poder ser modificado;
• Criar uma imagem squashfs compatível com o aparelho, a partir dos arquivos contidos em uma determinada pasta;
• Montar uma imagem squashfs de um bloco code modificado e testar o binário zmw_base_zinwell de dentro do bloco para saber se o mesmo foi criado de forma compatível;
• Extrair o conteúdo de uma imagem squashfs compatível que esteja no pendrive;
• Registrar todas as operações em uma arquivo de log.

Para fazer isso eu criei um novo sistema de arquivos raiz com uma nova compilação cruzada para mipsel (cross-compile) usando o buildroot. Com isso, incluí também a capacidade do STB formatar em FAT32 (pois compilei o pacote dosfstools). Mas não tentei alterar o padrão de formatação, que continua em ext3. Não sei se é possível, mas acho que é.

Tentativa de por suporte a NTFS

Porém, a ideia mesmo é tentar colocar NTFS no futuro. Ele já formata em NTFS (pacote ntfsprogs compilado). O problema é montar e utilizar um disco NTFS, pois precisaria compilar o ntfs-3g e o fuse, e isso é mais difícil. Além do ntfs-3g ser grandinho, o que dificulta pelo tamanho da flash, o fuse depende do Kernel e não consegui recompilar o Kernel, nem com o buildroot. Isso porque essa máquina tem algumas características de hardware específicas que parecem não estarem disponíveis para configuração no código fonte do Kernel, dependendo de patchs. O código fonte específico para o STB eu até consegui, mas é um Kernel muito antigo (2.6.12-4.0-brcmstb), que não tem suporte ao fuse. É possível injetar o fuse nesse Kernel, mas fazer o cross-compile assim é mais difícil. Também fazer uma compilação de um módulo fuse externo seria interessante. Até consegui compilar o fuse (os binários), mas o módulo por cross-compile não sai. Então, ainda estou tentando. E acho que é possível. STB Zinwell com suporte a NTFS.

[rictad]

Rafael,

Eu gostaria de começar a procurar as rotinas do sintonizador também, pois é algo que me interessa. Você chegou a repassar isso aqui para mim:

Eu reparei que existem referências a vários tuners, tanto no Zinwell quanto no Semp.

Isso pode nos ajudar. Como você verificou essas referências?

[rafael_netto]

Vamos lá.

O único recurso que eu tenho é tentar correlacionar as mensagens que saem no terminal com o que aparece no código do software.
(aliás, no IDA 5.5 o disassembly já vem identificado, dispensando o mips-analyser que eu nem descobri como instalar)

Durante o boot, o Semp apresenta estas mensagens relacionadas ao tuner:

Código: [Selecionar]

task_create out tuner 6151
^@task_create out uartrx 7176
flash size = 8192KB
HDCPKey MagicWord = 00
Demod. I2C Device 0x30 and tuner 0xC2 via 0xFE detected, install TC90512 driver, DemodHandle = 0
tc90512 Initialising
config graphics 0
zw_tuner_halInit -> 0x11

E quando muda de canal (seja assistindo, ou nas telas de sintonia) as mensagens são assim:

Código: [Selecionar]

tc90512-> Tune to channel, frequency=563143 KHz
Writing RF = 563143
Set Frequency : Write tuner sequence = 0x10 0x9a 0xc1 0xa4 0x80
[TUNER]zw_frontend_VA6009Read=0x54 , fStatus=0
Tuner(0x11) PLL locked

Eu entendi que existem duas configurações de hardware ligadas ao sintonizador, que eu chamei de "driver" (o que aparece nas mensagens "Initialising" e "Tune to channel") e o que eu chamei de "frontend" (que aparece nas mensagens "[TUNER]zw_frontend...")

Acontece que procurando no código por estes termos, encontrei outras mensagens semelhantes, se referindo a outros tuners:

Código: [Selecionar]

.rodata:0066C058 aTunerZw_fronte:.ascii "[TUNER]zw_frontend_VA6009Read=0x%x , fStatus=%d\n"<0>

.rodata:0066EBF8 aTunerZw_fron_5:.ascii "[TUNER]zw_frontend_ED6084Read=0x%x , fStatus=%d\n"<0>

.rodata:0066B1D8 aTc90512TuneToC:.ascii "tc90512-> Tune to channel, frequency=%d KHz \n"<0>

.rodata:0066AE30 aCk451TuneToCha:.ascii "ck451-> Tune to channel, frequency=%d KHz \n"<0>

Assim, o software do Semp contém o seguinte:

"Driver"
TC90512
TC90507
CK451

"Frontend"
VA6009
ED6084
TD1311
EF2092
EF2093
TD1616
MAX3580

O Semp DC2008H usa o "driver" TC90512 e o "frontend" VA6009. Mas todos os outros também são mencionados no código executável, não apenas na área de dados.

UPDATE: Olhando com um pouco mais de cuidado verifiquei que no código do Semp existem referências a mais dispositivos ainda, mas as mensagens são ligeiramente diferentes, ex:
"Found CX24116 at i2c bus %d address 0x%x\n
"Found LNBP21 at bus %d address %x\n"
"LGS8913_tuneToSignal -> frequency = %d KHz\n"

Enquanto isso, quando eu tentei rodar o firmware do Zinwell/Rictad observei isto:

Código: [Selecionar]

task_create out tuner 6151
zw_uart7401_init channel A, baud = 9600
zw_uart7401_init channel B, baud = 115200
zw_uart7401_init done
boot time till here (io init done) 504
boot time till here (av hal init done) 641
>> zw_frontend_init -->
zw_tc90517_register
        Read TC90517 register C5h:  0
TC90517 not found!
zw_tc90507_register
TC90507 not found!
Error: No tuner installed ...

Ao que parece ele procura pelos "drivers" TC90517 e TC90507 e, não encontrando, desiste.

Buscando no código encontrei mensagens semelhantes às do Semp, apenas para estes dois "drivers":

Código: [Selecionar]

0675DC0 aTc90507TuneToC:.ascii "tc90507-> Tune to channel, frequency=%d KHz \n"<0>

.rodata:00675BD4 aZw_tc90517_tun:.ascii "zw_tc90517_tuneToChannel ( %d )\n"<0>

Quanto ao "frontend" procurei pelas mensagens semelhantes e encontrei apenas o TD1311:

Código: [Selecionar]

.rodata:00676880 aTunerZw_fronte:.ascii "[TUNER]zw_frontend_TD1311Read=0x%x , fStatus=%d\n"<0>

Portanto os dois softwares são a princípio incompatíveis, pois o Zinwell não possui a combinação "driver" + "frontend" necessária para o Semp e vice-versa. No entanto o Semp aparentemente possui apenas o "driver" equivalente ao Zinwell (TC90507), talvez seja um bom ponto de partida.

[rafael_netto]

Pesquisando um pouco mais verifiquei que TC90507, TC90517 e TC90512 são demoduladores OFDM da Toshiba. Dos três, o TC90512 (o do Semp) trabalha também com satélite (ISDB-S), os outros apenas com ISDB-T.

Quanto aos "frontend"

TD1311 e TD1616: (aparentemente) tuners DVB-T da Philips
MAX3580: tuner DVB-T da Maxim
os demais eu não encontrei.

Portanto o que eu chamei de "driver" é o demodulador, e o que chamei de "frontend" é o tuner em si.

[rictad]

O único recurso que eu tenho é tentar correlacionar as mensagens que saem no terminal com o que aparece no código do software.
(aliás, no IDA 5.5 o disassembly já vem identificado, dispensando o mips-analyser que eu nem descobri como instalar)

Muito bom saber disso! Vou adquirir uma atualização para testar. A minha versão é a 5.2

Durante o boot, o Semp apresenta estas mensagens relacionadas ao tuner:

Código: [Selecionar]

task_create out tuner 6151
^@task_create out uartrx 7176
flash size = 8192KB
HDCPKey MagicWord = 00
Demod. I2C Device 0x30 and tuner 0xC2 via 0xFE detected, install TC90512 driver, DemodHandle = 0
tc90512 Initialising
config graphics 0
zw_tuner_halInit -> 0x11

E quando muda de canal (seja assistindo, ou nas telas de sintonia) as mensagens são assim:

Código: [Selecionar]

tc90512-> Tune to channel, frequency=563143 KHz
Writing RF = 563143
Set Frequency : Write tuner sequence = 0x10 0x9a 0xc1 0xa4 0x80
[TUNER]zw_frontend_VA6009Read=0x54 , fStatus=0
Tuner(0x11) PLL locked


Essa é a mesma técnica que usei para achar as rotinas do FP (painel frontal). As strings indicando a inicialização do painel frontal durante o boot são "OnBoard fp init done" no ZBT-633 e "8051 fp init done" no ZBT-620A.

Vamos sem mips-analyser, já que parece não ser mais necessário. No início do código, é possível encontrarmos a rotina que chama as sub-rotinas que inicializam o hardware enquanto exibe as respectivas mensagens de boot. Eu lembro de começar a procurar as strings do tuner, mas acabei parando. Você fez uma pesquisa muito interessante sobre os sintonizadores usados nesses aparelhos todos. Se eu conseguir mostrar como achei as rotinas que inicializam o FP (não sei se são drivers, mas inicializam ), isso pode ajudar a descobrirmos se de fato suporte a outros tuners não estão disponíveis no código. Apesar das strings não estarem presentes, não significa que as rotinas não estejam. Veja só:

No código do ZBT-620, versão 1.7.2, temos:

Código: [Selecionar]

...........
...........
...........
.text:00400640 09 F8 20 03                             jalr    $t9 # executa 'ci init'
.text:00400644 00 00 00 00                             nop
.text:00400648 18 00 BC 8F                             lw      $gp, 0x30+var_18($sp)
.text:0040064C 50 02 05 26                             addiu   $a1, $s0, 0x250
.text:00400650 88 00 06 24                             li      $a2, 0x88
.text:00400654 24 80 84 8F                             lw      $a0, offset aCiInitDone  # "ci init done" -- carrega string em $a0
.text:00400658 2C D9 99 8F                             lw      $t9, offset sub_40398C # rotina que exibe a string
.text:0040065C 09 F8 20 03                             jalr    $t9
.text:00400660 44 03 84 24                             addiu   $a0, 0x344       # "ci init done"
.text:00400664 18 00 BC 8F                             lw      $gp, 0x30+var_18($sp)
.text:00400668 CC AE 99 8F                             lw      $t9, offset sub_451A00  # pre-executa 8051 fp init
.text:0040066C 09 F8 20 03                             jalr    $t9 # chama pre-executa 8051 fp init
.text:00400670 00 00 00 00                             nop
.text:00400674 18 00 BC 8F                             lw      $gp, 0x30+var_18($sp)
.text:00400678 50 02 05 26                             addiu   $a1, $s0, 0x250
.text:0040067C 90 00 06 24                             li      $a2, 0x90
.text:00400680 24 80 84 8F                             lw      $a0, offset a8051FpInitDone  # "8051 fp init done" -- carrega string em $a0
.text:00400684 2C D9 99 8F                             lw      $t9, offset sub_40398C # rotina que exibe a string
.text:00400688 09 F8 20 03                             jalr    $t9
.text:0040068C 54 03 84 24                             addiu   $a0, 0x354       # "8051 fp init done"
.text:00400690 18 00 BC 8F                             lw      $gp, 0x30+var_18($sp)
.text:00400694 04 C3 99 8F                             lw      $t9, offset sub_43E868
.text:00400698 09 F8 20 03                             jalr    $t9
.text:0040069C 00 00 00 00                             nop
.text:004006A0 18 00 BC 8F                             lw      $gp, 0x30+var_18($sp)
.text:004006A4 7C D3 99 8F                             lw      $t9, offset sub_6486F4 # executa ffs init
.text:004006A8 09 F8 20 03                             jalr    $t9
.text:004006AC 00 00 00 00                             nop
.text:004006B0 18 00 BC 8F                             lw      $gp, 0x30+var_18($sp)
.text:004006B4 50 02 05 26                             addiu   $a1, $s0, 0x250
.text:004006B8 9A 00 06 24                             li      $a2, 0x9A
.text:004006BC 24 80 84 8F                             lw      $a0, offset aFfsInitDone  # "ffs init done" -- carrega string em $a0
.text:004006C0 2C D9 99 8F                             lw      $t9, offset sub_40398C # rotina que exibe a string
...........
...........
...........

A rotina que exibe a string é a que é chamada várias vezes. E as chamadas imediatamente anteriores à exibição da string são sempre para as rotinas que inicializam o dispositivo "anunciado".

Eu chamei de "pre-executa 8051" por que no caso do ZBT-620A, essa rotina ainda chamará outra, que de fato inicializa o FP. A "executa 8051 fp init".

Rotina pre-executa 8051:

Código: [Selecionar]

.text:00451A00                          # pre-executa 8051 fp init
.text:00451A00
.text:00451A00                         sub_451A00:                              # DATA XREF: sub_40038C+2DC_t
.text:00451A00                                                                  # .got:00BC74BC_o
.text:00451A00
.text:00451A00                         var_18          = -0x18
.text:00451A00                         var_10          = -0x10
.text:00451A00                         var_C           = -0xC
.text:00451A00                         var_8           = -8
.text:00451A00                         var_4           = -4
.text:00451A00
.text:00451A00 78 00 1C 3C F0 AB 9C 27                 la      $gp, aScqw       # mips_analyser
.text:00451A08 21 E0 99 03                             addu    $gp, $t9
.text:00451A0C D8 FF BD 27                             addiu   $sp, -0x28
.text:00451A10 24 00 BF AF                             sw      $ra, 0x28+var_4($sp)
.text:00451A14 20 00 B2 AF                             sw      $s2, 0x28+var_8($sp)
.text:00451A18 1C 00 B1 AF                             sw      $s1, 0x28+var_C($sp)
.text:00451A1C 18 00 B0 AF                             sw      $s0, 0x28+var_10($sp)
.text:00451A20 10 00 BC AF                             sw      $gp, 0x28+var_18($sp)
.text:00451A24 10 94 99 8F                             lw      $t9, offset sub_4D51F8  # executa 8051 fp init
.text:00451A28 54 80 92 8F                             lw      $s2, 0xc423a4
.text:00451A2C 09 F8 20 03                             jalr    $t9
.text:00451A30 21 88 00 00                             move    $s1, $0
.text:00451A34 10 00 BC 8F                             lw      $gp, 0x28+var_18($sp)
.text:00451A38 44 80 82 8F                             lw      $v0, offset 0xb792a0
.text:00451A3C A0 92 50 24                             addiu   $s0, $v0, 0x92A0
.text:00451A40
.text:00451A40                         loc_451A40:                              # CODE XREF: sub_451A00+60_j
.text:00451A40 00 00 19 8E                             lw      $t9, 0($s0)
.text:00451A44 09 F8 20 03                             jalr    $t9
.text:00451A48 48 00 10 26                             addiu   $s0, 0x48
.text:00451A4C 0B 00 40 14                             bnez    $v0, loc_451A7C
.text:00451A50 10 00 BC 8F                             lw      $gp, 0x28+var_18($sp)
.text:00451A54 A4 23 42 8E                             lw      $v0, 0x23A4($s2)
.text:00451A58 01 00 31 26                             addiu   $s1, 1
.text:00451A5C 2B 10 51 00                             sltu    $v0, $s1
.text:00451A60 F7 FF 40 10                             beqz    $v0, loc_451A40
.text:00451A64 24 00 BF 8F                             lw      $ra, 0x28+var_4($sp)
.text:00451A68 20 00 B2 8F                             lw      $s2, 0x28+var_8($sp)
.text:00451A6C 1C 00 B1 8F                             lw      $s1, 0x28+var_C($sp)
.text:00451A70 18 00 B0 8F                             lw      $s0, 0x28+var_10($sp)
.text:00451A74 08 00 E0 03                             jr      $ra
.text:00451A78 28 00 BD 27                             addiu   $sp, 0x28
.text:00451A7C                          # ---------------------------------------------------------------------------
.text:00451A7C
.text:00451A7C                         loc_451A7C:                              # CODE XREF: sub_451A00+4C_j
.text:00451A7C 54 80 82 8F                             lw      $v0, 0xc423a0
.text:00451A80 24 00 BF 8F                             lw      $ra, 0x28+var_4($sp)
.text:00451A84 20 00 B2 8F                             lw      $s2, 0x28+var_8($sp)
.text:00451A88 A0 23 51 AC                             sw      $s1, 0x23A0($v0)
.text:00451A8C 18 00 B0 8F                             lw      $s0, 0x28+var_10($sp)
.text:00451A90 1C 00 B1 8F                             lw      $s1, 0x28+var_C($sp)
.text:00451A94 08 00 E0 03                             jr      $ra
.text:00451A98 28 00 BD 27                             addiu   $sp, 0x28
.text:00451A98                          # End of function sub_451A00

Início da rotina executa 8051:

Código: [Selecionar]

.text:004D51F8                          # executa 8051 fp init
.text:004D51F8
.text:004D51F8                         sub_4D51F8:                              # DATA XREF: sub_451A00+24_t
.text:004D51F8                                                                  # .got:00BC5A00_o
.text:004D51F8
.text:004D51F8                         var_20          = -0x20
.text:004D51F8                         var_1C          = -0x1C
.text:004D51F8                         var_18          = -0x18
.text:004D51F8                         var_10          = -0x10
.text:004D51F8                         var_C           = -0xC
.text:004D51F8                         var_8           = -8
.text:004D51F8
.text:004D51F8 6F 00 1C 3C F8 73 9C 27                 la      $gp, unk_6F73F8  # mips_analyser
.text:004D5200 21 E0 99 03                             addu    $gp, $t9
.text:004D5204 D0 FF BD 27                             addiu   $sp, -0x30
.text:004D5208 28 00 BF AF                             sw      $ra, 0x30+var_8($sp)
.text:004D520C 24 00 B1 AF                             sw      $s1, 0x30+var_C($sp)
.text:004D5210 20 00 B0 AF                             sw      $s0, 0x30+var_10($sp)
.text:004D5214 18 00 BC AF                             sw      $gp, 0x30+var_18($sp)
.text:004D5218 88 80 90 8F                             lw      $s0, 0xcdb690
.text:004D521C 2C 80 85 8F                             lw      $a1, offset a7401uarta  # "7401UARTA"
.text:004D5220 48 BC 99 8F                             lw      $t9, offset sub_4510F8
.text:004D5224 90 B6 04 26                             addiu   $a0, $s0, 0xB690
.text:004D5228 09 F8 20 03                             jalr    $t9
.text:004D522C A8 1F A5 24                             addiu   $a1, 0x1FA8      # "7401UARTA"
.text:004D5230 18 00 BC 8F                             lw      $gp, 0x30+var_18($sp)
.text:004D5234 E0 D9 99 8F                             lw      $t9, offset sub_4511A4
.text:004D5238 09 F8 20 03                             jalr    $t9
.text:004D523C 90 B6 04 26                             addiu   $a0, $s0, 0xB690
.text:004D5240 18 00 BC 8F                             lw      $gp, 0x30+var_18($sp)
.text:004D5244 21 20 00 00                             move    $a0, $0
.text:004D5248 70 A6 82 8F                             lw      $v0, 0xbca0d4
.text:004D524C 9C CD 83 8F                             lw      $v1, 0xcda550
.text:004D5250 10 8B 99 8F                             lw      $t9, offset sub_43C850
.text:004D5254 00 00 40 AC                             sw      $0, 0($v0)
.text:004D5258 68 C0 82 8F                             lw      $v0, 0xbca0d0
.text:004D525C 00 00 60 AC                             sw      $0, 0($v1)
.text:004D5260 00 00 40 AC                             sw      $0, 0($v0)
.text:004D5264 09 F8 20 03                             jalr    $t9
.text:004D5268 00 00 00 00                             nop
.text:004D526C 18 00 BC 8F                             lw      $gp, 0x30+var_18($sp)
.text:004D5270 01 00 04 24                             li      $a0, 1
.text:004D5274 88 80 83 8F                             lw      $v1, 0xcdb688
.text:004D5278 10 8B 99 8F                             lw      $t9, offset sub_43C850
.text:004D527C 09 F8 20 03                             jalr    $t9
.text:004D5280 88 B6 62 AC                             sw      $v0, -0x4978($v1)
.text:004D5284 18 00 BC 8F                             lw      $gp, 0x30+var_18($sp)
.text:004D5288 21 30 00 00                             move    $a2, $0
.text:004D528C 00 20 07 24                             li      $a3, 0x2000
.text:004D5290 88 80 83 8F                             lw      $v1, 0xcdb68c
.text:004D5294 2C 80 85 8F                             lw      $a1, offset aZw_fp  # "ZW_FP"
.text:004D5298 98 80 84 8F                             lw      $a0, offset sub_4D4CB8
.text:004D529C 2C 86 99 8F                             lw      $t9, offset sub_43C588
.text:004D52A0 8C B6 62 AC                             sw      $v0, -0x4974($v1)
.text:004D52A4 38 00 02 24                             li      $v0, 0x38
.text:004D52A8 B4 1F A5 24                             addiu   $a1, 0x1FB4      # "ZW_FP"
.text:004D52AC B8 4C 84 24                             addiu   $a0, 0x4CB8
.text:004D52B0 10 00 A2 AF                             sw      $v0, 0x30+var_20($sp)
.........
.........
.........

Podemos ver na rotina "executa 8051 fp init" referências à "ZW_FP" e "7401UARTA". Existem outras com essas referências que parecem terem sido feitas para inicializar outros FP.

Por exemplo, no início do código do ZBT-633 1.13.6, temos:

Código: [Selecionar]

.text:00400698 0C 94 99 8F                             lw      $t9, offset sub_4039EC
.text:0040069C 09 F8 20 03                             jalr    $t9
.text:004006A0 94 29 84 24                             addiu   $a0, 0x2994      # "ci init done"
.text:004006A4 18 00 BC 8F                             lw      $gp, 0x30+var_18($sp)
.text:004006A8 DC A7 99 8F                             lw      $t9, offset sub_4D6D30  # executa onboard fp init
.text:004006AC 09 F8 20 03                             jalr    $t9              # chama executa onboard fp init
.text:004006AC                                                                 
.text:004006B0 00 00 00 00                             nop
.text:004006B4 18 00 BC 8F                             lw      $gp, 0x30+var_18($sp)
.text:004006B8 A0 28 05 26                             addiu   $a1, $s0, 0x28A0
.text:004006BC 8A 00 06 24                             li      $a2, 0x8A
.text:004006C0 28 80 84 8F                             lw      $a0, offset aOnboardFpInitD  # "OnBoard fp init done"
.text:004006C4 0C 94 99 8F                             lw      $t9, offset sub_4039EC
.text:004006C8 09 F8 20 03                             jalr    $t9
.text:004006CC A4 29 84 24                             addiu   $a0, 0x29A4      # "OnBoard fp init done"
.text:004006D0 18 00 BC 8F                             lw      $gp, 0x30+var_18($sp)
.text:004006D4 0C A6 99 8F                             lw      $t9, offset sub_407270
.text:004006D8 09 F8 20 03                             jalr    $t9
.text:004006DC 00 00 00 00                             nop

Não existe "pre-executa fp" no ZBT-633. O início da rotina "executa onboard fp init" é o seguinte:

Código: [Selecionar]

.text:004D6D30                          # executa onboard fp init
.text:004D6D30
.text:004D6D30                         sub_4D6D30:                              # DATA XREF: sub_4003DC+2CC_t
.text:004D6D30                                                                  # sub_44EB40+24_t ...
.text:004D6D30
.text:004D6D30                         var_18          = -0x18
.text:004D6D30                         var_14          = -0x14
.text:004D6D30                         var_10          = -0x10
.text:004D6D30                         var_8           = -8
.text:004D6D30
.text:004D6D30 6E 00 1C 3C 80 E9 9C 27                 la      $gp, unk_6DE980  # mips_analyser
.text:004D6D38 21 E0 99 03                             addu    $gp, $t9
.text:004D6D3C D8 FF BD 27                             addiu   $sp, -0x28
.text:004D6D40 20 00 BF AF                             sw      $ra, 0x28+var_8($sp)
.text:004D6D44 18 00 BC AF                             sw      $gp, 0x28+var_10($sp)
.text:004D6D48 14 B1 99 8F                             lw      $t9, offset sub_438750
.text:004D6D4C 09 F8 20 03                             jalr    $t9
.text:004D6D50 21 20 00 00                             move    $a0, $0
.text:004D6D54 18 00 BC 8F                             lw      $gp, 0x28+var_10($sp)
.text:004D6D58 01 00 04 24                             li      $a0, 1
.text:004D6D5C A8 80 83 8F                             lw      $v1, 0xd45d08
.text:004D6D60 14 B1 99 8F                             lw      $t9, offset sub_438750
.text:004D6D64 09 F8 20 03                             jalr    $t9
.text:004D6D68 08 5D 62 AC                             sw      $v0, 0x5D08($v1)
.text:004D6D6C 18 00 BC 8F                             lw      $gp, 0x28+var_10($sp)
.text:004D6D70 21 30 00 00                             move    $a2, $0
.text:004D6D74 00 20 07 24                             li      $a3, 0x2000
.text:004D6D78 A8 80 83 8F                             lw      $v1, 0xd45d0c
.text:004D6D7C AC 80 84 8F                             lw      $a0, offset sub_4D6EE0
.text:004D6D80 30 80 85 8F                             lw      $a1, offset aZw_fp  # "ZW_FP"
.text:004D6D84 34 D8 99 8F                             lw      $t9, offset sub_4383F8
.text:004D6D88 0C 5D 62 AC                             sw      $v0, 0x5D0C($v1)
.text:004D6D8C 2E 00 02 24                             li      $v0, 0x2E
.text:004D6D90 CC 59 A5 24                             addiu   $a1, 0x59CC      # "ZW_FP"
.text:004D6D94 10 00 A2 AF                             sw      $v0, 0x28+var_18($sp)
.text:004D6D98 E0 6E 84 24                             addiu   $a0, 0x6EE0
.text:004D6D9C 09 F8 20 03                             jalr    $t9
....
....
....

Podemos observar as mesmas referências ("ZW_FP" e "UART"), mas a rotina é diferente da "executa 8051 fp init" do ZBT-620A. Mas, se sairmos buscando pelo texto "ZW_FP", vamos encontrar a mesma "executa 8051 fp init" no código do ZBT-633 em sub_4D5DB8. Para não precisar comparar as rotinas instrução por instrução, podemos fazer algumas comparações simples de olho no IDA (possuem, em seu início, a mesma quantidade de variáveis definidas pelo IDA e elas ainda são as mesmas, possuem a mesma visão gráfica no mini-fluxograma, as mesmas subdivisões etc) de forma que há indícios para serem as mesmas. Além disso, também é possível acharmos uma "pre-executa 8051 fp init" em sub_44EB40. O interessante é que essa "pre-executa 8051" chama a "executa onboard fp init", apesar de não ser nunca executada (o IDA marca em vermelho, sem criar a função, mas a qual podemos mandá-lo criar para nos facilitar).

A primeira coisa que fiz para testar foi alterar o apontamento da GOT em 0xBAFE8C do endereço da "executa onboard fp init" para a "executa 8051". Mas isso não funcionou. A "executa 8051 fp init" precisa da "pré-executa" antes.

Bom, com a alteração feita anteriormente, a "pre-executa" passou a apontar corretamente para a "executa 8051", já que ela usava a mesma referência na GOT (pois apontava estranhamente para a "executa onboard fp init"). O problema agora era alterar o apontamento na rotina de inicialização e exibição de strings no boot sem mexer novamente neste ponto da GOT. Como não havia nenhuma entrada na GOT que já apontasse para o endereço da "pré-executa", tive que criar uma nova entrada. Se olharmos a GOT, veremos que há alguns buracos com quatro 0's de tempos em tempos, onde podemos inserir novos endereços de apontamento. O mais próximo de 0xBAFE8C fica justamente duas palavras após, em 0xBAFE94. Então incluí os valores 40 EB 44 00 no lugar da palavra zerada, criando uma nova entrada que aponta para 0x44EB40 ("pre-executa 8051 fp init"). Agora, faltava alterar a referência para a nova entrada da GOT na rotina de inicialização. Tínhamos:

Código: [Selecionar]

.text:004006A4 18 00 BC 8F                        lw      $gp, 0x30+var_18($sp)
.text:004006A8 DC A7 99 8F                        lw      $t9, offset sub_4D6D30  # executa onboard fp init
.text:004006AC 09 F8 20 03                        jalr    $t9              # chama executa onboard fp init
.text:004006B0 00 00 00 00                        nop
Em 0x4006A8, $t9 é carregado com o valor que está no endereço 0xBAFE8C. Se apertamos a tecla "h", veremos que isso equivale a lw $t9, -0x5824($gp) (*). Como agora queria que se referisse à nova entrada na GOT, que fica em 0xBAFE92 (8 bytes a mais), mudei a instrução para lw $t9, -0x581C($gp), ficando assim:

Código: [Selecionar]

_text:004006A4     18 00 BC 8F            lw      $gp, 0x30+var_18($sp)
_text:004006A8     E4 A7 99 8F            lw      $t9, -0x581C($gp)
_text:004006AC     09 F8 20 03            jalr    $t9
_text:004006B0     00 00 00 00            nop

Isso garante que $t9 seja carregado com o que está na GOT, 8 bytes à frente do endereço anterior (0xBAFE92).

Assim, a rotina de inicialização agora chama a "pre-executa 8051 fp init". E esta chama "executa 8051 fp init", devido à primeira alteração na GOT, fazendo com que o FP do ZBT-620A seja iniciado pelo firmware 1.13.6. Mas a string exibida durante o boot ainda é "OnBoard fp init done".

(*)EDIT: No caso do IDA 5.5 (e possivelmente as versões seguintes), apertar "h" não é suficiente para mostrar o offset real em relação ao registrador $gp. Vai apenas alternar entre o valor decimal e hexadecimal do operando. Isso ocorre porque, por padrão, a versão 5.5 vem com a opção "simplificar instruções com $gp" habilitada, o que cria a pseudoinstrução la (e facilita muito a leitura, sem precisar do mips-analyser, como o rafael_netto havia dito).

Código: [Selecionar]

.text:004006A4  18 00 BC 8F               lw      $gp, 0x30+var_18($sp)
.text:004006A8  DC A7 99 8F               la      $t9, sub_4D6D30
.text:004006AC  09 F8 20 03               jalr    $t9 ; sub_4D6D30
.text:004006B0  00 00 00 00               nop

Para vermos a instrução real, lw $t9, -0x5824($gp), temos que ir em "Options", "General", aba "Analysis", botão "Processor specific analysis options" e desmarcar "Simplify $gp expressions" (nessa tela também é possível vermos onde se inicia a GOT).

[rictad]

Olha só, no caso do ZBT-633, a rotina que começa a inicialização do tuner é esta:

Código: [Selecionar]

.text:00400310                         sub_400310:                              # DATA XREF: sub_4003DC+D8_t
.text:00400310
.text:00400310                         var_10          = -0x10
.text:00400310                         var_8           = -8
.text:00400310                         var_4           = -4
.text:00400310
.text:00400310 7B 00 1C 3C A0 53 9C 27                 la      $gp, unk_7B53A0  # mips_analyser
.text:00400318 21 E0 99 03                             addu    $gp, $t9
.text:0040031C E0 FF BD 27                             addiu   $sp, -0x20
.text:00400320 1C 00 BF AF                             sw      $ra, 0x20+var_4($sp)
.text:00400324 18 00 B0 AF                             sw      $s0, 0x20+var_8($sp)
.text:00400328 10 00 BC AF                             sw      $gp, 0x20+var_10($sp)
.text:0040032C 28 80 90 8F                             lw      $s0, offset a__SrcMain_c  # "../src/main.c"
.text:00400330 28 80 84 8F                             lw      $a0, offset aTunerInitStart  # "tuner init start"
.text:00400334 0C 94 99 8F                             lw      $t9, offset sub_4039EC
.text:00400338 A0 28 05 26                             addiu   $a1, $s0, 0x28A0  # "../src/main.c"
.text:0040033C B0 28 84 24                             addiu   $a0, 0x28B0      # "tuner init start"
.text:00400340 09 F8 20 03                             jalr    $t9
.text:00400344 37 00 06 24                             li      $a2, 0x37
.text:00400348 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:0040034C 70 D5 99 8F                             lw      $t9, offset sub_43B240 ## Inicializa tuner?
.text:00400350 09 F8 20 03                             jalr    $t9
.text:00400354 00 00 00 00                             nop
.text:00400358 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:0040035C A0 28 05 26                             addiu   $a1, $s0, 0x28A0
.text:00400360 39 00 06 24                             li      $a2, 0x39
.text:00400364 28 80 84 8F                             lw      $a0, offset aTunerInitDone  # "tuner init done"
.text:00400368 0C 94 99 8F                             lw      $t9, offset sub_4039EC
.text:0040036C 09 F8 20 03                             jalr    $t9
.text:00400370 C4 28 84 24                             addiu   $a0, 0x28C4      # "tuner init done"
.text:00400374 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:00400378 1C 00 BF 8F                             lw      $ra, 0x20+var_4($sp)
.text:0040037C 18 00 B0 8F                             lw      $s0, 0x20+var_8($sp)
.text:00400380 58 BF 82 8F                             lw      $v0, 0xbb2eec
.text:00400384 B4 B3 99 8F                             lw      $t9, offset sub_438598
.text:00400388 20 00 BD 27                             addiu   $sp, 0x20
.text:0040038C 08 00 20 03                             jr      $t9
.text:00400390 00 00 44 8C                             lw      $a0, 0($v0)
.text:00400390                          # End of function sub_400310


Se a gente seguir aquela chamada de inicialização, vemos isso (que possui as strings que você mencionou):

Código: [Selecionar]

.text:0043B240                         sub_43B240:                              # DATA XREF: sub_400310+3C_t
.text:0043B240                                                                  # .got:00BB2C20_o
.text:0043B240
.text:0043B240                         var_30          = -0x30
.text:0043B240                         var_28          = -0x28
.text:0043B240                         var_24          = -0x24
.text:0043B240                         var_20          = -0x20
.text:0043B240                         var_1C          = -0x1C
.text:0043B240                         var_18          = -0x18
.text:0043B240                         var_14          = -0x14
.text:0043B240                         var_10          = -0x10
.text:0043B240                         var_C           = -0xC
.text:0043B240                         var_8           = -8
.text:0043B240                         var_4           = -4
.text:0043B240
.text:0043B240 78 00 1C 3C 70 A4 9C 27                 la      $gp, a7uD        # mips_analyser
.text:0043B248 21 E0 99 03                             addu    $gp, $t9
.text:0043B24C C0 FF BD 27                             addiu   $sp, -0x40
.text:0043B250 3C 00 BF AF                             sw      $ra, 0x40+var_4($sp)
.text:0043B254 38 00 BE AF                             sw      $fp, 0x40+var_8($sp)
.text:0043B258 34 00 B7 AF                             sw      $s7, 0x40+var_C($sp)
.text:0043B25C 30 00 B6 AF                             sw      $s6, 0x40+var_10($sp)
.text:0043B260 2C 00 B5 AF                             sw      $s5, 0x40+var_14($sp)
.text:0043B264 28 00 B4 AF                             sw      $s4, 0x40+var_18($sp)
.text:0043B268 24 00 B3 AF                             sw      $s3, 0x40+var_1C($sp)
.text:0043B26C 20 00 B2 AF                             sw      $s2, 0x40+var_20($sp)
.text:0043B270 1C 00 B1 AF                             sw      $s1, 0x40+var_24($sp)
.text:0043B274 18 00 B0 AF                             sw      $s0, 0x40+var_28($sp)
.text:0043B278 10 00 BC AF                             sw      $gp, 0x40+var_30($sp)
.text:0043B27C 2C 80 82 8F                             lw      $v0, 0xbc38a8
.text:0043B280 DC 9F 99 8F                             lw      $t9, offset sub_664A60
.text:0043B284 21 28 00 00                             move    $a1, $0
.text:0043B288 A8 38 50 24                             addiu   $s0, $v0, 0x38A8
.text:0043B28C 78 00 06 24                             li      $a2, 0x78
.text:0043B290 09 F8 20 03                             jalr    $t9
.text:0043B294 21 20 00 02                             move    $a0, $s0
.text:0043B298 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)
.text:0043B29C 50 80 82 8F                             lw      $v0, offset sub_43B0D0
.text:0043B2A0 2C 80 96 8F                             lw      $s6, 0xbc38a1
.text:0043B2A4 D0 B0 51 24                             addiu   $s1, $v0, 0xB0D0
.text:0043B2A8 21 C8 20 02                             move    $t9, $s1
.text:0043B2AC 09 F8 20 03                             jalr    $t9
.text:0043B2B0 0C 00 14 24                             li      $s4, 0xC
.text:0043B2B4 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)
.text:0043B2B8 28 80 84 8F                             lw      $a0, offset aZw_frontend_in  # ">> zw_frontend_init -->"
.text:0043B2BC 98 88 99 8F                             lw      $t9, offset sub_65EB40
.text:0043B2C0 09 F8 20 03                             jalr    $t9
.text:0043B2C4 B0 76 84 24                             addiu   $a0, 0x76B0      # ">> zw_frontend_init -->"
.text:0043B2C8 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)
.text:0043B2CC 28 80 84 8F                             lw      $a0, offset aZw_tc90517_reg  # "zw_tc90517_register"
.text:0043B2D0 98 88 99 8F                             lw      $t9, offset sub_65EB40
.text:0043B2D4 09 F8 20 03                             jalr    $t9
.text:0043B2D8 C8 76 84 24                             addiu   $a0, 0x76C8      # "zw_tc90517_register"
.text:0043B2DC 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)
.text:0043B2E0 21 20 00 02                             move    $a0, $s0
.text:0043B2E4 A0 94 99 8F                             lw      $t9, offset sub_42AEF0
.text:0043B2E8 09 F8 20 03                             jalr    $t9
.text:0043B2EC A1 38 C5 26                             addiu   $a1, $s6, 0x38A1
.text:0043B2F0 01 00 03 24                             li      $v1, 1
.text:0043B2F4 4D 00 43 10                             beq     $v0, $v1, loc_43B42C
.text:0043B2F8 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)
.text:0043B2FC
.text:0043B2FC                         loc_43B2FC:                              # CODE XREF: sub_43B240+218_j
.text:0043B2FC A1 38 C2 92                             lbu     $v0, 0x38A1($s6)
.text:0043B300 44 00 40 10                             beqz    $v0, loc_43B414
.text:0043B304 28 80 84 8F                             lw      $a0, offset sub_670000
.text:0043B308
.text:0043B308                         loc_43B308:                              # CODE XREF: sub_43B240+1E4_j
.text:0043B308 FF 00 42 30                             andi    $v0, 0xFF
.text:0043B30C 34 00 40 10                             beqz    $v0, loc_43B3E0
.text:0043B310 21 90 00 00                             move    $s2, $0
.text:0043B314 21 F0 00 02                             move    $fp, $s0
.text:0043B318 00 11 12 00                             sll     $v0, $s2, 4
.text:0043B31C
.text:0043B31C                         loc_43B31C:                              # CODE XREF: sub_43B240+198_j
.text:0043B31C 23 10 52 00                             subu    $v0, $s2
.text:0043B320 80 10 02 00                             sll     $v0, 2
.text:0043B324 21 10 5E 00                             addu    $v0, $fp
.text:0043B328 10 00 43 8C                             lw      $v1, 0x10($v0)
.text:0043B32C 26 00 60 10                             beqz    $v1, loc_43B3C8
.text:0043B330 00 00 00 00                             nop
.text:0043B334 24 00 80 12                             beqz    $s4, loc_43B3C8
.text:0043B338 00 00 00 00                             nop
.text:0043B33C 21 80 40 00                             move    $s0, $v0
.text:0043B340 01 00 13 24                             li      $s3, 1
.text:0043B344 28 80 95 8F                             lw      $s5, offset sub_670000
.text:0043B348 20 80 82 8F                             lw      $v0, offset 0x7f83b8
.text:0043B34C B8 83 42 24                             addiu   $v0, 0x83B8
.text:0043B350 06 00 00 10                             b       loc_43B36C
.text:0043B354 00 00 57 8C                             lw      $s7, 0($v0)
.text:0043B358                          # ---------------------------------------------------------------------------
.text:0043B358
.text:0043B358                         loc_43B358:                              # CODE XREF: sub_43B240+14C_j
.text:0043B358 FF FF 82 26                             addiu   $v0, $s4, 0xFFFF
.text:0043B35C 1A 00 33 16                             bne     $s1, $s3, loc_43B3C8
.text:0043B360 FF 00 54 30                             andi    $s4, $v0, 0xFF
.text:0043B364
.text:0043B364                         loc_43B364:                              # CODE XREF: sub_43B240+180_j
.text:0043B364 19 00 80 12                             beqz    $s4, loc_43B3CC
.text:0043B368 A1 38 C2 92                             lbu     $v0, 0x38A1($s6)
.text:0043B36C
.text:0043B36C                         loc_43B36C:                              # CODE XREF: sub_43B240+110_j
.text:0043B36C 00 00 04 92                             lbu     $a0, 0($s0)
.text:0043B370 10 00 19 8E                             lw      $t9, 0x10($s0)
.text:0043B374 09 F8 20 03                             jalr    $t9
.text:0043B378 01 00 05 92                             lbu     $a1, 1($s0)
.text:0043B37C 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)
.text:0043B380 21 88 40 00                             move    $s1, $v0
.text:0043B384 FC 76 A4 26                             addiu   $a0, $s5, 0x76FC
.text:0043B388 28 8A 99 8F                             lw      $t9, offset sub_65ECD0
.text:0043B38C F2 FF 53 14                             bne     $v0, $s3, loc_43B358
.text:0043B390 21 28 40 02                             move    $a1, $s2
.text:0043B394 09 F8 20 03                             jalr    $t9
.text:0043B398 00 00 00 00                             nop
.text:0043B39C 21 C8 E0 02                             move    $t9, $s7
.text:0043B3A0 09 F8 20 03                             jalr    $t9
.text:0043B3A4 00 00 00 00                             nop
.text:0043B3A8 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)
.text:0043B3AC 40 BE 99 8F                             lw      $t9, offset sub_438364
.text:0043B3B0 09 F8 20 03                             jalr    $t9
.text:0043B3B4 64 00 04 24                             li      $a0, 0x64
.text:0043B3B8 FF FF 82 26                             addiu   $v0, $s4, 0xFFFF
.text:0043B3BC 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)
.text:0043B3C0 E8 FF 33 12                             beq     $s1, $s3, loc_43B364
.text:0043B3C4 FF 00 54 30                             andi    $s4, $v0, 0xFF
.text:0043B3C8
.text:0043B3C8                         loc_43B3C8:                              # CODE XREF: sub_43B240+EC_j
.text:0043B3C8                                                                  # sub_43B240+F4_j ...
.text:0043B3C8 A1 38 C2 92                             lbu     $v0, 0x38A1($s6)
.text:0043B3CC
.text:0043B3CC                         loc_43B3CC:                              # CODE XREF: sub_43B240:loc_43B364_j
.text:0043B3CC 01 00 43 26                             addiu   $v1, $s2, 1
.text:0043B3D0 FF 00 72 30                             andi    $s2, $v1, 0xFF
.text:0043B3D4 2B 10 42 02                             sltu    $v0, $s2, $v0
.text:0043B3D8 D0 FF 40 14                             bnez    $v0, loc_43B31C
.text:0043B3DC 00 11 12 00                             sll     $v0, $s2, 4
.text:0043B3E0
.text:0043B3E0                         loc_43B3E0:                              # CODE XREF: sub_43B240+CC_j
.text:0043B3E0 3C 00 BF 8F                             lw      $ra, 0x40+var_4($sp)
.text:0043B3E4 38 00 BE 8F                             lw      $fp, 0x40+var_8($sp)
.text:0043B3E8 34 00 B7 8F                             lw      $s7, 0x40+var_C($sp)
.text:0043B3EC 30 00 B6 8F                             lw      $s6, 0x40+var_10($sp)
.text:0043B3F0 2C 00 B5 8F                             lw      $s5, 0x40+var_14($sp)
.text:0043B3F4 28 00 B4 8F                             lw      $s4, 0x40+var_18($sp)
.text:0043B3F8 24 00 B3 8F                             lw      $s3, 0x40+var_1C($sp)
.text:0043B3FC 20 00 B2 8F                             lw      $s2, 0x40+var_20($sp)
.text:0043B400 1C 00 B1 8F                             lw      $s1, 0x40+var_24($sp)
.text:0043B404 18 00 B0 8F                             lw      $s0, 0x40+var_28($sp)
.text:0043B408 21 10 00 00                             move    $v0, $0
.text:0043B40C 08 00 E0 03                             jr      $ra
.text:0043B410 40 00 BD 27                             addiu   $sp, 0x40
.text:0043B414                          # ---------------------------------------------------------------------------
.text:0043B414
.text:0043B414                         loc_43B414:                              # CODE XREF: sub_43B240+C0_j
.text:0043B414 98 88 99 8F                             lw      $t9, offset sub_65EB40
.text:0043B418 09 F8 20 03                             jalr    $t9
.text:0043B41C DC 76 84 24                             addiu   $a0, 0x76DC
.text:0043B420 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)
.text:0043B424 B8 FF 00 10                             b       loc_43B308
.text:0043B428 A1 38 C2 92                             lbu     $v0, 0x38A1($s6)
.text:0043B42C                          # ---------------------------------------------------------------------------
.text:0043B42C
.text:0043B42C                         loc_43B42C:                              # CODE XREF: sub_43B240+B4_j
.text:0043B42C 28 80 84 8F                             lw      $a0, offset aZw_tc90507_reg  # "zw_tc90507_register"
.text:0043B430 98 88 99 8F                             lw      $t9, offset sub_65EB40
.text:0043B434 09 F8 20 03                             jalr    $t9
.text:0043B438 18 77 84 24                             addiu   $a0, 0x7718      # "zw_tc90507_register"
.text:0043B43C 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)
.text:0043B440 21 20 00 02                             move    $a0, $s0
.text:0043B444 8C 85 99 8F                             lw      $t9, offset sub_42CC74
.text:0043B448 09 F8 20 03                             jalr    $t9
.text:0043B44C A1 38 C5 26                             addiu   $a1, $s6, 0x38A1
.text:0043B450 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)
.text:0043B454 40 00 03 24                             li      $v1, 0x40
.text:0043B458 A8 FF 00 10                             b       loc_43B2FC
.text:0043B45C 01 00 03 A2                             sb      $v1, 1($s0)
.text:0043B45C                          # End of function sub_43B240
.text:0043B45C

As strings são importantes para nos indicar que estamos no local certo. Mas é mais importante seguirmos as chamadas que devem nos levar às rotinas reais de inicialização, como por exemplo a que está em sub_42AEF0. Segue seu início:

Código: [Selecionar]

.text:0042AEF0                         sub_42AEF0:                              # DATA XREF: sub_43B240+A4_t
.text:0042AEF0                                                                  # .got:00BAEB50_o
.text:0042AEF0
.text:0042AEF0                         var_20          = -0x20
.text:0042AEF0                         var_18          = -0x18
.text:0042AEF0                         var_14          = -0x14
.text:0042AEF0                         var_10          = -0x10
.text:0042AEF0                         var_C           = -0xC
.text:0042AEF0                         var_8           = -8
.text:0042AEF0
.text:0042AEF0 79 00 1C 3C C0 A7 9C 27                 la      $gp, unk_78A7C0  # mips_analyser
.text:0042AEF8 21 E0 99 03                             addu    $gp, $t9
.text:0042AEFC D0 FF BD 27                             addiu   $sp, -0x30
.text:0042AF00 28 00 BF AF                             sw      $ra, 0x30+var_8($sp)
.text:0042AF04 24 00 B3 AF                             sw      $s3, 0x30+var_C($sp)
.text:0042AF08 20 00 B2 AF                             sw      $s2, 0x30+var_10($sp)
.text:0042AF0C 1C 00 B1 AF                             sw      $s1, 0x30+var_14($sp)
.text:0042AF10 18 00 B0 AF                             sw      $s0, 0x30+var_18($sp)
.text:0042AF14 10 00 BC AF                             sw      $gp, 0x30+var_20($sp)
.text:0042AF18 10 D6 99 8F                             lw      $t9, offset sub_42C588
.text:0042AF1C 21 90 80 00                             move    $s2, $a0
.text:0042AF20 09 F8 20 03                             jalr    $t9
.text:0042AF24 21 88 A0 00                             move    $s1, $a1
.text:0042AF28 01 00 13 24                             li      $s3, 1
.text:0042AF2C 9C 00 40 14                             bnez    $v0, loc_42B1A0
.text:0042AF30 10 00 BC 8F                             lw      $gp, 0x30+var_20($sp)
.text:0042AF34 00 00 22 92                             lbu     $v0, 0($s1)
.text:0042AF38 DC 9F 99 8F                             lw      $t9, offset sub_664A60
.text:0042AF3C 2C 80 90 8F                             lw      $s0, 0xbc2760
.text:0042AF40 00 21 02 00                             sll     $a0, $v0, 4
.text:0042AF44 23 20 82 00                             subu    $a0, $v0
.text:0042AF48 80 20 04 00                             sll     $a0, 2
.text:0042AF4C 21 20 92 00                             addu    $a0, $s2
.text:0042AF50 3C 00 06 24                             li      $a2, 0x3C
.text:0042AF54 09 F8 20 03                             jalr    $t9
.text:0042AF58 21 28 00 00                             move    $a1, $0
.text:0042AF5C 10 00 BC 8F                             lw      $gp, 0x30+var_20($sp)
.text:0042AF60 60 27 05 92                             lbu     $a1, 0x2760($s0)
.text:0042AF64 2C 80 82 8F                             lw      $v0, 0xbc276c
.text:0042AF68 FF 00 A3 30                             andi    $v1, $a1, 0xFF
.text:0042AF6C 00 19 03 00                             sll     $v1, 4
.text:0042AF70 6C 27 42 24                             addiu   $v0, 0x276C
.text:0042AF74 21 18 62 00                             addu    $v1, $v0
.text:0042AF78 00 00 65 A0                             sb      $a1, 0($v1)
.text:0042AF7C 00 00 24 92                             lbu     $a0, 0($s1)
.text:0042AF80 28 8A 99 8F                             lw      $t9, offset sub_65ECD0
.text:0042AF84 00 11 04 00                             sll     $v0, $a0, 4
.text:0042AF88 23 10 44 00                             subu    $v0, $a0
.text:0042AF8C 80 10 02 00                             sll     $v0, 2
.text:0042AF90 21 10 52 00                             addu    $v0, $s2
.text:0042AF94 00 00 45 A0                             sb      $a1, 0($v0)
.text:0042AF98 00 00 23 92                             lbu     $v1, 0($s1)
.text:0042AF9C 00 11 03 00                             sll     $v0, $v1, 4
.text:0042AFA0 23 10 43 00                             subu    $v0, $v1
.text:0042AFA4 80 10 02 00                             sll     $v0, 2
.text:0042AFA8 21 10 52 00                             addu    $v0, $s2
.text:0042AFAC 09 00 03 24                             li      $v1, 9
.text:0042AFB0 02 00 43 A0                             sb      $v1, 2($v0)
.text:0042AFB4 00 00 24 92                             lbu     $a0, 0($s1)
.text:0042AFB8 00 11 04 00                             sll     $v0, $a0, 4
.text:0042AFBC 23 10 44 00                             subu    $v0, $a0
.text:0042AFC0 80 10 02 00                             sll     $v0, 2
.text:0042AFC4 21 10 52 00                             addu    $v0, $s2
.text:0042AFC8 03 00 40 A0                             sb      $0, 3($v0)
.text:0042AFCC 00 00 23 92                             lbu     $v1, 0($s1)
.text:0042AFD0 00 11 03 00                             sll     $v0, $v1, 4
.text:0042AFD4 23 10 43 00                             subu    $v0, $v1
.text:0042AFD8 80 10 02 00                             sll     $v0, 2
.text:0042AFDC 21 10 52 00                             addu    $v0, $s2
.text:0042AFE0 04 00 53 A0                             sb      $s3, 4($v0)
.text:0042AFE4 00 00 23 92                             lbu     $v1, 0($s1)
.text:0042AFE8 00 11 03 00                             sll     $v0, $v1, 4
.text:0042AFEC 23 10 43 00                             subu    $v0, $v1
.text:0042AFF0 80 10 02 00                             sll     $v0, 2
.text:0042AFF4 21 10 52 00                             addu    $v0, $s2
.text:0042AFF8 05 00 53 A0                             sb      $s3, 5($v0)
.text:0042AFFC 00 00 23 92                             lbu     $v1, 0($s1)
.text:0042B000 60 27 05 92                             lbu     $a1, 0x2760($s0)
.text:0042B004 21 98 00 00                             move    $s3, $0
.text:0042B008 00 11 03 00                             sll     $v0, $v1, 4
.text:0042B00C 23 10 43 00                             subu    $v0, $v1
.text:0042B010 80 10 02 00                             sll     $v0, 2
.text:0042B014 21 10 52 00                             addu    $v0, $s2
.text:0042B018 DC 05 03 24                             li      $v1, 0x5DC
.text:0042B01C 0C 00 43 AC                             sw      $v1, 0xC($v0)
.text:0042B020 00 00 24 92                             lbu     $a0, 0($s1)
.text:0042B024 44 80 83 8F                             lw      $v1, offset sub_42B1D4
.text:0042B028 00 11 04 00                             sll     $v0, $a0, 4
.text:0042B02C 23 10 44 00                             subu    $v0, $a0
.text:0042B030 80 10 02 00                             sll     $v0, 2
.text:0042B034 21 10 52 00                             addu    $v0, $s2
.text:0042B038 D4 B1 63 24                             addiu   $v1, 0xB1D4
.text:0042B03C 10 00 43 AC                             sw      $v1, 0x10($v0)
.text:0042B040 00 00 24 92                             lbu     $a0, 0($s1)
.text:0042B044 44 80 83 8F                             lw      $v1, offset sub_42B220
.text:0042B048 00 11 04 00                             sll     $v0, $a0, 4
.text:0042B04C 23 10 44 00                             subu    $v0, $a0
.text:0042B050 80 10 02 00                             sll     $v0, 2
.text:0042B054 21 10 52 00                             addu    $v0, $s2
.text:0042B058 20 B2 63 24                             addiu   $v1, 0xB220
.text:0042B05C 14 00 43 AC                             sw      $v1, 0x14($v0)
.text:0042B060 00 00 24 92                             lbu     $a0, 0($s1)
.text:0042B064 44 80 83 8F                             lw      $v1, offset sub_42B6BC
.text:0042B068 00 11 04 00                             sll     $v0, $a0, 4
.text:0042B06C 23 10 44 00                             subu    $v0, $a0
.text:0042B070 80 10 02 00                             sll     $v0, 2
.text:0042B074 21 10 52 00                             addu    $v0, $s2
.text:0042B078 BC B6 63 24                             addiu   $v1, 0xB6BC
.text:0042B07C 1C 00 43 AC                             sw      $v1, 0x1C($v0)
.text:0042B080 00 00 24 92                             lbu     $a0, 0($s1)
.text:0042B084 44 80 83 8F                             lw      $v1, offset sub_42B2CC
.text:0042B088 00 11 04 00                             sll     $v0, $a0, 4
.text:0042B08C 23 10 44 00                             subu    $v0, $a0
.text:0042B090 80 10 02 00                             sll     $v0, 2
.text:0042B094 21 10 52 00                             addu    $v0, $s2
.text:0042B098 CC B2 63 24                             addiu   $v1, 0xB2CC
.text:0042B09C 20 00 43 AC                             sw      $v1, 0x20($v0)
.text:0042B0A0 00 00 24 92                             lbu     $a0, 0($s1)
.text:0042B0A4 44 80 83 8F                             lw      $v1, offset sub_42B414
.text:0042B0A8 00 11 04 00                             sll     $v0, $a0, 4
.text:0042B0AC 23 10 44 00                             subu    $v0, $a0
.text:0042B0B0 80 10 02 00                             sll     $v0, 2
.text:0042B0B4 21 10 52 00                             addu    $v0, $s2
.text:0042B0B8 14 B4 63 24                             addiu   $v1, 0xB414
.text:0042B0BC 24 00 43 AC                             sw      $v1, 0x24($v0)
.text:0042B0C0 00 00 26 92                             lbu     $a2, 0($s1)
.text:0042B0C4 44 80 83 8F                             lw      $v1, offset sub_42B49C
.text:0042B0C8 28 80 84 8F                             lw      $a0, offset aDemod_I2cDevic  # "Demod. I2C Device 0x30 and tuner 0xC2 v"...
.text:0042B0CC 00 11 06 00                             sll     $v0, $a2, 4
.text:0042B0D0 23 10 46 00                             subu    $v0, $a2
.text:0042B0D4 80 10 02 00                             sll     $v0, 2
.text:0042B0D8 21 10 52 00                             addu    $v0, $s2
.text:0042B0DC 9C B4 63 24                             addiu   $v1, 0xB49C
.text:0042B0E0 28 00 43 AC                             sw      $v1, 0x28($v0)
.text:0042B0E4 00 00 26 92                             lbu     $a2, 0($s1)
.text:0042B0E8 44 80 83 8F                             lw      $v1, offset sub_42B524
.text:0042B0EC 44 5B 84 24                             addiu   $a0, 0x5B44      # "Demod. I2C Device 0x30 and tuner 0xC2 v"...
.text:0042B0F0 00 11 06 00                             sll     $v0, $a2, 4
.text:0042B0F4 23 10 46 00                             subu    $v0, $a2
.text:0042B0F8 80 10 02 00                             sll     $v0, 2
.text:0042B0FC 21 10 52 00                             addu    $v0, $s2
.text:0042B100 24 B5 63 24                             addiu   $v1, 0xB524
.text:0042B104 2C 00 43 AC                             sw      $v1, 0x2C($v0)
.text:0042B108 00 00 26 92                             lbu     $a2, 0($s1)
..............
..............
..............

Se isso for a inicialização do tuner do ZBT-633 e no SEMP tiver uma rotina igual, então é possível fazer uma adaptação. O problema é que talvez, como você apontou, possam existir várias fases de inicialização. Aí seriam várias rotinas.

[zeurt]

Obrigado novamente rictad, pela continuação das explicações!
Eu consegui, lendo atentamente o que você escreveu, entender a parte das modificações no MIPS Assembly com o IDA (apesar das curiosas peculiaridades do MIPS Assembly, não fica tão difícil para quem tem um pouco de familiaridade com o ARM Assembly).
Já a parte "Linux" do processo foi mais difícil pra mim. Não tinha a menor idéia do que era o Buildroot, ou NTFS-3G, etc. De qualquer modo fui atrás para decobrir do que se tratava, e fiquei bastante impressionado. É incrível a quantidade de coisas que nós podemos aprender seguindo as trilhas que você deixa com tanto cuidado e detalhismo.

Tenho notado que nos últimos tempos a maioria dos aparelhos eletrônicos de áudio-vídeo possuem firmware com Linux embarcado (ex: Media Players, Blu-ray Players, STBs, TVs, etc.). Listo abaixo alguns exemplos interessantes:

1- Modificações de firmware no WDTV: http://root.unknown.sk/wdtv/wiki/doku.php?id=wdtv_firmware_hacks
Pode-se observar no link que passei, que existem 2 tipos principais de firmware alternativo para o WDTV, sendo um tradicional, e outro chamado ext3-boot, que de certa maneira lembra o Mini Modo de Desenvolvimento que você quer implantar para o Zinwell (ou seja, o boot é feito pelo pendrive, o qual deve conter o firmware a ser testado: o interessante é que nesse caso não há a limitação de tamanho da flash, podendo-se criar firmwares de tamanhos bem grandes...).

2- Modificações de firmware das TVs Samsung (SamyGo): http://sourceforge.net/apps/mediawiki/samygo/index.php?title=Main_Page
Neste caso a curiosidade é o sistema de arquivos proprietário da Samsung (RFS), que acaba causando dificuldades adicionais no processo de hacking.

3- Por último, gostaria de lembrar de uma tentativa frustrada de hacking, a dos Blu-ray players com Mediatek MT8520: http://hej456.com/forum/viewtopic.php?t=832&postdays=0&postorder=asc&start=0&sid=171c409203bd52ebdb2ee715c2dab9b0
Nem o NewAge conseguiu desvendar o algorítmo de compressão/descompressão usado (provavelmente por Hardware, diferente dos MT13x9, que tinham um algoritmo de compressão mais simples, e cujo descompressor ficava no próprio firmware).

A minha intenção em descrever os exemplos acima foi a de ressaltar que para modificações de firmwares dos mais diversos aparelhos na atualidade, é necessário um conjunto de conhecimentos que envolve Linux, Assembly (ARM, MIPS, x86, etc.) e de preferência um conhecimento aprofundado em Compressão de Dados (para os casos mais difíceis como o item 3).
Além disso, o que já foi feito nos itens 1 e 2 pode servir de inspiração para os mais variados aparelhos com Linux embarcado, apesar de que as modificações criadas para esses aparelhos (itens 1 e 2) nunca forma tão claramente explicadas como as modificações que o rictad já fez (tanto no LG DV397H como no Zinwell "Tijolão"). Pelo contrário, os hackers "gostam" de transmitir comunicados simplistas, quase em código, e dão a impressão de não querer transmitir os seus feitos de modo didático...

rictad,
Você já conseguiu alguma pista sobre a localização e funcionamento das rotinas do menu? Pergunto isso pois, caso seja possível o suporte a NTFS, talvez seja necessária a seleção do tipo de sistema de arquivos usado (ext3 ou NTFS), através do menu...

[rictad]

rictad,
Você já conseguiu alguma pista sobre a localização e funcionamento das rotinas do menu? Pergunto isso pois, caso seja possível o suporte a NTFS, talvez seja necessária a seleção do tipo de sistema de arquivos usado (ext3 ou NTFS), através do menu...

Olá zeurt! Consegui apenas algumas poucas coisas em relação à GUI. Acho que é possível redirecionar os apontamentos às strings "Sim" e "Não" (no menu que pergunta se deseja formatar) para strings "FAT32" (ou "NTFS") e "ext3", por exemplo. Daí a escolha "ext3" continuará executando o comando "mke2fs", que foi fácil de achar procurando por essa string no código. Mas ainda não procurei descobrir como é feita a execução desse comando. Descobrindo como, será possível redirecionar a outra opção à execução de um comando "mkfs.vfat" ou "mkntfs" de uma forma semelhante, eu acho.

1- Modificações de firmware no WDTV: http://root.unknown.sk/wdtv/wiki/doku.php?id=wdtv_firmware_hacks
Pode-se observar no link que passei, que existem 2 tipos principais de firmware alternativo para o WDTV, sendo um tradicional, e outro chamado ext3-boot, que de certa maneira lembra o Mini Modo de Desenvolvimento que você quer implantar para o Zinwell (ou seja, o boot é feito pelo pendrive, o qual deve conter o firmware a ser testado: o interessante é que nesse caso não há a limitação de tamanho da flash, podendo-se criar firmwares de tamanhos bem grandes...).

Isso é interessante. Tem até versão com suporte a CD/DVD externo.


Consegui retirar o bug do closed caption na versão 1.14.4. Então fiz as modificações para aceitar os 3 controles, incluí suporte ao controle do Semp DC2008H (ainda não testado). Agradecimentos ao rafael_netto pelos códigos daquele controle. Retirei a limitação do tamanho mínimo dos HDs externos (que era de 32 GB) e fiz a versão para o "tijolão". Antes de disponibilizar os firmwares, vou explicar o que foi feito.

Eu obtive a versão 1.14.2, que parece ter sido usada como testes para a função PVR com agendamento. Agradecimentos ao JC. Essa versão, assim como a 1.13.6, não possui bug algum no closed caption. Não testei tudo, então não sei como estavam as demais funções. Mas o closed caption estava funcionando normalmente. O que ocorre é que esses firmwares tem duas rotinas relacionadas ao CC. Uma é para habilitar/desabilitar o closed caption e a outra é para mostrar/ocultar a legenda do CC, mesmo ele estando habilitado. No firmware 1.14.4, a rotina que habilita a legenda é a sub_45ACD4. Para habilitar, devemos chamá-la com o valor 1 no registrado $a0. Para desabilitar, o valor deve ser 0. Já a rotina que deixa ou não ser mostrado o quadro de legendas do CC é a sub_4A2F18 e também tem como entrada o registrador $a0. Para chegar a essas rotinas, procurei pelas strings "Enable CC" e "Show CC" que são mostradas no console (com cabo serial) quando habilitamos ou desabilitamos o closed caption.

O motivo para ter duas talvez seja o desejo ou necessidade de "desabilitar" temporariamente o closed caption enquanto se faz alguma operação. Por exemplo, ao se conectar um dispositivo na entrada USB, aparece na tela o quadro de mensagens com a informação "USB Conectado!". Se o CC estiver habilitado, poderia dar problemas. O mesmo poderia acontecer ao acessar o menu. Porém, ao que parece, as próprias rotinas da interface gráfica se encarregam de resolver esse conflito, desabilitando temporariamente a visualização do CC enquanto alguma outra informação é exibida na tela. Por isso, não havia nenhuma preocupação em desabilitar o CC quando se exibia mensagens na tela nas versões 1.13.6 e 1.14.2.

Já na versão 1.14.4, estranhamente as rotinas responsáveis pela exibição do closed caption (as duas) são chamadas pela rotina que exibe a informação de dispositivo USB conectado/desconectado. E isso ocorre duas vezes, sendo a primeira para desabilitar o CC, antes da exibição da mensagem, e a segunda para habilitar, após a exibição. Há também outra rotina que as chama, duas vezes e da mesma forma. Essa rotina é bem grande e tem relação com diversas funções que exibem informações na tela, entre elas a de atualização de firmware. E, por fim, outra rotina faz três chamadas, mas sempre ligando o CC. Essa parece estar ligada à programação de canais.

Portanto, ao todo são 3 bugs de CC. Eu simplesmente retirei essas chamadas anormais às rotinas "Enable CC" e "Show CC" e tudo voltou a funcionar como deveria. Seguem os pontos:

Código: [Selecionar]

.text:0045AD20 18 97 99 8F                             la      $t9, sub_4A2C58  # Mostra 'Enable CC'
.text:0045AD24 21 20 00 00                             move    $a0, $0          # Bug CC desliga
.text:0045AD28 09 F8 20 03                             jalr    $t9 ; sub_4A2C58  # Mostra 'Enable CC' -- alterar para nop
.text:0045AD2C 02 91 10 00                             srl     $s2, $s0, 4
.text:0045AD30 18 00 BC 8F                             lw      $gp, 0x40+var_28($sp)
.text:0045AD34 21 20 00 00                             move    $a0, $0
.text:0045AD38 3C 97 99 8F                             la      $t9, sub_4A2F18  # Mostra 'Show CC'
.text:0045AD3C 09 F8 20 03                             jalr    $t9 ; sub_4A2F18  # Mostra 'Show CC' -- alterar para nop


Código: [Selecionar]

.text:0045B0B4 18 97 99 8F                             la      $t9, sub_4A2C58  # Mostra 'Enable CC'
.text:0045B0B8 02 AA 02 92                             lbu     $v0, (byte_C3AA02 - 0xC40000)($s0)
.text:0045B0BC 05 00 40 14                             bnez    $v0, loc_45B0D4
.text:0045B0C0 01 00 04 24                             li      $a0, 1  # Bug CC liga
.text:0045B0C4 1C 00 BF 8F                             lw      $ra, 0x20+var_4($sp)
.text:0045B0C8 18 00 B0 8F                             lw      $s0, 0x20+var_8($sp)
.text:0045B0CC 08 00 E0 03                             jr      $ra
.text:0045B0D0 20 00 BD 27                             addiu   $sp, 0x20
.text:0045B0D4                          # ---------------------------------------------------------------------------
.text:0045B0D4
.text:0045B0D4                         loc_45B0D4:                              # CODE XREF: sub_45B094+28_j
.text:0045B0D4 09 F8 20 03                             jalr    $t9            #  -- alterar para nop
.text:0045B0D8 00 00 00 00                             nop
.text:0045B0DC 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:0045B0E0 3C 97 99 8F                             la      $t9, sub_4A2F18  # Mostra 'Show CC'
.text:0045B0E4 09 F8 20 03                             jalr    $t9 ; sub_4A2F18  # Mostra 'Show CC' -- alterar para nop


Código: [Selecionar]

.text:004A809C 18 97 99 8F                             la      $t9, sub_4A2C58  # Mostra 'Enable CC'
.text:004A80A0 01 00 02 24                             li      $v0, 1
.text:004A80A4 8C 4C 62 A0                             sb      $v0, 0x4C8C($v1)
.text:004A80A8 09 F8 20 03                             jalr    $t9 ; sub_4A2C58  # Mostra 'Enable CC' -- alterar para nop
.text:004A80AC 21 20 00 00                             move    $a0, $0          # Bug CC desliga
.text:004A80B0 18 00 BC 8F                             lw      $gp, 0x40+var_28($sp)
.text:004A80B4 21 20 00 00                             move    $a0, $0
.text:004A80B8 3C 97 99 8F                             la      $t9, sub_4A2F18  # Mostra 'Show CC'
.text:004A80BC 80 80 92 8F                             la      $s2, unk_CB0000
.text:004A80C0 09 F8 20 03                             jalr    $t9 ; sub_4A2F18  # Mostra 'Show CC' -- alterar para nop


Código: [Selecionar]

.text:004A8670 18 97 99 8F                             la      $t9, sub_4A2C58  # Mostra 'Enable CC'
.text:004A8674 8C 4C 60 A0                             sb      $0, 0x4C8C($v1)
.text:004A8678 09 F8 20 03                             jalr    $t9 ; sub_4A2C58  # Mostra 'Enable CC' -- alterar para nop
.text:004A867C 01 00 04 24                             li      $a0, 1           # Bug CC liga
.text:004A8680 18 00 BC 8F                             lw      $gp, 0x60+var_48($sp)
.text:004A8684 3C 97 99 8F                             la      $t9, sub_4A2F18  # Mostra 'Show CC'
.text:004A8688 09 F8 20 03                             jalr    $t9 ; sub_4A2F18  # Mostra 'Show CC' -- alterar para nop
.text:004A868C 01 00 04 24                             li      $a0, 1


Código: [Selecionar]

.text:004D2CE0 18 97 99 8F                             la      $t9, sub_4A2C58  # Mostra 'Enable CC'
.text:004D2CE4 01 00 04 24                             li      $a0, 1           # Bug CC liga
.text:004D2CE8 09 F8 20 03                             jalr    $t9 ; sub_4A2C58  # Mostra 'Enable CC' -- alterar para nop
.text:004D2CEC E0 AF 40 A2                             sb      $0, -0x5020($s2)
.text:004D2CF0 10 00 BC 8F                             lw      $gp, 0x28+var_18($sp)
.text:004D2CF4 3C 97 99 8F                             la      $t9, sub_4A2F18  # Mostra 'Show CC'
.text:004D2CF8 09 F8 20 03                             jalr    $t9 ; sub_4A2F18  # Mostra 'Show CC' -- alterar para nop
.text:004D2CFC 01 00 04 24                             li      $a0, 1


Código: [Selecionar]

.text:004D2D70 01 00 04 24                             li      $a0, 1           # Bug CC liga
.text:004D2D74 18 97 99 8F                             la      $t9, sub_4A2C58  # Mostra 'Enable CC'
.text:004D2D78 09 F8 20 03                             jalr    $t9 ; sub_4A2C58  # Mostra 'Enable CC' -- alterar para nop
.text:004D2D7C E0 AF 40 A2                             sb      $0, -0x5020($s2)
.text:004D2D80 10 00 BC 8F                             lw      $gp, 0x28+var_18($sp)
.text:004D2D84 3C 97 99 8F                             la      $t9, sub_4A2F18  # Mostra 'Show CC'
.text:004D2D88 09 F8 20 03                             jalr    $t9 ; sub_4A2F18  # Mostra 'Show CC' -- alterar para nop
.text:004D2D8C 01 00 04 24                             li      $a0, 1


Código: [Selecionar]

.text:004D2E78 18 97 99 8F                             la      $t9, sub_4A2C58 # Mostra 'Enable CC'
.text:004D2E7C 01 00 04 24                             li      $a0, 1 # Bug CC liga
.text:004D2E80 09 F8 20 03                             jalr    $t9 ; sub_4A2C58  # Mostra 'Enable CC' -- alterar para nop
.text:004D2E84 E0 AF 40 A2                             sb      $0, -0x5020($s2)
.text:004D2E88 10 00 BC 8F                             lw      $gp, 0x28+var_18($sp)
.text:004D2E8C 01 00 04 24                             li      $a0, 1
.text:004D2E90 3C 97 99 8F                             la      $t9, sub_4A2F18  # Mostra 'Show CC'
.text:004D2E94 09 F8 20 03                             jalr    $t9 ; sub_4A2F18  # Mostra 'Show CC' -- alterar para nop
.text:004D2E98 01 00 11 24                             li      $s1, 1

Com relação ao tamanho mínimo permitido para o HD, a rotina que calcula o espaço disponível é esta:

Código: [Selecionar]

.text:004B2A98                         sub_4B2A98:                              # CODE XREF: sub_4786EC+FC_p
.text:004B2A98                                                                  # sub_4D4C48+B58_p
.text:004B2A98                                                                  # DATA XREF: ...
.text:004B2A98
.text:004B2A98                         var_18          = -0x18
.text:004B2A98                         var_10          = -0x10
.text:004B2A98                         var_C           = -0xC
.text:004B2A98                         var_8           = -8
.text:004B2A98
.text:004B2A98 71 00 1C 3C 18 D2 9C 27                 la      $gp, unk_70D218
.text:004B2AA0 21 E0 99 03                             addu    $gp, $t9
.text:004B2AA4 D8 FF BD 27                             addiu   $sp, -0x28
.text:004B2AA8 20 00 BF AF                             sw      $ra, 0x28+var_8($sp)
.text:004B2AAC 10 00 BC AF                             sw      $gp, 0x28+var_18($sp)
.text:004B2AB0 34 80 84 8F                             la      $a0, aWarningUnknown  # "Warning: unknown JFIF revision number %"...
.text:004B2AB4 70 8E 99 8F                             la      $t9, sub_4B28A4
.text:004B2AB8 18 00 A5 27                             addiu   $a1, $sp, 0x28+var_10
.text:004B2ABC 1C 00 A6 27                             addiu   $a2, $sp, 0x28+var_C
.text:004B2AC0 09 F8 20 03                             jalr    $t9 ; sub_4B28A4
.text:004B2AC4 00 D6 84 24                             addiu   $a0, (aMntUsb - 0x690000)  # "/mnt/usb"
.text:004B2AC8 10 00 BC 8F                             lw      $gp, 0x28+var_18($sp)
.text:004B2ACC 18 00 A5 8F                             lw      $a1, 0x28+var_10($sp)
.text:004B2AD0 1C 00 A6 8F                             lw      $a2, 0x28+var_C($sp)
.text:004B2AD4 34 80 84 8F                             la      $a0, aWarningUnknown  # "Warning: unknown JFIF revision number %"...
.text:004B2AD8 30 8A 99 8F                             la      $t9, sub_666260
.text:004B2ADC 82 2A 05 00                             srl     $a1, 10
.text:004B2AE0 82 32 06 00                             srl     $a2, 10
.text:004B2AE4 18 00 A5 AF                             sw      $a1, 0x28+var_10($sp)
.text:004B2AE8 1C 00 A6 AF                             sw      $a2, 0x28+var_C($sp)
.text:004B2AEC 09 F8 20 03                             jalr    $t9 ; sub_666260
.text:004B2AF0 8C 9E 84 24                             addiu   $a0, (aTotalDAvailD - 0x690000)  # "\n>>> total = %d avail = %d \n"
.text:004B2AF4 18 00 A2 8F                             lw      $v0, 0x28+var_10($sp)
.text:004B2AF8 10 00 BC 8F                             lw      $gp, 0x28+var_18($sp)
.text:004B2AFC 20 00 BF 8F                             lw      $ra, 0x28+var_8($sp)
.text:004B2B00 00 7D 42 2C                             sltiu   $v0, 0x7D00
.text:004B2B04 08 00 E0 03                             jr      $ra
.text:004B2B08 28 00 BD 27                             addiu   $sp, 0x28
.text:004B2B08                          # End of function sub_4B2A98

Vejam que no final temos 4B2B00 00 7D 42 2C  sltiu  $v0, 0x7D00. Isso é o mesmo que dividir o valor de $v0 por 0x7D00 = 32.000. Há duas chamadas para esse rotina: uma antes de começar uma gravação OTR e outra que eu acho que é antes de aceitar um agendamento de gravação. As mudanças estão explicadas nos comentários:

Código: [Selecionar]

.text:004787E4 9C 8C 99 8F                             la      $t9, sub_4B2A98  # verifica tamanho
.text:004787E8 09 F8 20 03                             jalr    $t9 ; sub_4B2A98  # verifica tamanho
.text:004787EC 00 00 00 00                             nop
.text:004787F0 12 00 40 14                             bnez    $v0, loc_47883C  # se não zero, limite de tamanho nao atingido (32G)
.text:004787F0                                                                  # mudar para nop ignora o tamanho
.text:004787F4 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)


Código: [Selecionar]

.text:004D579C 9C 8C 99 8F                             la      $t9, sub_4B2A98  # verifica tamanho
.text:004D57A0 09 F8 20 03                             jalr    $t9 ; sub_4B2A98  # verifica tamanho
.text:004D57A4 00 00 00 00                             nop
.text:004D57A8 56 00 40 14                             bnez    $v0, loc_4D5904  # se não zero, limite de tamanho nao atingido (32G)
.text:004787F0                                                                  # mudar para nop ignora o tamanho
.text:004D57AC 18 00 BC 8F                             lw      $gp, 0xE8+var_D0($sp)

Por fim, apenas para indicar onde ocorreram as mudanças que já haviam sido explicadas para a versão 1.13.6:

• a rotina "pre-executa 8051 fp init" é a sub_4526A0;
• a rotina "executa 8051 fp init" é a sub_4DD3E8;
• a chamada à "executa onboard fp init", que deve ser alterada para iniciar o painel do "tijolão", está em 0x4006AC;
• em .got:00BBA4F foi incluído o endereço da "pre-executa 8051 fp init";
• e em .got:00BBA4E8 o apontamento foi de alterado de "executa onboard fp init" para "executa 8051 fp init".

A nova rotina para interpretar as teclas dos diversos controles começa em sub_791250. Eu alterei levemente o início da rotina utilizada por mim na versão 1.13.6, apenas para incluir a checagem do código mestre do Semp, e acrescentei a rotina inteira de interpretação do controle remoto retirada do firmware daquele STB, a qual eu achei com ajuda dos códigos que o rafael_netto me passou. É interessante notar que a rotina do Semp devolve os mesmos códigos de função e no mesmo registrador ($v0), o que facilitou o seu "transplante". Porém, a sua estrutura é arquitetada de um modo diferente, o que parece indicar que o compilador usado era de outra versão ou estava com alguma opção de otimização modificada. A chamada para esta minha rotina é feita em 0x43E144, onde originalmente havia o filtro para o código mestre do controle (que eu retirei).

À tarde eu disponibilizo os firmwares, tanto para o ZBT-633 como para o ZBT-620A "tijolão". Estou chamando de 1.14.4 "beta" porque ainda precisamos testar o controle do Semp e quero incluir o mini modo de desenvolvimento, que está quase pronto. Também gostaria de arrumar algumas strings mal traduzidas que deixaram no firmware original, como "Dispositivo do formato", que deveria ser "Formatando dispostivo".

[rictad]

Firmware Rictad versão 1.14.4 beta (com agendamento da gravação)

• Corrigido o "bug do closed caption" que havia no firmware oficial;
• Retirado o limite mínimo de 32GB de espaço para que dispositivos USB pudessem ser utilizados;
• Suporte simultâneo aos controles remotos do ZBT-620A ("tijolão"), ZBT-620C/633 (slim), Samsung BN59-00604A (configurado na função STB, código 15) e Semp DC2008H;
• Disponibilizada uma versão para o ZBT-620A, que inicializa corretamente o painel frontal.

Nota 1: O limite de 32GB foi retirado, mas isso não quer dizer que é possível gravar tranquilamente em pen drives. Eu não consegui gravar mais que 1 minuto devido a problemas de sincronismo da unidade, já que a memória flash costuma ser lenta. Portanto, isso vai depender da velocidade do pen drive e deve ser usado mais para testes do que para gravações reais. Já em partições pequenas de HDs verdadeiros, a gravação ocorreu tranquilamente.

Nota 2: O suporte ao controle do Semp ainda não foi testado. Foi incluído apenas como um recurso extra. Como os aparelhos possuem sintonizadores diferentes, esse firmware não deve ser utilizado no Semp.

ATENÇÃO:

Por questão de segurança, assim como ocorre com a versão 1.13.6, só atualize para as versões 1.14.4, inclusive a oficial da Ivision, se o aparelho estiver, no mínimo, com a versão 1.5.5. Caso a versão seja inferior a essa, como a 1.3.7 ou a 1.3.8, você deve atualizar primeiro para as versões 1.5.5 ou 1.7.2 que estão disponíveis na Internet, de acordo com o modelo do seu aparelho.

A versão 1.14.4a beta deve ser preferencialmente instalada no Zinwell ZBT-620A "tijolão", de controle grande e prateado. Mas se você instalar no aparelho errado, ainda poderá atualizar com a versão c depois.
Após a atualização, você não poderá instalar as versões antigas 1.7.2 e 1.5.5 oficiais. Caso, por algum motivo, isso seja necessário, você só poderá "desatualizar" se utilizar a versão 1.7.2_back especial disponibilizada no início do tópico (EDIT: ou com a versão ZBT-620A_1.7.2_back2 disponibilizada mais à frente).

A versão 1.14.4c beta deve ser preferencialmente instalada no Zinwell ZBT-620C/633 slim, de controle Zinwell menor e preto. Mas se você instalar no aparelho errado, ainda poderá atualizar com a versão a depois. Após a atualização, você poderá voltar para as versões oficiais 1.13.6 e 1.14.4 disponibilizadas no site da Ivision. E assim como ocorre quando se atualiza com as versões oficiais, você não poderá voltar para as versões mais antigas (1.5.5, 1.7.2 etc). (EDIT:  é possível voltar com a versão ZBT-633_1.7.2_back2 disponibilizada mais à frente).

Quando você atualizar para a versão 1.14.4, serão gravados 4 blocos na flash. Então você deverá esperar a barra de gravação encher 4 vezes! Após a atualização, caso o STB já não esteja atualizado com a versão 1.14.4 oficial, o mesmo será reiniciado 2 vezes, a primeira é para apagar a EPROM.

[rafael_netto]

Como eu já disse anteriormente, eu esperava usar esses desenvolvimentos para implementar modificações no próprio firmware original do Semp, sem pensar em PVR.

Tenho duas coisas em mente:

1) Medidores de sinal. Como eu já havia dito os medidores do Semp estão bugados e têm um comportamento semelhante ao que havia nas versões mais antigas do Zinwell (não sei extamente até qual, a 1.7.2 com certeza não tem esse problema).

2) Ajuste de formato. O Semp, como o Zinwell até 1.7.2 (inclusive) não oferece ajuste de formato para resoluções HD, apenas para 480i/p. Apesar dos menus funcionarem normalmente, a maioria das configurações é ignorada. Isto foi implementado nas versões mais novas.

Para implementar essas modificações, acho que poderia ser feito o seguinte:
- identificar o código correspondente nas diferentes versões do Zinwell, antes e depois da alteração
- identificar o mesmo código no Semp, que deverá ser semelhante ao Zinwell mais antigo
- "transplantar" o código mais recente do Zinwell

O Semp 1.1.0, bem como o Zinwell 1.7.2, também possui um bug que provoca falhas esporádicas no áudio. Aparentemente isso não acontece nas versões mais antigas de ambos, nem na mais nova do Zinwell. Este problema eu imagino que seja de solução mais difícil.

E é claro a infame mensagem "Atualizando informações da transmissora" com tela preta, e no caso do Semp, mudança de canal. Parece que as versões mais novas da Zinwell, e só elas, não têm isso.

[rictad]

1) Medidores de sinal. Como eu já havia dito os medidores do Semp estão bugados e têm um comportamento semelhante ao que havia nas versões mais antigas do Zinwell (não sei extamente até qual, a 1.7.2 com certeza não tem esse problema).

Para a gente tentar comparar, quais mensagens são mostradas no terminal do Semp quando se exibe os medidores de sinal?

[rafael_netto]

Para a gente tentar comparar, quais mensagens são mostradas no terminal do Semp quando se exibe os medidores de sinal?

Aí é que está! Não mostra. Por outro lado, existe uma mensagem "%SNR %ddb" num ponto do código, pra mim isso indica que essa rotina não é usada (seria pra outro tuner).

O mais perto que a gente chega de mensagens relativas a sinal é a mudança de canal na tela de sintonia manual:

Código: [Selecionar]

tc90512-> Tune to channel, frequency=533143 KHz
Writing RF = 533143
Set Frequency : Write tuner sequence = 0xf 0xc8 0xc1 0x84 0x80
[TUNER]zw_frontend_VA6009Read=0x54 , fStatus=0
Tuner(0x11) PLL locked
***ReTuner Frequency***  533143
in scan_init
========== TMCC Information ==========
-----Mode           =   Mode3-----
-----GuardLength    =     1/8-----
-----System         =   ISDBT-----
-----TMCC Countdown =      15-----
-----Emergency Flag =     OFF-----
-----Part Flag      =      ON-----

========== TMCC[A] ==========
-----Modulation     =    QPSK-----
-----Rate           =     2/3-----
-----InterLeave     =       2-----
-----Segment Number =       1-----
========== TMCC[B] ==========
-----Modulation     =   64QAM-----
-----Rate           =     2/3-----
-----InterLeave     =       2-----
-----Segment Number =      12-----
========== TMCC[C] ==========
-----Modulation     = Invalid-----
-----Rate           = Invalid-----
-----InterLeave     = Invalid-----
-----Segment Number = Invalid-----
Demod -> Normal channel detected !

in request PAT
av play 0 0
clear no signal

Quanto à mudança de formato, ainda não verifiquei o terminal, farei isso em breve.

[rafael_netto]

O firmware do Semp parece que tem um PVR oculto!

Eu já havia visto mensagens no terminal relativas a isso. Mas pesquisando pelas strings Unicode (usadas nos menus) descobri o seguinte:

Código: [Selecionar]

.data:00938C12                 .byte 0x46  # F
.data:00938C13                 .byte    0
.data:00938C14                 .byte 0x6F  # o
.data:00938C15                 .byte    0
.data:00938C16                 .byte 0x72  # r
.data:00938C17                 .byte    0
.data:00938C18                 .byte 0x6D  # m
.data:00938C19                 .byte    0
.data:00938C1A                 .byte 0x61  # a
.data:00938C1B                 .byte    0
.data:00938C1C                 .byte 0x74  # t
.data:00938C1D                 .byte    0
.data:00938C1E                 .byte 0x20
.data:00938C1F                 .byte    0
.data:00938C20                 .byte 0x48  # H
.data:00938C21                 .byte    0
.data:00938C22                 .byte 0x44  # D
.data:00938C23                 .byte    0
.data:00938C24                 .byte 0x44  # D
.data:00938C25                 .byte    0
.data:00938C26                 .byte    0
.data:00938C27                 .byte    0
.data:00938C28                 .byte 0x48  # H
.data:00938C29                 .byte    0
.data:00938C2A                 .byte 0x44  # D
.data:00938C2B                 .byte    0
.data:00938C2C                 .byte 0x44  # D
.data:00938C2D                 .byte    0
.data:00938C2E                 .byte 0x20
.data:00938C2F                 .byte    0
.data:00938C30                 .byte 0x64  # d
.data:00938C31                 .byte    0
.data:00938C32                 .byte 0x65  # e
.data:00938C33                 .byte    0
.data:00938C34                 .byte 0x6C  # l
.data:00938C35                 .byte    0
.data:00938C36                 .byte 0x20
.data:00938C37                 .byte    0
.data:00938C38                 .byte 0x46  # F
.data:00938C39                 .byte    0
.data:00938C3A                 .byte 0x6F  # o
.data:00938C3B                 .byte    0
.data:00938C3C                 .byte 0x72  # r
.data:00938C3D                 .byte    0
.data:00938C3E                 .byte 0x6D  # m
.data:00938C3F                 .byte    0
.data:00938C40                 .byte 0x61  # a
.data:00938C41                 .byte    0
.data:00938C42                 .byte 0x74  # t
.data:00938C43                 .byte    0
.data:00938C44                 .byte 0x6F  # o
.data:00938C45                 .byte    0
.data:00938C46                 .byte    0
.data:00938C47                 .byte    0
.data:00938C48                 .byte 0x48  # H
.data:00938C49                 .byte    0
.data:00938C4A                 .byte 0x44  # D
.data:00938C4B                 .byte    0
.data:00938C4C                 .byte 0x44  # D
.data:00938C4D                 .byte    0
.data:00938C4E                 .byte 0x20
.data:00938C4F                 .byte    0
.data:00938C50                 .byte 0x64  # d
.data:00938C51                 .byte    0
.data:00938C52                 .byte 0x6F  # o
.data:00938C53                 .byte    0
.data:00938C54                 .byte 0x20
.data:00938C55                 .byte    0
.data:00938C56                 .byte 0x46  # F
.data:00938C57                 .byte    0
.data:00938C58                 .byte 0x6F  # o
.data:00938C59                 .byte    0
.data:00938C5A                 .byte 0x72  # r
.data:00938C5B                 .byte    0
.data:00938C5C                 .byte 0x6D  # m
.data:00938C5D                 .byte    0
.data:00938C5E                 .byte 0x61  # a
.data:00938C5F                 .byte    0
.data:00938C60                 .byte 0x74  # t
.data:00938C61                 .byte    0
.data:00938C62                 .byte 0x6F  # o


Código: [Selecionar]

.data:00939034                 .byte 0x52  # R
.data:00939035                 .byte    0
.data:00939036                 .byte 0x65  # e
.data:00939037                 .byte    0
.data:00939038                 .byte 0x63  # c
.data:00939039                 .byte    0
.data:0093903A                 .byte 0x6F  # o
.data:0093903B                 .byte    0
.data:0093903C                 .byte 0x72  # r
.data:0093903D                 .byte    0
.data:0093903E                 .byte 0x64  # d
.data:0093903F                 .byte    0
.data:00939040                 .byte 0x20
.data:00939041                 .byte    0
.data:00939042                 .byte 0x4C  # L
.data:00939043                 .byte    0
.data:00939044                 .byte 0x69  # i
.data:00939045                 .byte    0
.data:00939046                 .byte 0x73  # s
.data:00939047                 .byte    0
.data:00939048                 .byte 0x74  # t
.data:00939049                 .byte    0
.data:0093904A                 .byte    0
.data:0093904B                 .byte    0
.data:0093904C                 .byte 0x4C  # L
.data:0093904D                 .byte    0
.data:0093904E                 .byte 0x69  # i
.data:0093904F                 .byte    0
.data:00939050                 .byte 0x73  # s
.data:00939051                 .byte    0
.data:00939052                 .byte 0x74  # t
.data:00939053                 .byte    0
.data:00939054                 .byte 0x61  # a
.data:00939055                 .byte    0
.data:00939056                 .byte 0x20
.data:00939057                 .byte    0
.data:00939058                 .byte 0x64  # d
.data:00939059                 .byte    0
.data:0093905A                 .byte 0x65  # e
.data:0093905B                 .byte    0
.data:0093905C                 .byte 0x20
.data:0093905D                 .byte    0
.data:0093905E                 .byte 0x52  # R
.data:0093905F                 .byte    0
.data:00939060                 .byte 0x65  # e
.data:00939061                 .byte    0
.data:00939062                 .byte 0x67  # g
.data:00939063                 .byte    0
.data:00939064                 .byte 0x69  # i
.data:00939065                 .byte    0
.data:00939066                 .byte 0x73  # s
.data:00939067                 .byte    0
.data:00939068                 .byte 0x74  # t
.data:00939069                 .byte    0
.data:0093906A                 .byte 0x72  # r
.data:0093906B                 .byte    0
.data:0093906C                 .byte 0x6F  # o
.data:0093906D                 .byte    0
.data:0093906E                 .byte    0
.data:0093906F                 .byte    0
.data:00939070                 .byte 0x4C  # L
.data:00939071                 .byte    0
.data:00939072                 .byte 0x69  # i
.data:00939073                 .byte    0
.data:00939074                 .byte 0x73  # s
.data:00939075                 .byte    0
.data:00939076                 .byte 0x74  # t
.data:00939077                 .byte    0
.data:00939078                 .byte 0x61  # a
.data:00939079                 .byte    0
.data:0093907A                 .byte 0x20
.data:0093907B                 .byte    0
.data:0093907C                 .byte 0x52  # R
.data:0093907D                 .byte    0
.data:0093907E                 .byte 0x65  # e
.data:0093907F                 .byte    0
.data:00939080                 .byte 0x63  # c
.data:00939081                 .byte    0
.data:00939082                 .byte 0x6F  # o
.data:00939083                 .byte    0
.data:00939084                 .byte 0x72  # r
.data:00939085                 .byte    0
.data:00939086                 .byte 0x64  # d


"HDD Format" e "Record List" em inglês, português e espanhol, como todas as mensagens da interface. Com direito a erros de tradução...

[rictad]

Para a gente tentar comparar, quais mensagens são mostradas no terminal do Semp quando se exibe os medidores de sinal?

Aí é que está! Não mostra. Por outro lado, existe uma mensagem "%SNR %ddb" num ponto do código, pra mim isso indica que essa rotina não é usada (seria pra outro tuner).

O mais perto que a gente chega de mensagens relativas a sinal é a mudança de canal na tela de sintonia manual:

Código: [Selecionar]

tc90512-> Tune to channel, frequency=533143 KHz
Writing RF = 533143
Set Frequency : Write tuner sequence = 0xf 0xc8 0xc1 0x84 0x80
[TUNER]zw_frontend_VA6009Read=0x54 , fStatus=0
Tuner(0x11) PLL locked
***ReTuner Frequency***  533143
in scan_init
========== TMCC Information ==========
-----Mode           =   Mode3-----
-----GuardLength    =     1/8-----
-----System         =   ISDBT-----
-----TMCC Countdown =      15-----
-----Emergency Flag =     OFF-----
-----Part Flag      =      ON-----

========== TMCC[A] ==========
-----Modulation     =    QPSK-----
-----Rate           =     2/3-----
-----InterLeave     =       2-----
-----Segment Number =       1-----
========== TMCC[B] ==========
-----Modulation     =   64QAM-----
-----Rate           =     2/3-----
-----InterLeave     =       2-----
-----Segment Number =      12-----
========== TMCC[C] ==========
-----Modulation     = Invalid-----
-----Rate           = Invalid-----
-----InterLeave     = Invalid-----
-----Segment Number = Invalid-----
Demod -> Normal channel detected !

in request PAT
av play 0 0
clear no signal


Para comparar:

Código: [Selecionar]

tc90507-> Tune to channel, frequency=515143 KHz
Frank-> Set Frequency = 515143000 to mt2131
pInfo->AS_Data.f_LO1 = 1732750000
pInfo->AS_Data.f_LO2 = 1173600000
Frank-> Calculated Num1 = 2432
Frank-> Calculated Num2 = 2867
Tuner(0x40) PLL locked
========== TMCC Information ==========
-----Mode           =   Mode3-----
-----GuardLength    =    1/16-----
-----System         =   ISDBT-----
-----TMCC Countdown =      15-----
-----Emergency Flag =     OFF-----
-----Part Flag      =      ON-----

========== TMCC[A] ==========
-----Modulation     =    QPSK-----
-----Rate           =     1/2-----
-----InterLeave     =       2-----
-----Segment Number =       1-----
========== TMCC[B] ==========
-----Modulation     =   64QAM-----
-----Rate           =     3/4-----
-----InterLeave     =       2-----
-----Segment Number =      12-----
========== TMCC[C] ==========
-----Modulation     = Invalid-----
-----Rate           = Invalid-----
-----InterLeave     = Invalid-----
-----Segment Number = Invalid-----
Demod -> Normal channel detected !
clear no signal
Pat index 0, Program Num 0x3f80
 >> Nit index 0, SID 0x3f98
>> Requset PMT index 0
Manual Scan PlayStream --->
        Video PID: 0x0111 Type: 27
        Audio PID: 0x0112 Type: 17
Video PID: 0x111 Type: 0x1b
Audio PID: 0x112 Type: 0x12
av play 0 0
Video PID: 0x111 IsPidScrambled 0
Audio PID: 0x112 IsPidScrambled 0
tc90507-> Tune to channel, frequency=515143 KHz
Frank-> Set Frequency = 515143000 to mt2131
pInfo->AS_Data.f_LO1 = 1732750000
pInfo->AS_Data.f_LO2 = 1173600000
Frank-> Calculated Num1 = 2432
Frank-> Calculated Num2 = 2867
Tuner(0x40) PLL locked
========== TMCC Information ==========
-----Mode           =   Mode3-----
-----GuardLength    =    1/16-----
-----System         =   ISDBT-----
-----TMCC Countdown =      15-----
-----Emergency Flag =     OFF-----
-----Part Flag      =      ON-----

========== TMCC[A] ==========
-----Modulation     =    QPSK-----
-----Rate           =     1/2-----
-----InterLeave     =       2-----
-----Segment Number =       1-----
========== TMCC[B] ==========
-----Modulation     =   64QAM-----
-----Rate           =     3/4-----
-----InterLeave     =       2-----
-----Segment Number =      12-----
========== TMCC[C] ==========
-----Modulation     = Invalid-----
-----Rate           = Invalid-----
-----InterLeave     = Invalid-----
-----Segment Number = Invalid-----
Demod -> Normal channel detected !
clear no signal
Pat index 0, Program Num 0x3f80
 >> Nit index 0, SID 0x3f98
>> Requset PMT index 0
Manual Scan PlayStream --->
        Video PID: 0x0111 Type: 27
        Audio PID: 0x0112 Type: 17
Video PID: 0x111 Type: 0x1b
Audio PID: 0x112 Type: 0x12
av play 0 0
Video PID: 0x111 IsPidScrambled 0
Audio PID: 0x112 IsPidScrambled 0
clear no signal
Já pensou que apesar de aparecer a referência correta ao tuner (que está relacionada à mudança manual de canal), as rotinas que mostram o sinal estão "trabalhando" com referência a outro sintonizador?

Mas o que é mostrado um pouco antes, no momento em que a interface gráfica é chamada para exibir a informação? Isso pode nos dar pistas para acharmos as rotinas responsáveis da GUI e traçarmos um caminho até as rotinas que de fato "calculam" o sinal. Seguem essas informações para o ZBT-633:

Código: [Selecionar]

Frank-> Delete ErrMsg
set frame buffer alpha 0xff
Current TunerHandle = 0, TunerType = 6
get HD ws.dx = 0, ws.dy = 0, ws.dw = 1920, ws.dx = 1080
resize HD ws.dx = 1070, ws.dy = 233, ws.dw = 600, ws.dx = 249
get ws.dx = 0, ws.dy = 0, ws.dw = 720, ws.dx = 480
resize ws.dx = 402, ws.dy = 100, ws.dw = 224, ws.dx = 115
hw layer create 602 451
hwid 0

O firmware do Semp parece que tem um PVR oculto!

É, eu também vi isso nos firmwares anteriores dos ZBT. É por isso que eu acho que já tem bastante coisa pronta no zmw_base_zinwell. Inclusive os sintonizadores. Também é possível encontrar referências à interatividade pela Internet, que foi implementada no STB da Olevia. A flash do Olevia tem o mesmo tamanho da do Zinwell. Eu cheguei a rodar esse firmware com interatividade no meu ZBT-620A, mas sem o sintonizador funcionar.

[et@]

Amigo meu aparelho é um ZBT-633 slim com versão de firmware v1.14.7 é uma atualização nova que corrigiu o bug do closed caption, o que eu quero mesmo é se vc você pode indicar um link de firmware seguro que vc criou que tire o limite de 32 GB para gravação. vc você tem um link seguro de firmware criado por vc você que eu posso fazer a atualização em cima do firmaware  firmware v1.14.7 que já está instalado no meu aparelho.

se tem coloca o link aí para mim!

[rictad]

Você pode utilizar a versão 1.14.4c beta do link acima com segurança, atualizando por cima da 1.14.7. Eu já testei esse retorno. Ela é a mesma 1.14.4, mas com bug de CC corrigido e sem o limite de 32GB. Chamei de beta, pois pretendo adicionar mais alguns recursos e ainda falta verificar o funcionamento do controle do Semp. Talvez eu implemente essas mesmas modificações na versão 1.14.7.

et@, por favor, atenção às Regras da Casa.

[rictad]

Mas é como eu citei. Sem o limite de 32GB você poderá usar pen drives pequenos, mas eles não funcionam bem devido a falhas de sincronismo. São mais úteis para pequenas gravações de testes. Mas a gravação funcionará bem em partições pequenas de HDs.

[et@]

Muito obrigado! se vc você testou em cima da versão v1.14.7 e deu tudo certo, eu confio em vc você, se eu quiser voltar para o firmware do site oficial, vou poder fazr fazer isso? caso eu enconte encontre algum bug desse seu firmware?

Tem um amigo lá do hotforum htforum " kdx125"que encontrou um bug nesse teu firmware

"Testei esse firmware e achei um bug
Após gravar o canal 32.1 e mudar para o 34.1, o tuner trava e a tela fica preta, só voltando se desligar e ligar.
Isso só aconteceu nessas condições.Se gravar outro canal isso não acontece, grava normalmente.
Utilizei um pen drive de 1 GB Kingston.Depois testo com outro pen drive e um HD externo pra ver se isso acontece tambem, bem como no firmware oficial."

Isso se confirma?

vou baixar seu firmware  e espero que de dê tudo certo.

[rictad]

Isso não é bug. É exatamente o que eu falei. Em pen drives pequenos podem ocorrer problemas por causa da velocidade do dispositivo. Veja que eu deixei isso claro lá em cima, na Nota 1 do post de lançamento do firmware. Ele mesmo fez o teste depois com HD e disse que o problema é o pen drive.

Mas você poderá sim atualizar com a versão oficial 1.14.7 depois, se precisar.

[Jefferson]

Et@, você tem uma última chance de seguir as Regras da Casa ou será banido.

[et@]

MEU AMIGO VC você É FERA! DEU TUDO CERTO, GRAVEI 1 MINUTO EM UM PENDRIVE DE 8GB DA KINGSTON E DEU TUDO CERTO, GRAVEi NA BAND RJ QUE TEM BITRATE DE 10Mbs ainda vou fazer mais testes em emissoras que tem bitrate maior, mais acredito que de erro porque o pendrive não tem muita velocidade, MAIS ESTOU SATISFEITO PELO RESULTADO, PARABENS NÃO ACREDITAVA QUE BRASILEIRO TINHA TANTA COPETÊNCIA competência A NIVEL DE FAZER ESSES FEITOS, VC você É O CARA!

E TEM MAIS, EU TINHA AQUI UM CONTROLE DO 620A E FUNCIONA AGORA TBM também NO MEU 633 SLIM, VOU DIVULGAR SUAS POSTAGEM EM TODOS OS FORUNS NA NET QUE TRATA DO CONVESORES conversores ZINWELL, PORQUE VC você  É FERA,

PARABENS AMIGO, ACREDITO AGORA QUE NESSE MUNDO AINDA EXISTE PESSOAS QUE FAZEM ALGO DE BOM PARA SEUS SEMELHANTES!

[Jefferson]

É sempre bom saber que funcionou, mas ignorar seis avisos é exatamente cinco a mais do que eu geralmente tolero. Usuário banido.

[zeurt]

É, eu também vi isso nos firmwares anteriores dos ZBT. É por isso que eu acho que já tem bastante coisa pronta no zmw_base_zinwell. Inclusive os sintonizadores. Também é possível encontrar referências à interatividade pela Internet, que foi implementada no STB da Olevia. A flash do Olevia tem o mesmo tamanho da do Zinwell. Eu cheguei a rodar esse firmware com interatividade no meu ZBT-620A, mas sem o sintonizador funcionar.

Oi rictad,
Já li neste post seu, e em outros anteriores, à respeito da interatividade dos STBs Olevia. Eu não entendi muito bem aonde você estava querendo chegar, afinal a interatividade desses Olevia's não é a mesma do nosso Ginga (Ginga-J e Ginga-NCL), não é? Qual seria a utilidade de se pesquisar isso? "Viajando" bastante, seria possível, imaginar num horizante muito distante, a implementação da nossa interatividade (Ginga) nos Zinwells???
Link do Olevia ZMT-620FTA: http://www.olevia.com.hk/product_details.php?workplaceID=19&productid=119
P.S.: Estou "viajando" um pouco mais. A intenção seria investigar como a interatividade do Olevia é implementada, para se possível, "trocá-la" pela nossa interatividade (Ginga)? Me desculpem, acho que fui longe demais... 

[rafael_netto]

Já pensou que apesar de aparecer a referência correta ao tuner (que está relacionada à mudança manual de canal), as rotinas que mostram o sinal estão "trabalhando" com referência a outro sintonizador?

Pensei nisso sim. Inclusive acho que a primeira coisa a fazer, quando se descobrir alguma outra rotina equivalente, seria reapontar a GOT para ela.

JMas o que é mostrado um pouco antes, no momento em que a interface gráfica é chamada para exibir a informação? Isso pode nos dar pistas para acharmos as rotinas responsáveis da GUI e traçarmos um caminho até as rotinas que de fato "calculam" o sinal.

Como eu disse o Semp é meio "lacônico" neste aspecto.

Isto é o que acontece quando se entra na tela de sintonia manual (as primeiras linhas correspondem à tecla OK pressionada)

Código: [Selecionar]

2>key 42034ab5 24459
key 42034ab5
App task run function
zw_vs_disableAspectRatio called
set frame buffer alpha 0xff
Current TunerHandle = 0, TunerType = 6
tc90512-> Tune to channel, frequency=0 KHz
Writing RF = 0
Set Frequency : Write tuner sequence = 0x1 0x34 0xc1 0x81 0x80
[TUNER]zw_frontend_VA6009Read=0x54 , fStatus=0
Tuner(0x11) PLL locked

VideoFormat 23
VideoFormat 1080I
hw layer create 232 146
hw layer create 306 194
tc90512-> Tune to channel, frequency=563143 KHz
Writing RF = 563143
Set Frequency : Write tuner sequence = 0x10 0x9a 0xc1 0xa4 0x80
[TUNER]zw_frontend_VA6009Read=0x54 , fStatus=0
Tuner(0x11) PLL locked
***ReTuner Frequency***  563143
hw layer create 538 390
hw layer create 796 536
in scan_init
========== TMCC Information ==========
-----Mode           =   Mode3-----
-----GuardLength    =    1/16-----
-----System         =   ISDBT-----
-----TMCC Countdown =      15-----
-----Emergency Flag =     OFF-----
-----Part Flag      =      ON-----

========== TMCC[A] ==========
-----Modulation     =    QPSK-----
-----Rate           =     1/2-----
-----InterLeave     =       2-----
-----Segment Number =       1-----
========== TMCC[B] ==========
-----Modulation     =   64QAM-----
-----Rate           =     3/4-----
-----InterLeave     =       2-----
-----Segment Number =      12-----
========== TMCC[C] ==========
-----Modulation     = Invalid-----
-----Rate           = Invalid-----
-----InterLeave     = Invalid-----
-----Segment Number = Invalid-----
Demod -> Fading channel detected !

av play 0 0
in request PAT
clear no signal

Mais lacônico ainda é a entrada na barra de informações, que também apresenta um medidor de sinal. Começa com a tecla Info:

Código: [Selecionar]

INFO
2>key 420328d7 9470
key 420328d7
KEY_INFO display iplate
hw layer create 528 170
hw layer create 796 268


[rictad]

Oi rictad,
Já li neste post seu, e em outros anteriores, à respeito da interatividade dos STBs Olevia. Eu não entendi muito bem aonde você estava querendo chegar, afinal a interatividade desses Olevia's não é a mesma do nosso Ginga (Ginga-J e Ginga-NCL), não é? Qual seria a utilidade de se pesquisar isso? "Viajando" bastante, seria possível, imaginar num horizante muito distante, a implementação da nossa interatividade (Ginga) nos Zinwells???
Link do Olevia ZMT-620FTA: http://www.olevia.com.hk/product_details.php?workplaceID=19&productid=119
P.S.: Estou "viajando" um pouco mais. A intenção seria investigar como a interatividade do Olevia é implementada, para se possível, "trocá-la" pela nossa interatividade (Ginga)? Me desculpem, acho que fui longe demais... 

É o Anyplex para video-on-demand na TV. Esse Olevia ZMT 620 (um Zinwell) tem esse suporte. O firmware foi dividido em 3 partes, o que fez parecer não caber na flash do Zinwell. Mas essas partes são arquivos de firmwares que devem ser instalados em sequência, possuindo blocos em comum. Tem coisa redundante (não sei o porquê disso). Mas, ao final, tem menos de 8mb. Foi assim que fiz rodar no meu ZBT-620A. Isso mostra que é possível implementar alguma funcionalidade (não tudo) Ginga no Zinwell. Mas isso também é só um exercício teórico. 

Mais lacônico ainda é a entrada na barra de informações, que também apresenta um medidor de sinal. Começa com a tecla Info:

Código: [Selecionar]

INFO
2>key 420328d7 9470
key 420328d7
KEY_INFO display iplate
hw layer create 528 170
hw layer create 796 268


Humm, aí fica mais difícil. Talvez um caminho seja seguir o que acontece quando a rotina que verifica o código da tecla devolve o valor da função da tecla INFO. Olhando essa rotina no firmware do Semp, é possível ver que o valor devolvido quando se aperta a tecla 0x28D7 é 0x51:

Código: [Selecionar]

_text:0043DBD8 D7 28 02 24                 li      $v0, 0x28D7
_text:0043DBDC 93 FF 82 14                 bne     $a0, $v0, locret_0_43DA2C
_text:0043DBE0 51 00 03 24                 li      $v1, 0x51
_text:0043DBE4 08 00 E0 03                 jr      $ra
_text:0043DBE8 21 10 60 00                 move    $v0, $v1

Agora podemos tentar ver "quem" chama essa rotina e o que faz quando recebe o código 0x51.

[Miro]

Olá Pessoal! Fiz um teste com o firmware ZBT-620_1.14.4a.beta.zim no meu AIKO HD-1018 (é parecido com o tijolão da Zinwell, e o controle é exatamente igual a esse da foto prateado). Eu já tinha atualizado anteriormente para uma versão 1.2.X da Zinwell e sabia que era compatível, então fiz exatamente como descrito aqui. Atualizei para a versão 1.5.5 primeiro e depois atualizei novamente para essa versão 1.14.4a_beta. Tudo correu bem na atualização, mas deixo aqui uma dica. Depois de atualizar essa versão desligue e tire o conversor da tomada de força e religue após alguns segundos. Ele ligou o painel perfeitamente e a busca de canais achou até alguns outros que não achava na versão anterior. Imagem e sons ótimos (meu sinal aqui é bem forte). Minha curiosidade era se iria funcionar o PVR nesse aparelho antigo, e realmente funcionou. Liguei um HD externo USB de 500 Gb e ele reconheceu de imediado o dispositivo, e gravei uns segundos da novela da Globo apertando diretamente o botão vermelho, ficou perfeito (ótima qualidade), só não gostei do pequeno painel de controle (botões play/stop,etc) que fica aparecendo no canto esquerdo da tela quando reproduzi o arquivo gravado. No meu caso não teve nenhum problema de sincronia do áudio gravado. 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.  Parabéns ao pelo trabalho, muito eficiente. Tenho certeza que acompanhando as novas versões o firmware ficará ainda melhor do que já está. Agora consigo gravar da TV programas em HD se quiser, antes não tinha essa opção no meu conversor.

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

[rictad]

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.

Com certeza é erro.

Só uma curiosidade. Quando se inicia o painel frontal do ZBT-620A, a string apresentada é "8051 fp init". Parece que o microcontrolador é o 8051, o mesmo usado nos Mediatek DVD players (mas versão 8032).

[rafael_netto]

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.

Ah tá, não sabia disso!
Seja como for o colega já conseguiu um controle do 633 para consertar a atualização. Mas fica a dica para quem tenha tido um problema semelhante e que por acaso tenha mais facilidade de mexer direto no aparelho do que de conseguir um controle.

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

Agora entendi. Eu pensava que o "front panel" era apenas o display (que só o tijolão tem), mas tinha esquecido dos botões.

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.

Fico feliz e tranquilo em saber que o meu backup está perfeito. 

De fato o canal 4.1 (29 UHF) é o que está sintonizado, imagino que você consiga navegar pelos canais do Rio e que ao entrar na tela de sintonia manual estará selecionado o 29.

Isso é interessante, pois mostra que o firmware do Semp é o mais compatível até agora com todos os rootfs que eu testei.

É curioso mesmo, já que entre todas as atualizações do Semp (pelo menos desde a 14c, não sei quanto às mais antigas) o root é incompatível, isto é, ao iniciar ele faz o rescan.

Pelo que entendi o executável do Semp não trava com nenhum rootfs e faz o rescan em todos, enquanto que os da Zinwell têm comportamento diferente de acordo com a versão, alguns travam, alguns fazem rescan, e outros não fazem nada (por ex. entre a 1.5.5 e a 1.7.2).

Agora, tem uma situação que aconteceu comigo que parece que você não verificou: mesmo ao rodar um executável do próprio Semp no pendrive, mas com versão diferente do rootfs, ele trava, não faz o rescan. No caso eu testei rodar o 1.0.14c tendo o 1.1.0 instalado no aparelho.

E quanto ao sistema de arquivos e o kernel? Não precisam ser modificados também de acordo com a versão?

[rictad]

Fico feliz e tranquilo em saber que o meu backup está perfeito. 

De fato o canal 4.1 (29 UHF) é o que está sintonizado, imagino que você consiga navegar pelos canais do Rio e que ao entrar na tela de sintonia manual estará selecionado o 29.

Só não consigo navegar porque não tenho o controle e o FP não inicializa. 

É curioso mesmo, já que entre todas as atualizações do Semp (pelo menos desde a 14c, não sei quanto às mais antigas) o root é incompatível, isto é, ao iniciar ele faz o rescan.

Pelo que entendi o executável do Semp não trava com nenhum rootfs e faz o rescan em todos, enquanto que os da Zinwell têm comportamento diferente de acordo com a versão, alguns travam, alguns fazem rescan, e outros não fazem nada (por ex. entre a 1.5.5 e a 1.7.2).

Isso. Ficou meio confuso o que eu escrevi mas é mais ou menos isso que quis dizer.

Agora, tem uma situação que aconteceu comigo que parece que você não verificou: mesmo ao rodar um executável do próprio Semp no pendrive, mas com versão diferente do rootfs, ele trava, não faz o rescan. No caso eu testei rodar o 1.0.14c tendo o 1.1.0 instalado no aparelho.

Isso deve ocorrer por se tratar de uma versão Semp mais antiga contra uma mais nova, que deve criar uma estrutura em flash0.rootfs bem diferente.

E quanto ao sistema de arquivos e o kernel? Não precisam ser modificados também de acordo com a versão?

Dificilmente precisam. Pelo que notei, o Kernel sempre é o mesmo. No máximo, uma nova compilação, mas da mesma versão e com as mesmas configurações. Já o sistema de arquivos muda muito pouca coisa. Às vezes ficam umas sobras de cópias de scripts que foram utilizados no desenvolvimento, mas que não fazem diferença. No caso do seu backup, ambos não fizeram diferença para executar o binário da versão Zinwell 1.14.4.

[rafael_netto]

E quanto ao sistema de arquivos e o kernel? Não precisam ser modificados também de acordo com a versão?

Dificilmente precisam. Pelo que notei, o Kernel sempre é o mesmo. No máximo, uma nova compilação, mas da mesma versão e com as mesmas configurações. Já o sistema de arquivos muda muito pouca coisa. Às vezes ficam umas sobras de cópias de scripts que foram utilizados no desenvolvimento, mas que não fazem diferença. No caso do seu backup, ambos não fizeram diferença para executar o binário da versão Zinwell 1.14.4.

Parece que não é bem assim. Senão seria possível instalar o 1.7.2 por cima dos 1.13.x/1.14.x.
Eu entendo que a incompatibilidade entre eles não é questão de rootfs, senão atualizar os quatro blocos não faria o conversor voltar a funcionar (o 1.7.2_back não funcionaria).

[rictad]

Parece que não é bem assim. Senão seria possível instalar o 1.7.2 por cima dos 1.13.x/1.14.x.
Eu entendo que a incompatibilidade entre eles não é questão de rootfs, senão atualizar os quatro blocos não faria o conversor voltar a funcionar (o 1.7.2_back não funcionaria).

Tem razão. Acabamos nos esquecendo de um detalhe importante, que faz a diferença entre as versões mais antigas e as mais novas. Eu falei um pouco disso lá atrás e já havia me esquecido. É a versão do squashfs.

As versões mais antigas do Zinwell (1.5.5 e 1.7.2) usam um squashfs estranho, lembra? Já as versões mais recentes, usam o squashfs 3.1 + lzma. Portanto, o Kernel da versão mais nova, apesar de ser o mesmo (versão 2.6.12-4.2-brcmstb), foi compilado com suporte ao squashfs + lzma. Além disso, o sistema de arquivos passou a vir no novo formato, apesar de ter o mesmo conteúdo. Se voltarmos para a versão 1.7.2 apenas com o bloco code, o Kernel recompilado não conseguirá montá-lo. Se, em seguida, gravarmos o Kernel da versão 1.7.2 (com o squashfs antigo e sem lzma), o bloco code será montado, mas o bloco do sistema de arquivos (avail) é que não será montado, pois está no novo squashfs. Então precisa dos 3 blocos, por uma questão de compatibilidade ao squashfs usado. O bloco load não é necessário, pois o CFE continua fazendo o trabalho dele. Até por segurança, nem deveria ser atualizado. Já o bloco rootfs das versões novas acaba sendo aceito pela versão 1.7.2 e reformatado.

Mas no caso do teste pelo Semp, esses blocos não são necessários, pois o binário estará no pen drive e não em uma imagem squashfs. Para ele rodar, basta o bloco rootfs correto.

[rafael_netto]

Fiz o teste de substituir o flash0.rootfs e rodar o zmw_base_zinwell a partir do pendrive e obtive um resultado, digamos "estranho".

Na primeira tentativa funcionou. A interface iniciou, consegui operá-la normalmente com o controle do Semp, vi o canal 10 de Brasília e troquei o vídeo para NTSC. Porém eu não havia gravado o log e não registrei o que acontecia durante o boot, em especial para ver as mensagens de detecção de tuner. Só reparei que, durante o uso normal do programa, no terminal aparecia uma mensagem insistente relativa a USB.

Rodei o Putty novamente, desta vez com log, sem reiniciar o conversor (apenas havia interrompido a interface com Ctrl-\ e rodado novamente). Desta vez a interface não iniciou e ficou cuspindo muitas mensagens relacionadas a comunicação i2c (que é usada para o tuner), se não me engano dizendo que os comandos não tinham sido aceitos ou que as respostas não eram entendidas. Eu bobamente não guardei o log disso.

Com medo de que tivesse danificado algo no STB reiniciei normalmente e fiquei aliviado ao ver a interface padrão do Semp iniciar no modo de fábrica, como era esperado.

Então mais uma vez copiei o flash0.rootfs e tentei rodar no pendrive. Daí por diante não funcionou mais. O programa é interrompido logo no início com estas mensagens:

Código: [Selecionar]

broadcom create task 10 b_event
broadcom create task 30 b_idle
boot time till here (boot bsp start) 3133
Before zw_init_i2c_hw
Before zw_init_common_interface
BCHP_EBI_CS_BASE_0 0x1e00000c
BCHP_EBI_CS_CONFIG_0 0x02000411
BCHP_EBI_CS_BASE_1 0x1c00000c
BCHP_EBI_CS_CONFIG_1 0x07000410
BCHP_EBI_CS_BASE_2 0x00000000
BCHP_EBI_CS_CONFIG_2 0x07000000
BCHP_EBI_CS_BASE_3 0x00000000
BCHP_EBI_CS_CONFIG_3 0x07000000
boot time till here (boot bsp end) 3156
boot time till here (bsettop init) 3173
O prompt do Busybox então retorna.

Felizmente, ao reiniciar com a interface padrão do Semp tudo volta pro lugar.

Uma coisa que eu reparei (já tinha reparado antes) é que quando se interrompe a execução da interface que foi chamada a partir da linha de comando (isto é, não inicou na hora do boot) o prompt fica extremamente lento, os caracteres demoram muito a aparecer. E quando se roda o programa, sempre dá algum erro. Eu já tinha tentado isso anteriormente, ao tentar rodar o zmw_base_zinwell original depois de tê-lo interrompido.

Agora parece que o que aconteceu foi que na primeira vez, tudo funcionou, mas na segunda, algo foi corrompido que impediu as execuções posteriores.

Cheguei a pensar que algo fosse escrito no filesystem, mas lembrei que ele é protegido contra gravação. A única explicação é que algum lugar, fora do rootfs, foi corrompido, e seja o que for, não afeta o software padrão do Semp (felizmente). Poderia ser nos blocos nvram ou skip, que ainda não mexemos?

[rictad]

Na primeira tentativa funcionou. A interface iniciou, consegui operá-la normalmente com o controle do Semp, vi o canal 10 de Brasília e troquei o vídeo para NTSC. Porém eu não havia gravado o log e não registrei o que acontecia durante o boot, em especial para ver as mensagens de detecção de tuner. Só reparei que, durante o uso normal do programa, no terminal aparecia uma mensagem insistente relativa a USB.

Normal a mensagem. Isso ocorre porque você iniciou o programa pelo USB, que já está montado. Como as novas versões do Zinwell tentam montar automaticamente o pen drive, o mount falha (pois o dispositivo está ocupado), mostrando a mensagem mount 00000. Ele continua tentando e a mensagem fica sendo mostrada insistentemente.

Como você alterou o video, então o controle do Semp funcionou. 

Rodei o Putty novamente, desta vez com log, sem reiniciar o conversor (apenas havia interrompido a interface com Ctrl-\ e rodado novamente). Desta vez a interface não iniciou e ficou cuspindo muitas mensagens relacionadas a comunicação i2c (que é usada para o tuner), se não me engano dizendo que os comandos não tinham sido aceitos ou que as respostas não eram entendidas. Eu bobamente não guardei o log disso.

Com medo de que tivesse danificado algo no STB reiniciei normalmente e fiquei aliviado ao ver a interface padrão do Semp iniciar no modo de fábrica, como era esperado.

Isso é seguro. Você pode repetir várias vezes que nunca vai acontecer nada com o Semp. Mas precisa reiniciar  STB para tudo voltar ao normal.

Então mais uma vez copiei o flash0.rootfs e tentei rodar no pendrive. Daí por diante não funcionou mais. O programa é interrompido logo no início com estas mensagens:

Código: [Selecionar]

broadcom create task 10 b_event
broadcom create task 30 b_idle
boot time till here (boot bsp start) 3133
Before zw_init_i2c_hw
Before zw_init_common_interface
BCHP_EBI_CS_BASE_0 0x1e00000c
BCHP_EBI_CS_CONFIG_0 0x02000411
BCHP_EBI_CS_BASE_1 0x1c00000c
BCHP_EBI_CS_CONFIG_1 0x07000410
BCHP_EBI_CS_BASE_2 0x00000000
BCHP_EBI_CS_CONFIG_2 0x07000000
BCHP_EBI_CS_BASE_3 0x00000000
BCHP_EBI_CS_CONFIG_3 0x07000000
boot time till here (boot bsp end) 3156
boot time till here (bsettop init) 3173
O prompt do Busybox então retorna.

(...)
Cheguei a pensar que algo fosse escrito no filesystem, mas lembrei que ele é protegido contra gravação. A única explicação é que algum lugar, fora do rootfs, foi corrompido, e seja o que for, não afeta o software padrão do Semp (felizmente). Poderia ser nos blocos nvram ou skip, que ainda não mexemos?

Isso é estranho. Talvez após copiar novamente o rootfs, o binário do Semp chegou a fazer algumas alterações antes de ser interrompido com CTRL-\. Aconteceu comigo algumas vezes. É muito rápido. Não acho que pode ser outro bloco, porque fiz os mesmos testes aqui com seu firmware inteiro.

Uma coisa que eu reparei (já tinha reparado antes) é que quando se interrompe a execução da interface que foi chamada a partir da linha de comando (isto é, não inicou na hora do boot) o prompt fica extremamente lento, os caracteres demoram muito a aparecer. E quando se roda o programa, sempre dá algum erro. Eu já tinha tentado isso anteriormente, ao tentar rodar o zmw_base_zinwell original depois de tê-lo interrompido.

Não sei se vai funcionar com essa versão do Busybox (nunca testei), mas na nova versão que compilei é só usar o comando (no terminal lento):

setsid cttyhack sh

ou

setsid cttyhack ash

Se funcionar, você poderá, inclusive, chamar o zmw_base_zinwell com "&" no final

./zmw_base_zinwell &

para enviá-lo para segundo plano, mantendo o terminal disponível, rápido e com controle enquanto o programa roda.
Se não funcionar, tente digitar somente o comando "ash" para ver se ele consegue iniciar outro shell com controle.
Isso está relacionado com job control.

[rictad]

Nova versão 1.7.2_back2.

Montei uma nova versão 1.7.2 de volta para quem atualizou com os firmwares 1.13.x e 1.14.x. Continua com 4 blocos, mas é menor que a anterior, pois aquela usava o dump inteiro dos blocos que copiei da flash. Agora eu os reduzi para o seu tamanho útil. A exceção é o bloco LOAD, que deixei inteiro (não quis mexer, por questão de segurança). Além disso, fiz uma variação especial para o ZBT-633/620C slim, para aqueles que, por algum motivo, precisarem voltar a versão. Fiz vários testes e as duas funcionam perfeitamente. Essas versões não são intercambiáveis entre os aparelhos, por causa do controle remoto (elas são originais). E devem ser instaladas contra as versões 1.13.x ou 1.14.x, tanto as oficiais como as modificadas que estão aqui neste tópico. Após serem instaladas, você ainda poderá reatualizar para as versões 1.13.x ou 1.14.x.

ATENÇÃO:

A versão ZBT-620A_1.7.2_back2 só pode ser instalada no Zinwell ZBT-620A "tijolão" e só deve ser instalada se tiver algum motivo para voltar para a versão antiga oficial. Se você instalá-la no slim, vai precisar achar o controle do "tijolão" para operá-lo e atualizá-lo corretamente ou enviá-lo para a assistência técnica.

A versão ZBT-633_1.7.2_back2 só pode ser instalada no Zinwell ZBT-633/620C slim e só deve ser instalada se tiver algum motivo para voltar para a versão antiga oficial. Se você instalá-la no "tijolão", vai precisar achar o controle do slim para operá-lo e atualizá-lo corretamente ou enviá-lo para a assistência técnica.

Serão gravados 4 blocos na flash. Portanto, você deve esperar a barra de atualização encher 4 vezes. Após isso, o STB será reiniciado 2 vezes, a primeira é para ressetar as configurações.

[rictad]

Eu fiz um teste agora a pouco com o novo firmware 1.15.4 do Zinwell ZBT-601 no tijolão. Claro, tive que abrir o firmware no zimview e alterar o customer number de 6 para 262 para que o tijolão aceitasse o firmware. Com o zimview também podemos ver que, dos 4 blocos, o único diferente (checksum) é o bloco code. Como esperado, após a atualização só pude operar o aparelho com o controle do ZBT-633 (que deve ser igual ao do ZBT-601). O engraçado é que a saída vídeo componente funcionou normalmente (o ZBT-601 não tem vídeo componente). Ambas as saídas de áudio stereo (o 601 só tem uma) também funcionaram. Não pude testar as saídas SPDIF (óptica e coaxial), pois não tenho equipamento compatível, mas acho que estão funcionando, apesar de o 601 não as possuir. Meu palpite é que se alguém instalar esse firmware no ZBT-633, tudo vai funcionar normalmente, com exceção do painel frontal. Ao final, para voltar à versão 1.14.4a beta do tijolão, tive que alterar o customer number do arquivo de 262 para 6, para que o firmware temporário do 601 permitisse a atualização

Olhando o arquivo zmw_base_zinwell no IDA, é visível a diferença nas rotinas de inicialização do painel frontal (o ZBT-601 não possui display). Assim como o ZBT-620A, ele também chama a rotina que nomeei "pré-executa 8051 fp init", mas que agora vou renomear para "pre-executa fp init". Essa rotina chama a principal, que eu denominei "executa frontpanel init", já que é essa a string relacionada durante a inicialização.

A ideia é usar apenas a última versão do ZBT-601 para integrar todas as modificações feitas até agora (e talvez as futuras) e disponibilizar 3 versões intercambiáveis entre os 3 aparelhos. Mas para isso vou ter que descobrir se o SPDIF realmente continua funcionando nos ZBT-620/633 após a atualização com o firmware do 601.

[zeurt]

A ideia é usar apenas a última versão do ZBT-601 para integrar todas as modificações feitas até agora (e talvez as futuras) e disponibilizar 3 versões intercambiáveis entre os 3 aparelhos. Mas para isso vou ter que descobrir se o SPDIF realmente continua funcionando nos ZBT-620/633 após a atualização com o firmware do 601.

Legal saber dessa compatibilidade. Faz algum tempo que eu estou pra te perguntar sobre isso... Na verdade eu estou precisando comprar um conversor pra minha mãe, e então pensei no ZBT-601, que está com um preço ótimo. Só faltava a confirmação que você deu agora sobre a compatibilidade com o ZBT-633, pois assim, além de comprar um conversor com ótimo custo-benefício, ainda poderei brincar um pouco com o desenvolvimento do firmware (tentar ajudar nem que seja um pouquinho  ).

Outra coisa: eu abri recentemente um binário zmw_base_zinwell que você enviou, no IDA 5.5.0, e fiquei POSITIVAMENTE impressionado com a quantidade de "comentários" espalhados por todo o código. Esses "comentários" que na verdade são as mensagens enviadas para o console são realmente muito bem-vindos. Com eles, a gente não fica desesperadamente perdido no meio de tudo (é bem diferente dos firmwares Mediatek, em que não existia nada disso).
Como você ressaltou algumas vezes já neste tópico, os comentários servem pra nos mostrar que estamos no lugar certo... É claro que precisa decifrar as instruções da redondeza do comentário que interessa para se chegar a rotina definitiva que executa determinada função. De qualquer modo, me pareceu que ajuda bastante, já que cada comentário serve como uma pista, um ponto de partida, ou uma idéia para uma nova modificação...
Um exemplo: próximo de onde você colocou os NOPs pra acabar com o limite de 32G existe a string "# "Disk total size must be over 32G!!".

Código: [Selecionar]

.text:004787E4                          # ---------------------------------------------------------------------------
.text:004787E4
.text:004787E4                         loc_4787E4:                              # CODE XREF: sub_4786EC+40j
.text:004787E4 9C 8C 99 8F                             la      $t9, sub_4B2A98
.text:004787E8 09 F8 20 03                             jalr    $t9 ; sub_4B2A98
.text:004787EC 00 00 00 00                             nop
.text:004787F0 00 00 00 00                             nop
.text:004787F4 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:004787F8 D4 A0 99 8F                             la      $t9, sub_459DF0
.text:004787FC 09 F8 20 03                             jalr    $t9 ; sub_459DF0
.text:00478800 00 00 00 00                             nop
.text:00478804 06 00 40 14                             bnez    $v0, loc_478820
.text:00478808 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:0047880C F0 82 99 8F                             la      $t9, sub_45B064
.text:00478810 09 F8 20 03                             jalr    $t9 ; sub_45B064
.text:00478814 00 00 00 00                             nop
.text:00478818 1D 00 40 10                             beqz    $v0, loc_478890
.text:0047881C 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:00478820
.text:00478820                         loc_478820:                              # CODE XREF: sub_4786EC+118j
.text:00478820                                                                  # sub_4786EC+1B0j
.text:00478820 24 80 84 8F                             la      $a0, dword_680000
.text:00478824 30 8A 99 8F                             la      $t9, sub_666260
.text:00478828 09 F8 20 03                             jalr    $t9 ; sub_666260
.text:0047882C B8 59 84 24                             addiu   $a0, (aWeHavePopWindo - 0x680000)  # "We have POP window, so we can't let use"...
.text:00478830 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:00478834 D8 FF 00 10                             b       loc_478798
.text:00478838 01 00 03 24                             li      $v1, 1
.text:0047883C                          # ---------------------------------------------------------------------------
.text:0047883C 34 9C 99 8F                             la      $t9, sub_45EBE0
.text:00478840 09 F8 20 03                             jalr    $t9 ; sub_45EBE0
.text:00478844 96 01 04 24                             li      $a0, 0x196
.text:00478848 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:0047884C 45 01 04 24                             li      $a0, 0x145
.text:00478850 34 9C 99 8F                             la      $t9, sub_45EBE0
.text:00478854 09 F8 20 03                             jalr    $t9 ; sub_45EBE0
.text:00478858 21 80 40 00                             move    $s0, $v0
.text:0047885C 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:00478860 21 20 00 02                             move    $a0, $s0
.text:00478864 21 28 40 00                             move    $a1, $v0
.text:00478868 AC CA 99 8F                             la      $t9, sub_459140
.text:0047886C 09 F8 20 03                             jalr    $t9 ; sub_459140
.text:00478870 C1 00 06 24                             li      $a2, 0xC1
.text:00478874 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)
.text:00478878 24 80 84 8F                             la      $a0, dword_680000
.text:0047887C A0 88 99 8F                             la      $t9, sub_6660D0
.text:00478880 09 F8 20 03                             jalr    $t9 ; sub_6660D0
.text:00478884 F8 59 84 24                             addiu   $a0, (aDiskTotalSizeM - 0x680000)  # "Disk total size must be over 32G!!"
.text:00478888 B9 FF 00 10                             b       loc_478770
.text:0047888C 10 00 BC 8F                             lw      $gp, 0x20+var_10($sp)

Última coisa: encontrei um belíssimo tutorial sobre MIPS Assembly, criado por um professor da Central Connecticut State University chamado Bradley Kjell. Aqui está o link: http://programmedlessons.org/AssemblyTutorial/
Na verdade é um curso programado para ser ministrado em 1 semestre na citada universidade. Pelo que pude perceber, a intenção foi criar um curso introdutório sobre Assembly, sendo que o processador escolhido foi o MIPS. Curiosidade: vejam o que os alunos desse professor tem a dizer sobre ele.  Link: http://www.ratemyprofessors.com/ShowRatings.jsp?tid=385487
Ele recomenda que se use o simulador de MIPS chamado SPIM, para que se possa acompanhar os programas exemplos ao longo do tutorial. Testei o SPIM e é super simples de entender, e muito legal. Link do SPIM: http://pages.cs.wisc.edu/~larus/spim.html
Eu tambei testei recentemente o MIPS Assembler MARS da Missouri State University, que eu havia recomendado alguns posts atrás: http://courses.missouristate.edu/KenVollmar/MARS/
Achei muito interessante esse Assembler, que também é um simulador, e muito completo por sinal. Inclusive os programas do tutorial que recomendei acima podem ser executados no simulador do MARS (assim como no próprio SPIM, que é mais simples, e recomendado pelo autor).
Só pra finalizar, achei o Assembler MARS muito bom:
a-) Tem o Syntax Highlighting, identificando instruções, labels, comentários, etc., cada um com uma cor.
b-) Tem aquela bem-vinda função de auto-preenchimento, ou seja, você começa a digitar um instrução, e o programa já oferece as várias opções para aquela(s) letra(s) incial(ais), inclusive dando uma rápida descrição de cada uma dessas instruções possíveis.
c-) Para salvar o binário (após o código-fonte ter sido montado), é só ir em Dump Memory, e escolher Binário: me parece que salva em Little Endian; é engraçado pois no próprio programa os 4 bytes das instruções aparecem da esquerda para direita, mas quando se faz o Dump Memory, o binário é salvo em Little Endian, da direita para esquerda (cada 4 bytes).
d-) É gratuito!  Parece que o MIPS oferece mais e melhores opções gratuitas que o ARM em termos de aprendizado e ferramentas...

[rafael_netto]

Na primeira tentativa funcionou. A interface iniciou, consegui operá-la normalmente com o controle do Semp, vi o canal 10 de Brasília e troquei o vídeo para NTSC.
(...)

Rodei o Putty novamente, desta vez com log, sem reiniciar o conversor (apenas havia interrompido a interface com Ctrl-\ e rodado novamente). Desta vez a interface não iniciou e ficou cuspindo muitas mensagens relacionadas a comunicação i2c (que é usada para o tuner), se não me engano dizendo que os comandos não tinham sido aceitos ou que as respostas não eram entendidas.
(...)

Com medo de que tivesse danificado algo no STB reiniciei normalmente e fiquei aliviado ao ver a interface padrão do Semp iniciar no modo de fábrica, como era esperado.

Então mais uma vez copiei o flash0.rootfs e tentei rodar no pendrive. Daí por diante não funcionou mais. O programa é interrompido logo no início com estas mensagens: (...)

Cheguei a pensar que algo fosse escrito no filesystem, mas lembrei que ele é protegido contra gravação. A única explicação é que algum lugar, fora do rootfs, foi corrompido, e seja o que for, não afeta o software padrão do Semp (felizmente). Poderia ser nos blocos nvram ou skip, que ainda não mexemos?

Isso é estranho. Talvez após copiar novamente o rootfs, o binário do Semp chegou a fazer algumas alterações antes de ser interrompido com CTRL-\. Aconteceu comigo algumas vezes. É muito rápido. Não acho que pode ser outro bloco, porque fiz os mesmos testes aqui com seu firmware inteiro.

Refiz o teste de novo. Desta vez eu tenho certeza que interrompi o Busybox antes de mais nada (já iniciei o aparelho com o Ctrl-\ apertado...) e nada adiantou. O executável modificado simplesmente se recusa a rodar.

Um teste que eu ainda pretendo fazer é atualizar de novo o Semp com um firmware original (na verdade fazer o downgrade pra 1.0.14c) na esperança que o processo de atualização faça algum tipo de limpeza. Mas não sei se terei tempo pra isso pois vou viajar esta semana.

[rictad]

Legal saber dessa compatibilidade. Faz algum tempo que eu estou pra te perguntar sobre isso... Na verdade eu estou precisando comprar um conversor pra minha mãe, e então pensei no ZBT-601, que está com um preço ótimo. Só faltava a confirmação que você deu agora sobre a compatibilidade com o ZBT-633, pois assim, além de comprar um conversor com ótimo custo-benefício, ainda poderei brincar um pouco com o desenvolvimento do firmware (tentar ajudar nem que seja um pouquinho  ).

Opa! Acho que teremos um gás extra no desenvolvimento.

Outra coisa: eu abri recentemente um binário zmw_base_zinwell que você enviou, no IDA 5.5.0, e fiquei POSITIVAMENTE impressionado com a quantidade de "comentários" espalhados por todo o código. Esses "comentários" que na verdade são as mensagens enviadas para o console são realmente muito bem-vindos. Com eles, a gente não fica desesperadamente perdido no meio de tudo (é bem diferente dos firmwares Mediatek, em que não existia nada disso).
Como você ressaltou algumas vezes já neste tópico, os comentários servem pra nos mostrar que estamos no lugar certo... É claro que precisa decifrar as instruções da redondeza do comentário que interessa para se chegar a rotina definitiva que executa determinada função. De qualquer modo, me pareceu que ajuda bastante, já que cada comentário serve como uma pista, um ponto de partida, ou uma idéia para uma nova modificação...
Um exemplo: próximo de onde você colocou os NOPs pra acabar com o limite de 32G existe a string "# "Disk total size must be over 32G!!".

Esses comentários ajudam bastante mesmo. Mas alguns poucos podem ser fakes. Normalmente você verá um sempre repetido no início de várias rotinas, apontando alguma string ASCII ou mesmo Unicode que não faz sentido. Geralmente é um dos ponteiros de string (#680000 ou #690000) que o IDA acaba considerando ele próprio uma referência a string. Esses ponteiros são atualizados com offsets para indicar as verdadeiras referências as strings utilizadas na rotina. Normalmente são carregados em $a1 ou $a0 e atualizados com operações ADD. Também algumas poucas strings acabam sendo esquecidas devido à estrutura mais trabalhada do código. Por exemplo, em todos os zmw_base_zinwell que analisei mais cuidadosamente, ao buscar "mke2fs", que é o comando para criar partições ext2/ext3, só achei o ponto em que a string está, mas não achei nenhum comentário referente àquela string. Eu acabei encontrando a referência a ela seguindo a rotina que faz referências a outras strings relacionadas com a formatação, como "fmtHDisk" e "create partition done!". Sabendo o valor absoluto do endereço da string "mke2fs", eu segui as atualizações nos valores do registrador a1 e marquei os pontos. Segue a rotina que formata (uma de duas). Além desse comentário que deixou de ser registrado, podemos ver o comentário fake, que no caso do zmw_base_zinwell da versão 1.14.7 é "x: width=%u, height=%u, components=%d", que na verdade é um dos ponteiros de string, o endereço #690000 (essa string que ele aponta é, portanto, o offset 0 para #690000). O comentário com o comando "mke2fs" foi inserido de forma natural mesmo. Mas é possível forçar o IDA a reconhecer aquele ponto como referência a um endereço relativo, que será nomeado pelo início da string. É só usar CTRL-R e colocar no endereço base o valor #690000 que ele vai atualizar com o offset -#2818.

Código: [Selecionar]

text:004D80FC                         sub_4D80FC:                              # DATA XREF: sub_48C15C+11B8_o
.text:004D80FC                                                                  # .got:00BB8ABC_o
.text:004D80FC
.text:004D80FC                         var_29D4        = -0x29D4
.text:004D80FC                         var_238         = -0x238
.text:004D80FC                         var_234         = -0x234
.text:004D80FC                         var_230         = -0x230
.text:004D80FC                         var_220         = -0x220
.text:004D80FC                         var_28          = -0x28
.text:004D80FC                         var_24          = -0x24
.text:004D80FC                         var_20          = -0x20
.text:004D80FC                         var_1C          = -0x1C
.text:004D80FC                         var_18          = -0x18
.text:004D80FC                         var_14          = -0x14
.text:004D80FC                         var_10          = -0x10
.text:004D80FC                         var_C           = -0xC
.text:004D80FC                         var_8           = -8
.text:004D80FC                         var_4           = -4
.text:004D80FC
.text:004D80FC 6E 00 1C 3C 14 7E 9C 27                 la      $gp, unk_6E7E14
.text:004D8104 21 E0 99 03                             addu    $gp, $t9
.text:004D8108 B8 FD BD 27                             addiu   $sp, -0x248
.text:004D810C 44 02 BF AF                             sw      $ra, 0x248+var_4($sp)
.text:004D8110 40 02 BE AF                             sw      $fp, 0x248+var_8($sp)
.text:004D8114 3C 02 B7 AF                             sw      $s7, 0x248+var_C($sp)
.text:004D8118 38 02 B6 AF                             sw      $s6, 0x248+var_10($sp)
.text:004D811C 34 02 B5 AF                             sw      $s5, 0x248+var_14($sp)
.text:004D8120 30 02 B4 AF                             sw      $s4, 0x248+var_18($sp)
.text:004D8124 2C 02 B3 AF                             sw      $s3, 0x248+var_1C($sp)
.text:004D8128 28 02 B2 AF                             sw      $s2, 0x248+var_20($sp)
.text:004D812C 24 02 B1 AF                             sw      $s1, 0x248+var_24($sp)
.text:004D8130 20 02 B0 AF                             sw      $s0, 0x248+var_28($sp)
.text:004D8134 18 00 BC AF                             sw      $gp, 0x248+var_230($sp)
.text:004D8138 34 80 84 8F                             la      $a0, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D813C A0 88 99 8F                             la      $t9, sub_6662E0
.text:004D8140 24 80 94 8F                             la      $s4, dword_680000
.text:004D8144 09 F8 20 03                             jalr    $t9 ; sub_6662E0
.text:004D8148 68 D7 84 24                             addiu   $a0, (aEnterZw_pvrfil - 0x690000)  # "Enter zw_pvrfile_fmtHDisk function "
.text:004D814C 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8150 70 5B 84 26                             addiu   $a0, $s4, (aDevSda - 0x680000)  # "/dev/sda"
.text:004D8154 54 AA 99 8F                             la      $t9, sub_4D7120
.text:004D8158 09 F8 20 03                             jalr    $t9 ; sub_4D7120
.text:004D815C 21 90 00 00                             move    $s2, $0
.text:004D8160 21 88 40 00                             move    $s1, $v0
.text:004D8164 01 00 02 24                             li      $v0, 1
.text:004D8168 29 00 22 12                             beq     $s1, $v0, loc_4D8210
.text:004D816C 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8170 34 80 84 8F                             la      $a0, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D8174 A0 88 99 8F                             la      $t9, sub_6662E0
.text:004D8178 09 F8 20 03                             jalr    $t9 ; sub_6662E0
.text:004D817C 8C D7 84 24                             addiu   $a0, (aErrorHardDiskD - 0x690000)  # "Error: Hard disk does not exist! "
.text:004D8180 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8184 38 9C 99 8F                             la      $t9, sub_45EC40
.text:004D8188 09 F8 20 03                             jalr    $t9 ; sub_45EC40
.text:004D818C 96 01 04 24                             li      $a0, 0x196
.text:004D8190 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8194 4E 01 04 24                             li      $a0, 0x14E
.text:004D8198 38 9C 99 8F                             la      $t9, sub_45EC40
.text:004D819C 09 F8 20 03                             jalr    $t9 ; sub_45EC40
.text:004D81A0 21 80 40 00                             move    $s0, $v0
.text:004D81A4 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D81A8 10 00 A0 AF                             sw      $0, 0x248+var_238($sp)
.text:004D81AC 21 28 00 02                             move    $a1, $s0
.text:004D81B0 F0 96 99 8F                             la      $t9, sub_4A88AC
.text:004D81B4 21 30 40 00                             move    $a2, $v0
.text:004D81B8 01 00 04 24                             li      $a0, 1
.text:004D81BC 09 F8 20 03                             jalr    $t9 ; sub_4A88AC
.text:004D81C0 D0 07 07 24                             li      $a3, 0x7D0
.text:004D81C4 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D81C8
.text:004D81C8                         loc_4D81C8:                              # CODE XREF: sub_4D80FC+5D8_j
.text:004D81C8                                                                  # sub_4D80FC+5FC_j
.text:004D81C8 AC 80 82 8F                             la      $v0, unk_D50000
.text:004D81CC E8 85 99 8F                             la      $t9, sub_403550
.text:004D81D0 58 8C 84 8F                             la      $a0, sub_48C15C
.text:004D81D4 09 F8 20 03                             jalr    $t9 ; sub_403550
.text:004D81D8 79 C7 40 A0                             sb      $0, (byte_D4C779 - 0xD50000)($v0)
.text:004D81DC 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D81E0 44 02 BF 8F                             lw      $ra, 0x248+var_4($sp)
.text:004D81E4 40 02 BE 8F                             lw      $fp, 0x248+var_8($sp)
.text:004D81E8 3C 02 B7 8F                             lw      $s7, 0x248+var_C($sp)
.text:004D81EC 38 02 B6 8F                             lw      $s6, 0x248+var_10($sp)
.text:004D81F0 34 02 B5 8F                             lw      $s5, 0x248+var_14($sp)
.text:004D81F4 30 02 B4 8F                             lw      $s4, 0x248+var_18($sp)
.text:004D81F8 2C 02 B3 8F                             lw      $s3, 0x248+var_1C($sp)
.text:004D81FC 28 02 B2 8F                             lw      $s2, 0x248+var_20($sp)
.text:004D8200 24 02 B1 8F                             lw      $s1, 0x248+var_24($sp)
.text:004D8204 20 02 B0 8F                             lw      $s0, 0x248+var_28($sp)
.text:004D8208 08 00 E0 03                             jr      $ra
.text:004D820C 48 02 BD 27                             addiu   $sp, 0x248
.text:004D8210                          # ---------------------------------------------------------------------------
.text:004D8210
.text:004D8210                         loc_4D8210:                              # CODE XREF: sub_4D80FC+6C_j
.text:004D8210 38 9C 99 8F                             la      $t9, sub_45EC40
.text:004D8214 95 01 04 24                             li      $a0, 0x195
.text:004D8218 09 F8 20 03                             jalr    $t9 ; sub_45EC40
.text:004D821C 03 00 16 24                             li      $s6, 3
.text:004D8220 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8224 49 01 04 24                             li      $a0, 0x149
.text:004D8228 38 9C 99 8F                             la      $t9, sub_45EC40
.text:004D822C 09 F8 20 03                             jalr    $t9 ; sub_45EC40
.text:004D8230 21 80 40 00                             move    $s0, $v0
.text:004D8234 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8238 10 00 B6 AF                             sw      $s6, 0x248+var_238($sp)
.text:004D823C 14 00 A0 AF                             sw      $0, 0x248+var_234($sp)
.text:004D8240 1C AE 99 8F                             la      $t9, sub_4A89BC
.text:004D8244 21 28 00 02                             move    $a1, $s0
.text:004D8248 21 30 40 00                             move    $a2, $v0
.text:004D824C 21 20 00 00                             move    $a0, $0
.text:004D8250 09 F8 20 03                             jalr    $t9 ; sub_4A89BC
.text:004D8254 01 00 07 24                             li      $a3, 1
.text:004D8258 FF 00 53 30                             andi    $s3, $v0, 0xFF
.text:004D825C 13 00 71 12                             beq     $s3, $s1, loc_4D82AC
.text:004D8260 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8264 AC 80 82 8F                             la      $v0, unk_D50000
.text:004D8268 E8 85 99 8F                             la      $t9, sub_403550
.text:004D826C F4 A1 84 8F                             la      $a0, sub_478C84
.text:004D8270 09 F8 20 03                             jalr    $t9 ; sub_403550
.text:004D8274 79 C7 40 A0                             sb      $0, (byte_D4C779 - 0xD50000)($v0)
.text:004D8278 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D827C 44 02 BF 8F                             lw      $ra, 0x248+var_4($sp)
.text:004D8280 40 02 BE 8F                             lw      $fp, 0x248+var_8($sp)
.text:004D8284 3C 02 B7 8F                             lw      $s7, 0x248+var_C($sp)
.text:004D8288 38 02 B6 8F                             lw      $s6, 0x248+var_10($sp)
.text:004D828C 34 02 B5 8F                             lw      $s5, 0x248+var_14($sp)
.text:004D8290 30 02 B4 8F                             lw      $s4, 0x248+var_18($sp)
.text:004D8294 2C 02 B3 8F                             lw      $s3, 0x248+var_1C($sp)
.text:004D8298 28 02 B2 8F                             lw      $s2, 0x248+var_20($sp)
.text:004D829C 24 02 B1 8F                             lw      $s1, 0x248+var_24($sp)
.text:004D82A0 20 02 B0 8F                             lw      $s0, 0x248+var_28($sp)
.text:004D82A4 08 00 E0 03                             jr      $ra
.text:004D82A8 48 02 BD 27                             addiu   $sp, 0x248
.text:004D82AC                          # ---------------------------------------------------------------------------
.text:004D82AC
.text:004D82AC                         loc_4D82AC:                              # CODE XREF: sub_4D80FC+160_j
.text:004D82AC 00 C3 99 8F                             la      $t9, sub_45C278
.text:004D82B0 09 F8 20 03                             jalr    $t9 ; sub_45C278
.text:004D82B4 01 00 04 24                             li      $a0, 1
.text:004D82B8 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D82BC B4 CF 99 8F                             la      $t9, sub_45B980
.text:004D82C0 09 F8 20 03                             jalr    $t9 ; sub_45B980
.text:004D82C4 00 00 00 00                             nop
.text:004D82C8 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D82CC 23 01 04 3C                             lui     $a0, 0x123
.text:004D82D0 F8 86 99 8F                             la      $t9, sub_66DDC0
.text:004D82D4 09 F8 20 03                             jalr    $t9 ; sub_66DDC0
.text:004D82D8 67 45 84 34                             li      $a0, 0x1234567
.text:004D82DC 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D82E0 BC BE 99 8F                             la      $t9, sub_43BE84
.text:004D82E4 09 F8 20 03                             jalr    $t9 ; sub_43BE84
.text:004D82E8 88 13 04 24                             li      $a0, 0x1388
.text:004D82EC 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D82F0 78 CC 99 8F                             la      $t9, sub_4CE9B8
.text:004D82F4 09 F8 20 03                             jalr    $t9 ; sub_4CE9B8
.text:004D82F8 00 00 00 00                             nop
.text:004D82FC 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8300 01 00 04 24                             li      $a0, 1
.text:004D8304 AC 80 82 8F                             la      $v0, unk_D50000
.text:004D8308 D0 91 99 8F                             la      $t9, sub_465F60
.text:004D830C 09 F8 20 03                             jalr    $t9 ; sub_465F60
.text:004D8310 79 C7 53 A0                             sb      $s3, (byte_D4C779 - 0xD50000)($v0)
.text:004D8314 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8318 E8 87 99 8F                             la      $t9, sub_465588
.text:004D831C 09 F8 20 03                             jalr    $t9 ; sub_465588
.text:004D8320 00 00 00 00                             nop
.text:004D8324 F6 00 40 14                             bnez    $v0, loc_4D8700
.text:004D8328 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D832C
.text:004D832C                         loc_4D832C:                              # CODE XREF: sub_4D80FC+610_j
.text:004D832C 24 80 84 8F                             la      $a0, dword_680000
.text:004D8330 B8 A1 99 8F                             la      $t9, sub_66CA00
.text:004D8334 AC 80 95 8F                             la      $s5, unk_D50000
.text:004D8338 09 F8 20 03                             jalr    $t9 ; sub_66CA00
.text:004D833C DC F2 84 24                             addiu   $a0, (aMnt - 0x680000)  # "/mnt"
.text:004D8340 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8344 34 80 84 8F                             la      $a0, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D8348 04 87 99 8F                             la      $t9, sub_66E590
.text:004D834C 9C 8E 90 8F                             la      $s0, dword_D4C770
.text:004D8350 09 F8 20 03                             jalr    $t9 ; sub_66E590
.text:004D8354 50 D8 84 24                             addiu   $a0, (aTDevSda1MntUsb+0xC - 0x690000)
.text:004D8358 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D835C 24 80 84 8F                             la      $a0, dword_680000
.text:004D8360 04 87 99 8F                             la      $t9, sub_66E590
.text:004D8364 09 F8 20 03                             jalr    $t9 ; sub_66E590
.text:004D8368 D8 31 84 24                             addiu   $a0, (aMntUsb2 - 0x680000)  # "/mnt/usb2"
.text:004D836C 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8370 24 80 84 8F                             la      $a0, dword_680000
.text:004D8374 04 87 99 8F                             la      $t9, sub_66E590
.text:004D8378 09 F8 20 03                             jalr    $t9 ; sub_66E590
.text:004D837C E4 31 84 24                             addiu   $a0, (aMntUsb3 - 0x680000)  # "/mnt/usb3"
.text:004D8380 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8384 24 80 84 8F                             la      $a0, dword_680000
.text:004D8388 04 87 99 8F                             la      $t9, sub_66E590
.text:004D838C 09 F8 20 03                             jalr    $t9 ; sub_66E590
.text:004D8390 F0 31 84 24                             addiu   $a0, (aMntUsb4 - 0x680000)  # "/mnt/usb4"
.text:004D8394 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8398 30 00 02 24                             li      $v0, 0x30
.text:004D839C 21 30 00 00                             move    $a2, $0
.text:004D83A0 A8 80 84 8F                             la      $a0, loc_4D0000
.text:004D83A4 34 80 85 8F                             la      $a1, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D83A8 E0 D8 99 8F                             la      $t9, sub_43BF18
.text:004D83AC 64 00 07 24                             li      $a3, 0x64
.text:004D83B0 78 C7 B3 A2                             sb      $s3, -0x3888($s5)
.text:004D83B4 A4 77 84 24                             addiu   $a0, (sub_4D77A4 - 0x4D0000)
.text:004D83B8 B0 D7 A5 24                             addiu   $a1, (aFmthdisk - 0x690000)  # "fmtHDisk"
.text:004D83BC 10 00 A2 AF                             sw      $v0, 0x248+var_238($sp)
.text:004D83C0 09 F8 20 03                             jalr    $t9 ; sub_43BF18
.text:004D83C4 14 00 A0 AF                             sw      $0, 0x248+var_234($sp)
.text:004D83C8 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D83CC 7F 7C 02 24                             li      $v0, 0x7C7F
.text:004D83D0 70 5B 84 26                             addiu   $a0, $s4, 0x5B70
.text:004D83D4 A8 80 99 8F                             la      $t9, loc_4D0000
.text:004D83D8 83 00 05 24                             li      $a1, 0x83
.text:004D83DC 34 7A 39 27                             addiu   $t9, (sub_4D7A34 - 0x4D0000)
.text:004D83E0 09 F8 20 03                             jalr    $t9 ; sub_4D7A34
.text:004D83E4 00 00 02 AE                             sw      $v0, 0($s0)
.text:004D83E8 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D83EC 34 80 84 8F                             la      $a0, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D83F0 A0 88 99 8F                             la      $t9, sub_6662E0
.text:004D83F4 09 F8 20 03                             jalr    $t9 ; sub_6662E0
.text:004D83F8 BC D7 84 24                             addiu   $a0, (aCreatePartitio - 0x690000)  # "create partition done!"
.text:004D83FC 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8400 00 00 03 8E                             lw      $v1, 0($s0)
.text:004D8404 DC BA 82 8F                             la      $v0, dword_D4C774
.text:004D8408 34 80 84 8F                             la      $a0, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D840C 30 8A 99 8F                             la      $t9, sub_666470
.text:004D8410 00 00 45 8C                             lw      $a1, (dword_D4C774 - 0xD4C774)($v0)
.text:004D8414 D4 D7 84 24                             addiu   $a0, (aPartition_numD - 0x690000)  # "partition_num=%d\n"
.text:004D8418 1B 00 A3 00                             divu    $a1, $v1
.text:004D841C 02 00 60 14                             bnez    $v1, loc_4D8428
.text:004D8420 00 00 00 00                             nop
.text:004D8424 0D 00 07 00                             break   0x1C00
.text:004D8428
.text:004D8428                         loc_4D8428:                              # CODE XREF: sub_4D80FC+320_j
.text:004D8428 12 28 00 00                             mflo    $a1
.text:004D842C 00 2E 05 00                             sll     $a1, 24
.text:004D8430 03 2E 05 00                             sra     $a1, 24
.text:004D8434 04 00 A2 28                             slti    $v0, $a1, 4
.text:004D8438 0A 28 C2 02                             movz    $a1, $s6, $v0
.text:004D843C 09 F8 20 03                             jalr    $t9
.text:004D8440 01 00 B4 24                             addiu   $s4, $a1, 1
.text:004D8444 11 00 80 1A                             blez    $s4, loc_4D848C
.text:004D8448 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D844C 34 80 93 8F                             la      $s3, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D8450 28 00 B1 27                             addiu   $s1, $sp, 0x248+var_220
.text:004D8454
.text:004D8454                         loc_4D8454:                              # CODE XREF: sub_4D80FC+388_j
.text:004D8454 F8 99 99 8F                             la      $t9, sub_666500
.text:004D8458 01 00 50 26                             addiu   $s0, $s2, 1
.text:004D845C 21 20 20 02                             move    $a0, $s1
.text:004D8460 E8 D7 65 26                             addiu   $a1, $s3, -0x2818  # comando mke2fs
.text:004D8464 09 F8 20 03                             jalr    $t9 ; sub_666500
.text:004D8468 21 30 00 02                             move    $a2, $s0
.text:004D846C 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8470 21 20 20 02                             move    $a0, $s1
.text:004D8474 8C D0 99 8F                             la      $t9, sub_61A230
.text:004D8478 09 F8 20 03                             jalr    $t9 ; sub_61A230
.text:004D847C 21 90 00 02                             move    $s2, $s0
.text:004D8480 2A 18 14 02                             slt     $v1, $s0, $s4
.text:004D8484 F3 FF 60 14                             bnez    $v1, loc_4D8454
.text:004D8488 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D848C
.text:004D848C                         loc_4D848C:                              # CODE XREF: sub_4D80FC+348_j
.text:004D848C 78 C7 A0 A2                             sb      $0, -0x3888($s5)
.text:004D8490
.text:004D8490                         loc_4D8490:                              # CODE XREF: sub_4D80FC+3A4_j
.text:004D8490 BC BE 99 8F                             la      $t9, sub_43BE84
.text:004D8494 09 F8 20 03                             jalr    $t9 ; sub_43BE84
.text:004D8498 64 00 04 24                             li      $a0, 0x64
.text:004D849C 78 C7 A2 82                             lb      $v0, -0x3888($s5)
.text:004D84A0 FB FF 40 10                             beqz    $v0, loc_4D8490
.text:004D84A4 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D84A8 34 80 84 8F                             la      $a0, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D84AC A0 88 99 8F                             la      $t9, sub_6662E0
.text:004D84B0 01 00 12 24                             li      $s2, 1
.text:004D84B4 09 F8 20 03                             jalr    $t9 ; sub_6662E0
.text:004D84B8 28 D8 84 24                             addiu   $a0, (aDone - 0x690000)  # "done!"
.text:004D84BC 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D84C0 34 80 84 8F                             la      $a0, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D84C4 8C D0 99 8F                             la      $t9, sub_61A230
.text:004D84C8 09 F8 20 03                             jalr    $t9 ; sub_61A230
.text:004D84CC 30 D8 84 24                             addiu   $a0, (aMkdirMntUsb - 0x690000)  # "mkdir /mnt/usb"
.text:004D84D0 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D84D4 34 80 84 8F                             la      $a0, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D84D8 8C D0 99 8F                             la      $t9, sub_61A230
.text:004D84DC 09 F8 20 03                             jalr    $t9 ; sub_61A230
.text:004D84E0 40 D8 84 24                             addiu   $a0, (unk_68D840 - 0x690000)
.text:004D84E4 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D84E8 34 80 84 8F                             la      $a0, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D84EC 8C D0 99 8F                             la      $t9, sub_61A230
.text:004D84F0 09 F8 20 03                             jalr    $t9 ; sub_61A230
.text:004D84F4 58 93 84 24                             addiu   $a0, (aMkdirMntUsbVid - 0x690000)  # "mkdir /mnt/usb/video"
.text:004D84F8 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D84FC 34 80 84 8F                             la      $a0, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D8500 8C D0 99 8F                             la      $t9, sub_61A230
.text:004D8504 09 F8 20 03                             jalr    $t9 ; sub_61A230
.text:004D8508 C0 92 84 24                             addiu   $a0, (aMkdirMntUsbAud - 0x690000)  # "mkdir /mnt/usb/audio"
.text:004D850C 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8510 34 80 84 8F                             la      $a0, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D8514 8C D0 99 8F                             la      $t9, sub_61A230
.text:004D8518 09 F8 20 03                             jalr    $t9 ; sub_61A230
.text:004D851C 70 93 84 24                             addiu   $a0, (aMkdirMntUsbPic - 0x690000)  # "mkdir /mnt/usb/picture"
.text:004D8520 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8524 34 80 84 8F                             la      $a0, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D8528 8C D0 99 8F                             la      $t9, sub_61A230
.text:004D852C 09 F8 20 03                             jalr    $t9 ; sub_61A230
.text:004D8530 5C D8 84 24                             addiu   $a0, (aMkdirMntUsbRec - 0x690000)  # "mkdir /mnt/usb/recycle"
.text:004D8534 2A 18 54 02                             slt     $v1, $s2, $s4
.text:004D8538 49 00 60 10                             beqz    $v1, loc_4D8660
.text:004D853C 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8540 34 80 9E 8F                             la      $fp, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D8544 34 80 97 8F                             la      $s7, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D8548 34 80 96 8F                             la      $s6, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D854C 34 80 95 8F                             la      $s5, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D8550 34 80 93 8F                             la      $s3, aXWidthUHeightU  # "x: width=%u, height=%u, components=%d"
.text:004D8554 28 00 B1 27                             addiu   $s1, $sp, 0x248+var_220
.text:004D8558
(...)
(...)
(...)
.text:004D8700 EC C8 99 8F                             la      $t9, sub_45FA38
.text:004D8704 09 F8 20 03                             jalr    $t9 ; sub_45FA38
.text:004D8708 21 20 00 00                             move    $a0, $0
.text:004D870C 07 FF 00 10                             b       loc_4D832C
.text:004D8710 18 00 BC 8F                             lw      $gp, 0x248+var_230($sp)
.text:004D8710                          # End of function sub_4D80FC
.text:004D8710


Refiz o teste de novo. Desta vez eu tenho certeza que interrompi o Busybox antes de mais nada (já iniciei o aparelho com o Ctrl-\ apertado...) e nada adiantou. O executável modificado simplesmente se recusa a rodar.

Um teste que eu ainda pretendo fazer é atualizar de novo o Semp com um firmware original (na verdade fazer o downgrade pra 1.0.14c) na esperança que o processo de atualização faça algum tipo de limpeza. Mas não sei se terei tempo pra isso pois vou viajar esta semana.

É, rafael, estou começando a desconfiar daquele bloco nvram também. O estranho é que na primeira vez funcionou. E aqui eu consegui alternar entre ambos os zmw_base_zinwell algumas vezes, desde que o bloco rootfs do Zinwell recém gravado não fosse alterado pelo do SEMP.
Bom, se você for fazer o downgrade, toma cuidado para preservar o bloco LOAD. Ele não precisa ser alterado e assim você não corre o risco de perder o CFE.

[rafael_netto]

É, rafael, estou começando a desconfiar daquele bloco nvram também. O estranho é que na primeira vez funcionou. E aqui eu consegui alternar entre ambos os zmw_base_zinwell algumas vezes, desde que o bloco rootfs do Zinwell recém gravado não fosse alterado pelo do SEMP.
Bom, se você for fazer o downgrade, toma cuidado para preservar o bloco LOAD. Ele não precisa ser alterado e assim você não corre o risco de perder o CFE.

Resolvido o mistério!

De fato a coisa era bem mais simples do que a gente imaginava. E os demais blocos da memória não têm nada a ver com isso.

O problema é que não se pode simplesmente dar boot com o "Ctrl-\" apertado. Isso aborta a própria carga do sistema operacional e faz com que outras coisas não funcionem. Tive a certeza disso quando em algumas ocasiões o próprio /usr/sbin/usbhd-start não funcionava! (não dá erro, mas não faz nada). E isso é algo meio aleatório.

Antes disso eu já tinha desconfiado do bcmdriver.ko, que pelo que eu entendi é um módulo que "prepara" a execução da interface ou algo assim, e precisa ser chamado antes.

Enfim, com sorte e um pouco de habilidade consegui interromper a execução no ponto certo (após o bcmdriver.ko, mas antes do zmw_base_zinwell) e rodei o executável do pendrive novamente sem problema nenhum!

Para ilustrar... eu entendi que o boot termina com a execução destes dois scripts:

/etc/init.d

Código: [Selecionar]

#! /bin/sh

# Set the path
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:.

# Mount /proc
echo "Mount /proc fs"
mount -t proc none /proc

# Mount /dev/pts
echo "Mount /dev/pts"
mount -t devpts none /dev/pts

# Setup up /etc/mtab link
ln -sf /proc/mounts /etc/mtab


# Start application
export AppPartition=$(sed -n -e '/app/s/^...\([0-9]\).*/\/dev\/mtdblock\1/p' /proc/mtd)
mount $AppPartition /mnt/hd -t squashfs
cd /mnt/hd
./settop zmw_base_zinwell


Ele termina montando a pasta /mnt/hd (usando o squashfs) e chamando /mnt/hd/settop, cujo parâmetro é o nome do executável da interface:

Código: [Selecionar]

#!/bin/sh
# this script sets LD_LIBRARY_PATH environment variable
# and checks consistence of the system configuration
LD_LIBRARY_PATH=.:${LD_LIBRARY_PATH}
export LD_LIBRARY_PATH
PATH=.:${PATH}
export PATH

# So dirty... if uname is not called, then the internal machine name will be incorrect, causing loading of bcmdriver.ko to
# fail. This happens on a minimum rootfs
uname
ulimit -c unlimited

# Install 97038 board, both B and C boards.

# Remove all possible drivers

/sbin/rmmod bcmdriver bcm7401

# Install the user-mode driver.
# This means that the porting interface runs in user mode.

/sbin/insmod ./bcmdriver.ko


# Start whatever application is requested
target=$1;
shift
${target} $@
ls /mnt/usb/core*.* -l
umount /mnt/usb

Este entre outras coisas chama o bcmdriver.ko e termina chamando o executável da interface passado como parâmetro. Parece que as últimas linhas deveriam ser executadas quando a interface acaba de rodar mas na prática o botão liga-desliga interrompe tudo abruptamente como já foi dito aqui.

Quanto ao procedimento de boot, eu verifiquei isto:

Código: [Selecionar]

init started:  BusyBox v1.2.1 (2007.04.18-10:43+0000) multi-call binary
Starting pid 15, console /dev/ttyS0: '/etc/init.d/rcSAlgorithmics/MIPS FPU Emulator v1.5

ABORTANDO NESTE PONTO NEM O USB FUNCIONA

 Mount /proc fs
Mount /dev/p

ABORTANDO NESTE PONTO O USB FUNCIONA, MAS NÃO A INTERFACE

Linux
rmmod: bcmdriver: No such file or directory
rmmod: bcm7401: No such file or directory
bcmdriver: no version magic, tainting kernel.

bcmdriver: module license 'Proprietary' taints kernel.

Initializing bcmdriver version $ 11 $

Bootup time start 2112

MCK - Using Interrupt Definition for 7402c0 (uname -a)

chipConfigs[19].maxNumIrq = 65

Global Interrupt Mask Low: 0xD15F7FFF, High: 0x1C0C11D3

Initialization complete...

Bootup time end 2130

A PARTIR DESTE PONTO TUDO FUNCIONA

O zmw_base_zinwell original é executado logo em seguida, portanto o ponto de parada é crítico. Mas na prática acho que acertar o ponto certo não é tão difícil quanto parece (este eu acertei de primeira).

Uma vez feito isto consegui rodar perfeitamente o executável modificado pelo Rictad seguindo as orientações, o controle do Semp funcionou perfeitamente. Não testei a fundo, mas as setas, OK e Exit com certeza funcionam. Cheguei a experimentar uma sintonia automática, só pra ver que ele corre os canais rapidamente sem achar nada (ainda não tinha confirmado pelo log que não havia tuner encontrado).

O log da inicialização do programa, até o momento em que ele inicializaria o tuner (e não encontra) é o seguinte:

Código: [Selecionar]

broadcom create task 10 b_event
broadcom create task 30 b_idle
boot time till here (boot bsp start) 30342
Before zw_init_i2c_hw
Before zw_init_common_interface
BCHP_EBI_CS_BASE_0 0x1e00000c
BCHP_EBI_CS_CONFIG_0 0x02000411
BCHP_EBI_CS_BASE_1 0x1c00000c
BCHP_EBI_CS_CONFIG_1 0x07000410
BCHP_EBI_CS_BASE_2 0x00000000
BCHP_EBI_CS_CONFIG_2 0x07000000
BCHP_EBI_CS_BASE_3 0x00000000
BCHP_EBI_CS_CONFIG_3 0x07000000
boot time till here (boot bsp end) 30366
boot time till here (bsettop boot board impl done) 30388
boot time till here (xpt done) 30881
boot time till here (video done) 31199
boot time till here (xvd done) 32071
boot time till here (audio done) 32240
boot time till here (user io done) 32241
boot time till here (hdmi done) 32243
boot time till here (pboot done) 32243
boot time till here (bsettop init) 32244
broadcom create task 32 file_io_0
broadcom create task 32 file_io_1
boot time till here (main()) 32261
create heap
boot time till here (os init done) 32276
pin mux: 4040bc = a241209
pin mux: 4040c0 = 45ö1120
DDR PLL: 106818 = 126
gpio dir: 400728 = fffffdff
gpio val: 400724 = 22400
hw ver 000
>>> Warning...Manual forced HW version to 8
 <<<boot time till here 32291
tast_create in
boot time till here (tuner init start) 32292
mux: 4040b0 = 92492d9
400708 = ffffefff
400704 = 4c0e5c5
task_create out tuner 6151
zw_uart7401_init channel A, baud = 9600
zw_uart7401_init channel B, baud = 115200
zw_uart7401_init done
boot time till here (io init done) 32295
boot time till here (av hal init done) 32423
>> zw_frontend_init -->
zw_tc90517_register
entered into zw_gfx_hal_init
config graphics 0
Read TC90517 register C5h:  0
TC90517 not found!
zw_tc90507_register
TC90507 not found!
Error: No tuner installed ...
boot time till here (tuner init done) 32454

Ficam aparecendo insistentes mensagens mount status 00000000 , como eu já havia dito antes.

Quando faz o scan automático, aparecem mensagens assim (em meio aos mount status):

Código: [Selecionar]

SCAN >>> ZW_TUNER_NOT_LOCKED
Inside ZW_SCAN_XPNDR_NOT_FOUND
Inside AUTO_SCAN_TUNE_IDLE
Inside AUTO_SCAN_END
Frank LED 0x2, set 0x0
[TUNER] Set Check Signal 0
ucFrontendHandle >= ucFrontendCtrlCount
Frank LED 0x2, set 0x0
zw_scan_startTSScan success
Inside AUTO_SCAN_TUNE


[zeurt]

rictad,
Um dos motivos que fizeram o pedroacerbi do HTForum querer vender seu ZBT-601 (para você, por coincidência  ) foi a questão do limite de 6h de gravação, que ainda está confuso para mim: esse limite existe tanto para ext3 como para FAT32? Esse limite existe tanto para gravações manuais como agendadas?
De qualquer modo achei a seguinte string no zmw_base_zinwell:

.rodata:0068B058 70 76 72 3A 20 73 74 72+aPvrStreamHasRe:.ascii "pvr: stream has recode 6hrs"<0>

Não existe referência direta à essa string no código (como no caso da string "mke2fs" que você comentou). Portanto para chegar até a referência teria que fazer o mesmo método que você fez para "mke2fs": sabendo o endereço absoluto da string do "limite de 6hrs", procurando nas rotinas relacionadas ao PVR, tentar encontrar a chamada para determinado offset à partir de algum ponteiro, não é?

Outra coisa:
Andei bisbilhotando no zmw_base_zinwell (enviado pelo rictad alguns posts atrás), e encontrei os locais onde estão as strings de todas as mensagens exibidas na tela: fica entre B48426 e B61E9E. Cada String aparece 7 vezes:
1,2,3,4,6: em Inglês
5: em Espanhol
7: em Português
O legal é que esses dados não estão comprimidos. Portanto, imagino que podemos mudá-las à vontade. Bem, acho que não tão à vontade assim, pois temos que respeitar o limite de caracteres que já está lá para cada string: trocar por uma menor pode; já trocar por uma maior ficaria mais complicado... Nos firmwares Mediatek, tinhamos à disposição aqueles programinhas pra mudarmos tudo, inclusive alterando o tamanho das strings se necessário... http://personal.inet.fi/cool/mediatek/programs/mtklangeditor.html
O objetivo disso tudo seria melhorar a tradução das mensagens na tela. Exemplos do que eu vi que poderia ser melhorado (deve haver muito mais...):
"Subtitulo": o ideal seria "Legenda"
"4:3 caixa de letra": o ideal seria deixar "4:3 Letter Box" mesmo
"16:9 tela Wide": o ideal seria deixar "16:9 Wide Screen" mesmo
"HD Tela": O ideal seria "Proporção de Tela HD"
"SD Tela": o ideal seria "Proporção de Tela SD"
"Pillar Box": nesse caso eles não traduziram, e fizeram bem... pois nem imagino uma tradução pra isso 
Além dos erros de tradução, ainda podemos ver minúsculas onde não deveriam estar (como destaquei em vermelho), etc.

Última coisa,
rictad, só me confirma uma coisa: as fontes (da GUI, das CC, etc.) estariam no próprio zmw_base_zinwell, não é?
Pergunto isso pois como você já descreveu no início deste tópico, as Closed Captions têm fontes pequenas e ruins, não é? Seria uma modificação muito legal poder melhorar isso... Falando nisso, além da fonte das Closed Captions, existe outro tipo de problema, como posicionamento problemático, caracteres errados, falta de itálico, etc.?
Eu estou pra criar um novo tópico aqui no Forum descrevendo as particularidades (e os problemas) das Closed Captions da TV Digital (tendo como ponto de comparação as CC da TV Analógica). Só pra adiantar, na minha TV Sony 40EX505 eu detectei os seguintes problemas, sendo que alguns são como certeza devidos a TV, outros devidos a transmissão, e outros que eu fiquei na dúvida sobre o causador:
- Ausência de Itálicos: Vendo o mesmo filme da Globo, na TV Analógica tem itálico, e já na TV Digital, nos pontos correspondentes, não tem itálico. Será isso um problema da transmissão, ou da TV? Por tudo que eu pude deduzir até agora, as CC digitais ,até o momento, são "upconverted" à partir das analógicas: elas não são criadas específicamente para TV Digital (com todos os recursos melhores que poderiam ser usados...).
- Falta de sincronia: na TV Analógica estão bem sincronizadas, e na Digital estão atrasadas: já ouvi falar que é problema das transmissoras, mas não tenho certeza...
- Alguns Caracteres especiais/acentuados errados: também não sei quem é o responsável...
- Formatação errada: fica evidente quando se compara com as CC dos filmes da Globo na TV Analógica, em que as falas ficam localizadas perfeitamente próximas de quem está falando...
- Fonte de tamanho pequeno, e com espaçamento entre os caracteres exagerado...

Só de lembrar como foi feita a engenharia reversa das fontes dos firmwares Mediatek, já dá um certo desespero: http://personal.inet.fi/cool/mediatek/documents/Info%20-%20MT1389%20v0.3b%20English.rtf E pensar que precisa: encontrar onde estão as fontes; fazer a engenharia reversa; criar um programa para trocar/editar as fontes. Nossa! Não sei quando (ou se) eu seria capaz de fazer esse processo completo. O máximo que eu conseguiria no momento seria tentar ajudar um pouco ali e outro aqui...

[Jefferson]

Código: [Selecionar]

init started:  BusyBox v1.2.1 (2007.04.18-10:43+0000) multi-call binary
Starting pid 15, console /dev/ttyS0: '/etc/init.d/rcSAlgorithmics/MIPS FPU Emulator v1.5

ABORTANDO NESTE PONTO NEM O USB FUNCIONA

 Mount /proc fs
Mount /dev/p

ABORTANDO NESTE PONTO O USB FUNCIONA, MAS NÃO A INTERFACE


Os comandos aparecem no terminal Telnet? Se aparecerem não deve ser difícil escrever um programa, no Windows, que pare a execução em um ponto específico, à escolha do usuário

[Jefferson]

Só de lembrar como foi feita a engenharia reversa das fontes dos firmwares Mediatek, já dá um certo desespero: http://personal.inet.fi/cool/mediatek/documents/Info%20-%20MT1389%20v0.3b%20English.rtf E pensar que precisa: encontrar onde estão as fontes; fazer a engenharia reversa; criar um programa para trocar/editar as fontes. Nossa! Não sei quando (ou se) eu seria capaz de fazer esse processo completo. O máximo que eu conseguiria no momento seria tentar ajudar um pouco ali e outro aqui...

A "scene" MT13x9 se beneficiou muito com essa documentação deixada pelos primeiros hackers. Sem ela como ponto de partida, eu nem teria começado.

[rictad]

rictad,
Um dos motivos que fizeram o pedroacerbi do HTForum querer vender seu ZBT-601 (para você, por coincidência  ) foi a questão do limite de 6h de gravação, que ainda está confuso para mim: esse limite existe tanto para ext3 como para FAT32? Esse limite existe tanto para gravações manuais como agendadas?

Pois é, eu não sei dizer, porque me desfiz do meu "tijolão" (família) e estou esperando o 601 chegar. Mas eu acho que é para os 2 formatos.

De qualquer modo achei a seguinte string no zmw_base_zinwell:

.rodata:0068B058 70 76 72 3A 20 73 74 72+aPvrStreamHasRe:.ascii "pvr: stream has recode 6hrs"<0>

Não existe referência direta à essa string no código (como no caso da string "mke2fs" que você comentou). Portanto para chegar até a referência teria que fazer o mesmo método que você fez para "mke2fs": sabendo o endereço absoluto da string do "limite de 6hrs", procurando nas rotinas relacionadas ao PVR, tentar encontrar a chamada para determinado offset à partir de algum ponteiro, não é?

Isso! Esse seria o método. Acho que (talvez esteja errado) não seja tão difícil retirar essa limitação.

Outra coisa:
Andei bisbilhotando no zmw_base_zinwell (enviado pelo rictad alguns posts atrás), e encontrei os locais onde estão as strings de todas as mensagens exibidas na tela: fica entre B48426 e B61E9E. Cada String aparece 7 vezes:
1,2,3,4,6: em Inglês
5: em Espanhol
7: em Português
O legal é que esses dados não estão comprimidos. Portanto, imagino que podemos mudá-las à vontade. Bem, acho que não tão à vontade assim, pois temos que respeitar o limite de caracteres que já está lá para cada string: trocar por uma menor pode; já trocar por uma maior ficaria mais complicado... Nos firmwares Mediatek, tinhamos à disposição aqueles programinhas pra mudarmos tudo, inclusive alterando o tamanho das strings se necessário... http://personal.inet.fi/cool/mediatek/programs/mtklangeditor.html

Mas eu descobri um modo, que seria alterar o ponteiro das strings para um lugar com mais espaço ou mesmo alterar apenas o offset relacionado à string que se quer aumentar para um outro ponto com espaço disponível. Isso funcionou bem para colocar a string "Rictad v.1.14.4c beta" na versão do firmware. 

Só de lembrar como foi feita a engenharia reversa das fontes dos firmwares Mediatek, já dá um certo desespero: http://personal.inet.fi/cool/mediatek/documents/Info%20-%20MT1389%20v0.3b%20English.rtf E pensar que precisa: encontrar onde estão as fontes; fazer a engenharia reversa; criar um programa para trocar/editar as fontes. Nossa! Não sei quando (ou se) eu seria capaz de fazer esse processo completo. O máximo que eu conseguiria no momento seria tentar ajudar um pouco ali e outro aqui...

A "scene" MT13x9 se beneficiou muito com essa documentação deixada pelos primeiros hackers. Sem ela como ponto de partida, eu nem teria começado.

Esse é o ponto! O que aqueles caras fizeram no começo foi fundamental.

Última coisa,
rictad, só me confirma uma coisa: as fontes (da GUI, das CC, etc.) estariam no próprio zmw_base_zinwell, não é?
Pergunto isso pois como você já descreveu no início deste tópico, as Closed Captions têm fontes pequenas e ruins, não é? Seria uma modificação muito legal poder melhorar isso... Falando nisso, além da fonte das Closed Captions, existe outro tipo de problema, como posicionamento problemático, caracteres errados, falta de itálico, etc.?
Eu estou pra criar um novo tópico aqui no Forum descrevendo as particularidades (e os problemas) das Closed Captions da TV Digital (tendo como ponto de comparação as CC da TV Analógica). Só pra adiantar, na minha TV Sony 40EX505 eu detectei os seguintes problemas, sendo que alguns são como certeza devidos a TV, outros devidos a transmissão, e outros que eu fiquei na dúvida sobre o causador:
- Ausência de Itálicos: Vendo o mesmo filme da Globo, na TV Analógica tem itálico, e já na TV Digital, nos pontos correspondentes, não tem itálico. Será isso um problema da transmissão, ou da TV? Por tudo que eu pude deduzir até agora, as CC digitais ,até o momento, são "upconverted" à partir das analógicas: elas não são criadas específicamente para TV Digital (com todos os recursos melhores que poderiam ser usados...).
- Falta de sincronia: na TV Analógica estão bem sincronizadas, e na Digital estão atrasadas: já ouvi falar que é problema das transmissoras, mas não tenho certeza...
- Alguns Caracteres especiais/acentuados errados: também não sei quem é o responsável...
- Formatação errada: fica evidente quando se compara com as CC dos filmes da Globo na TV Analógica, em que as falas ficam localizadas perfeitamente próximas de quem está falando...
- Fonte de tamanho pequeno, e com espaçamento entre os caracteres exagerado...

Sim, as fontes devem estar no zmw_base_zinwell. E o CC é o padrão mesmo. Acho aquilo um absurdo de ruim. Quem depende de closed caption acaba sofrendo um total descaso dos fabricantes.

[rictad]

Código: [Selecionar]

init started:  BusyBox v1.2.1 (2007.04.18-10:43+0000) multi-call binary
Starting pid 15, console /dev/ttyS0: '/etc/init.d/rcSAlgorithmics/MIPS FPU Emulator v1.5

ABORTANDO NESTE PONTO NEM O USB FUNCIONA

 Mount /proc fs
Mount /dev/p

ABORTANDO NESTE PONTO O USB FUNCIONA, MAS NÃO A INTERFACE


Os comandos aparecem no terminal Telnet? Se aparecerem não deve ser difícil escrever um programa, no Windows, que pare a execução em um ponto específico, à escolha do usuário

Sim, aparecem no terminal. Mas como estão no script de inicialização, também é possível modificar o script e criar um novo sistema de arquivos squashfs para ser gravado na flash. No novo sistema de arquivos que eu criei (mas ainda não disponibilizei porque não terminei de configurar), que tem a nova versão do busybox, eu alterei várias vezes esses scripts para permitir que executem automaticamente um binário do firmware encontrado no pen drive.

Seria possível alterar o script para que não chame o zmw_base_zinwell da flash ou chame apenas o do pen drive. Mas isso pode dificultar o uso da única porta USB para testar o PVR, já que o pen drive já estaria montado. Esse é o motivo dos vários mount 00000 que o rafael citou:

Ficam aparecendo insistentes mensagens mount status 00000000 , como eu já havia dito antes.

Rafael, para evitar essa mensagem, e conseguir testar a porta USB com o novo zmw_base_zinwell rodando, você deve criar ao menos 2 partições no pen drive. Assim, você deixa o binário na partição 0 e quando ele for chamado vai montar a partição 1, a qual pode ser usada para testar o PVR.

[rictad]

Outra coisa:
Andei bisbilhotando no zmw_base_zinwell (enviado pelo rictad alguns posts atrás), e encontrei os locais onde estão as strings de todas as mensagens exibidas na tela: fica entre B48426 e B61E9E. Cada String aparece 7 vezes:
1,2,3,4,6: em Inglês
5: em Espanhol
7: em Português
O legal é que esses dados não estão comprimidos. Portanto, imagino que podemos mudá-las à vontade. Bem, acho que não tão à vontade assim, pois temos que respeitar o limite de caracteres que já está lá para cada string: trocar por uma menor pode; já trocar por uma maior ficaria mais complicado... Nos firmwares Mediatek, tinhamos à disposição aqueles programinhas pra mudarmos tudo, inclusive alterando o tamanho das strings se necessário... http://personal.inet.fi/cool/mediatek/programs/mtklangeditor.html
O objetivo disso tudo seria melhorar a tradução das mensagens na tela. Exemplos do que eu vi que poderia ser melhorado (deve haver muito mais...):

Achei o arquivo que havia criado com o bloco de strings Unicode retirado do firmware1.14.4 (esse mesmo que você encontrou). Segue em anexo. É possível abrirmos em um editor hexadecimal e vermos como funciona a sua estrutura. Enquanto as strings ASCII são referenciadas com ponteiros nas próprias rotinas, sendo atualizados com offsets, as strings Unicode possuem uma estrutura de ponteiros no próprio bloco, semelhante à dos menus dos Mediatek.

No início do arquivo temos:
00 01 00 00 5A 68 10 01 00 00 5A 70

A primeira referência diz que a string 0001, mais precisamente a string 001 da língua 0, começa no endereço 0x00005A68 (string "Min"). A mesma string, mas da língua 1 (1001), começa no endereço 0x00005A70.

Daria para fazer um programinha que agilizasse as mudanças e traduções nas strings. O problema é que não há espaço após o bloco, ou seja, se ele aumentar de tamanho tem que ser mudado de lugar. Neste caso, temos que descobrir onde estaria a referência a todo o bloco. Se tiver uma referência em cada rotina, fica mais difícil. Uma solução seria alterar apenas o ponteiro das strings, tirando elas do bloco e as jogando para um lugar vazio. Ainda sim dá problemas, pois acho que em cada versão do firmware o bloco fica em lugar diferente e os espaços vazios seriam outros também. De qualquer forma, fica fácil fazer pequenas alterações manuais.

[zeurt]

Daria para fazer um programinha que agilizasse as mudanças e traduções nas strings. O problema é que não há espaço após o bloco, ou seja, se ele aumentar de tamanho tem que ser mudado de lugar. Neste caso, temos que descobrir onde estaria a referência a todo o bloco. Se tiver uma referência em cada rotina, fica mais difícil. Uma solução seria alterar apenas o ponteiro das strings, tirando elas do bloco e as jogando para um lugar vazio. Ainda sim dá problemas, pois acho que em cada versão do firmware o bloco fica em lugar diferente e os espaços vazios seriam outros também. De qualquer forma, fica fácil fazer pequenas alterações manuais.

Eu dei uma olhada aqui no IDA, e só existem 2 referencias para essa tabela das strings Unicode. São elas:

Código: [Selecionar]

Up   o sub_4364B0+40 la      $t0, unk_B429C0
Down o .got:00BB9978 .word unk_B429C0   
Essa sub_4364B0 parece ser uma rotina chave para acessar a tabela. Ainda não analisei ela com calma:

Código: [Selecionar]

.text:004364B0
.text:004364B0
.text:004364B0                         sub_4364B0:                              # CODE XREF: sub_45EBE0+10j
.text:004364B0                                                                  # sub_61A7B0+208p ...
.text:004364B0
.text:004364B0                         var_18          = -0x18
.text:004364B0                         var_10          = -0x10
.text:004364B0                         var_C           = -0xC
.text:004364B0                         var_8           = -8
.text:004364B0
.text:004364B0 79 00 1C 3C 00 98 9C 27                 la      $gp, unk_789800
.text:004364B8 21 E0 99 03                             addu    $gp, $t9
.text:004364BC D8 FF BD 27                             addiu   $sp, -0x28
.text:004364C0 20 00 BF AF                             sw      $ra, 0x28+var_8($sp)
.text:004364C4 1C 00 B1 AF                             sw      $s1, 0x28+var_C($sp)
.text:004364C8 18 00 B0 AF                             sw      $s0, 0x28+var_10($sp)
.text:004364CC 10 00 BC AF                             sw      $gp, 0x28+var_18($sp)
.text:004364D0 A8 98 99 8F                             la      $t9, sub_4A62E0
.text:004364D4 FF FF 91 30                             andi    $s1, $a0, 0xFFFF
.text:004364D8 09 F8 20 03                             jalr    $t9 ; sub_4A62E0
.text:004364DC 21 80 00 00                             move    $s0, $0
.text:004364E0 10 00 BC 8F                             lw      $gp, 0x28+var_18($sp)
.text:004364E4 21 18 40 00                             move    $v1, $v0
.text:004364E8 01 00 02 24                             li      $v0, 1
.text:004364EC 06 00 62 10                             beq     $v1, $v0, loc_436508
.text:004364F0 C8 9C 88 8F                             la      $t0, unk_B429C0
.text:004364F4 02 00 62 28                             slti    $v0, $v1, 2
.text:004364F8 36 00 40 14                             bnez    $v0, loc_4365D4
.text:004364FC 02 00 02 24                             li      $v0, 2
.text:00436500 22 00 62 10                             beq     $v1, $v0, loc_43658C
.text:00436504 00 00 00 00                             nop
.text:00436508
.text:00436508                         loc_436508:                              # CODE XREF: sub_4364B0+3Cj
.text:00436508                                                                  # sub_4364B0:loc_43658Cj ...
.text:00436508 00 13 10 00                             sll     $v0, $s0, 12
.text:0043650C 25 10 51 00                             or      $v0, $s1
.text:00436510 FF FF 50 30                             andi    $s0, $v0, 0xFFFF
.text:00436514 18 00 00 12                             beqz    $s0, loc_436578
.text:00436518 21 10 00 00                             move    $v0, $0
.text:0043651C 02 00 02 91                             lbu     $v0, 2($t0)
.text:00436520 03 00 03 91                             lbu     $v1, 3($t0)
.text:00436524 04 00 04 91                             lbu     $a0, 4($t0)
.text:00436528 00 16 02 00                             sll     $v0, 24
.text:0043652C 00 1C 03 00                             sll     $v1, 16
.text:00436530 05 00 05 91                             lbu     $a1, 5($t0)
.text:00436534 25 10 43 00                             or      $v0, $v1
.text:00436538 00 22 04 00                             sll     $a0, 8
.text:0043653C 25 10 44 00                             or      $v0, $a0
.text:00436540 25 38 45 00                             or      $a3, $v0, $a1
.text:00436544 0B 00 E0 18                             blez    $a3, loc_436574
.text:00436548 21 30 00 00                             move    $a2, $0
.text:0043654C
.text:0043654C                         loc_43654C:                              # CODE XREF: sub_4364B0+BCj
.text:0043654C 21 28 06 01                             addu    $a1, $t0, $a2
.text:00436550 00 00 A2 90                             lbu     $v0, 0($a1)
.text:00436554 01 00 A3 90                             lbu     $v1, 1($a1)
.text:00436558 06 00 C6 24                             addiu   $a2, 6
.text:0043655C 00 12 02 00                             sll     $v0, 8
.text:00436560 25 10 43 00                             or      $v0, $v1
.text:00436564 0B 00 50 10                             beq     $v0, $s0, loc_436594
.text:00436568 2A 20 C7 00                             slt     $a0, $a2, $a3
.text:0043656C F7 FF 80 14                             bnez    $a0, loc_43654C
.text:00436570 00 00 00 00                             nop
.text:00436574
.text:00436574                         loc_436574:                              # CODE XREF: sub_4364B0+94j
.text:00436574 21 10 00 00                             move    $v0, $0
.text:00436578
.text:00436578                         loc_436578:                              # CODE XREF: sub_4364B0+64j
.text:00436578 20 00 BF 8F                             lw      $ra, 0x28+var_8($sp)
.text:0043657C 1C 00 B1 8F                             lw      $s1, 0x28+var_C($sp)
.text:00436580 18 00 B0 8F                             lw      $s0, 0x28+var_10($sp)
.text:00436584 08 00 E0 03                             jr      $ra
.text:00436588 28 00 BD 27                             addiu   $sp, 0x28
.text:0043658C                          # ---------------------------------------------------------------------------
.text:0043658C
.text:0043658C                         loc_43658C:                              # CODE XREF: sub_4364B0+50j
.text:0043658C DE FF 00 10                             b       loc_436508
.text:00436590 04 00 10 24                             li      $s0, 4
.text:00436594                          # ---------------------------------------------------------------------------
.text:00436594
.text:00436594                         loc_436594:                              # CODE XREF: sub_4364B0+B4j
.text:00436594 02 00 A2 90                             lbu     $v0, 2($a1)
.text:00436598 03 00 A3 90                             lbu     $v1, 3($a1)
.text:0043659C 04 00 A4 90                             lbu     $a0, 4($a1)
.text:004365A0 00 16 02 00                             sll     $v0, 24
.text:004365A4 00 1C 03 00                             sll     $v1, 16
.text:004365A8 05 00 A5 90                             lbu     $a1, 5($a1)
.text:004365AC 25 10 43 00                             or      $v0, $v1
.text:004365B0 00 22 04 00                             sll     $a0, 8
.text:004365B4 25 10 44 00                             or      $v0, $a0
.text:004365B8 20 00 BF 8F                             lw      $ra, 0x28+var_8($sp)
.text:004365BC 1C 00 B1 8F                             lw      $s1, 0x28+var_C($sp)
.text:004365C0 18 00 B0 8F                             lw      $s0, 0x28+var_10($sp)
.text:004365C4 25 10 45 00                             or      $v0, $a1
.text:004365C8 21 10 48 00                             addu    $v0, $t0
.text:004365CC 08 00 E0 03                             jr      $ra
.text:004365D0 28 00 BD 27                             addiu   $sp, 0x28
.text:004365D4                          # ---------------------------------------------------------------------------
.text:004365D4
.text:004365D4                         loc_4365D4:                              # CODE XREF: sub_4364B0+48j
.text:004365D4 CC FF 60 14                             bnez    $v1, loc_436508
.text:004365D8 00 00 00 00                             nop
.text:004365DC CA FF 00 10                             b       loc_436508
.text:004365E0 06 00 10 24                             li      $s0, 6
.text:004365E0                          # End of function sub_4364B0
.text:004365E0
Em resumo, pelo que eu entendi, o bloco inteiro poderia ser mudado de lugar.
Se o programinha fosse feito, a tabela (os ponteiros) teriam que ser todos reformados, já que mudar o tamanho de uma única string faria com que os endereços (offsets) das strings seguintes ficassem errados, não é?
O total de strings pra rever/traduzir é: 227H, ou seja, 551!  Tudo bem, se tiver como fazer, eu assumo essa tarefa da revisão/tradução se precisar... 

[zeurt]

Para quem não usa Linux rotineiramente, está com preguiça de usar um Live Linux, ou está com preguiça de compilar o Squashfs tools com LZMA para o Windows, aqui estão os binários já compilados: http://download.nicksoft.info/linux/backuplivecd/squashfs-tools.zip
Créditos para o russo Nikolay Pelov, deste site: http://www.nicksoft.info/

Já testei, e está funcionando perfeitamente: foi possível extrair os binários zmw_base_zinwell à partir dos blocos CODE dos firmwares .zim do ZBT633/601 exportados pelo Zimview (conforme explicados pelo rictad em um de seus posts iniciais deste tópico).

[zeurt]

rictad,
Eu notei que o ZBT-601 não tem Porta Ethernet. Isso não torna a recuperação, após atualização mal sucedida, difícil, ou praticamente impossível com as ferramentas que contamos até o momento?
Afinal, quando estamos no CFE, a única alternativa para gravar os blocos do firmware na flash não é pela rede? Ou eu perdi alguma informação?

[rictad]

Para quem não usa Linux rotineiramente, está com preguiça de usar um Live Linux, ou está com preguiça de compilar o Squashfs tools com LZMA para o Windows, aqui estão os binários já compilados: http://download.nicksoft.info/linux/backuplivecd/squashfs-tools.zip
Créditos para o russo Nikolay Pelov, deste site: http://www.nicksoft.info/

Já testei, e está funcionando perfeitamente: foi possível extrair os binários zmw_base_zinwell à partir dos blocos CODE dos firmwares .zim do ZBT633/601 exportados pelo Zimview (conforme explicados pelo rictad em um de seus posts iniciais deste tópico).

Olá zeurt! Essa compilação do Pelov eu já conhecia, mas tem um problema. O unsquash funciona legal, mas o mksquash dá erro com alguns arquivos. Pelo menos na época eu não consegui de forma alguma refazer o bloco CODE com ela. O próprio Pelov diz que não sabe porque em alguns casos esse erro ocorre. O ryan também chegou a me dizer que usava essa versão. Já no caso específico dele, a criação da imagem ocorre com sucesso.

rictad,
Eu notei que o ZBT-601 não tem Porta Ethernet. Isso não torna a recuperação, após atualização mal sucedida, difícil, ou praticamente impossível com as ferramentas que contamos até o momento?
Afinal, quando estamos no CFE, a única alternativa para gravar os blocos do firmware na flash não é pela rede? Ou eu perdi alguma informação?

Pois é. A única forma de recuperar uma gravação mal sucedida (desde que o CFE ainda esteja funcionando) é pela rede mesmo. O fato de o ZBT-601 não ter porta ethernet realmente gera uma certa preocupação para quem for desenvolver. Mas a ideia é testar antes o zmw_base_zinwell pelo pen drive. Se funcionar, é só gerar o bloco CODE. Depois, pode-se testar também o bloco CODE pelo pen drive, montando-o em algum ponto do sistema de arquivos e chamando o zmw_base_zinwell de dentro. Se funcionar também, é só criar a imagem .zim e gravar na flash. Assim, os riscos de ocorrerem problemas após a gravação na flash são reduzidos ao risco padrão de uma atualização mal sucedida.

[zeurt]

Sobre o limite de 6h de gravação:
Andei pensando bastante sobre esse limite, e acabei chegando a algumas conclusões.
Acho que tem sentido existir um limite de tempo de gravação. Por exemplo, digamos que alguém tenha um HDD de 1TB e resolve gravar um programa (apertar REC). Digamos que essa pessoa esqueça dessa gravação, saia de casa, volte, durma, etc. Se não houvesse o limite, seria criado um arquivos gigantesco, ocupando quase todo o HDD??? Ou será que independente de existir um limite explícito, existe algum outro tipo de limitação máxima "natural" para o tamanho possível desses arquivos?
Me parece que o limite de 6h é meio arbitrário, poderia ser mais, ou menos (ou será que existe alguma lógica nesse valor?).
De qualquer modo, na minha opinião, o ideal não seria eliminar o limite (justamente para manter o "dispositivo de segurança" que descrevi acima). Acho que o melhor seria o usuário poder escolher o limite máximo em horas, ou até mesmo poder escolher, caso queira, eliminar o limite. Para isso, também seria necessário termos acesso a estrutura do menu, etc.
Se o usuário pudesse escolher o limite máximo de gravação, estariamos criando indiretamente uma função OTR (One Touch Recording) adaptada. Explico: digamos que se queira gravar as próximas 3 horas de um determinado canal. Seria só ir ao menu e determinar o limite máximo de gravação em 3 horas. Daí, era só pressionar REC (não é tão One Touch, mas é quase... )
Caso não conseguirmos mesmo ter acesso a estrutura do menu, se eu pudesse escolher, eu manteria um certo limite máximo (12 horas??). Ou atá mesmo criar 2 versões de firmware, atendendo a todos os gostos... 

Estrurura de dados do Firmware:
Nos últimos dias, eu tenho estudado a parte de Pure Data do firmware (a parte .data no IDA). Descobri bastante coisa interessante. Falta MUITA coisa ainda, é claro. Mas já é um começo, já dar pra visualizar o "esqueleto" principal da estrutura de dados. Inclusive, acho que encontrei o provável local das fontes (posso estar enganado, mas evidências iniciais indicam isso).
Estou com o rascunho aqui, e após aprimorar um pouco mais essa versão preliminar ALFA, eu postarei esses achados iniciais...

[rictad]

Sobre o limite de 6h de gravação:
Andei pensando bastante sobre esse limite, e acabei chegando a algumas conclusões.
Acho que tem sentido existir um limite de tempo de gravação. Por exemplo, digamos que alguém tenha um HDD de 1TB e resolve gravar um programa (apertar REC). Digamos que essa pessoa esqueça dessa gravação, saia de casa, volte, durma, etc. Se não houvesse o limite, seria criado um arquivos gigantesco, ocupando quase todo o HDD??? Ou será que independente de existir um limite explícito, existe algum outro tipo de limitação máxima "natural" para o tamanho possível desses arquivos?
Me parece que o limite de 6h é meio arbitrário, poderia ser mais, ou menos (ou será que existe alguma lógica nesse valor?).
De qualquer modo, na minha opinião, o ideal não seria eliminar o limite (justamente para manter o "dispositivo de segurança" que descrevi acima). Acho que o melhor seria o usuário poder escolher o limite máximo em horas, ou até mesmo poder escolher, quase queira, eliminar o limite. Para isso, também seria necessário termos acesso a estrutura do menu, etc.
Se o usuário pudesse escolher o limite máximo de gravação, estariamos criando indiretamente uma função OTR (One Touch Recording) adaptada. Explico: digamos que se queira gravar as próximas 3 horas de um determinado canal. Seria só ir ao menu e determinar o limite máximo de gravação em 3 horas. Daí, era só pressionar REC (não é tão One Touch, mas é quase... )
Caso não conseguirmos mesmo ter acesso a estrutura do menu, se eu pudesse escolher, eu manteria um certo limite máximo (12 horas??). Ou atá mesmo criar 2 versões de firmware, atendendo a todos os gostos... 

Se a pessoa usa um HD pré-formatado com FAT32, a gravação será quebrada em vários arquivos (pois FAT32 suporta arquivos até 4GB). Então, neste caso, acho que não haverá problemas. Sem o limite de tempo, a gravação deve acabar quando o HD encher. Eu acho, pois depois que tirei o limite do tamanho mínimo do HD, eu não tentei gravar até encher um disco. Um bom teste seria criar uma partição de 1GB e testar o PVR nela até acabar o espaço para ver o comportamento do aparelho.

Já a formatação própria usa o seguinte comando: "mke2fs -j -i 8388608 -J size=4 -m 0 -O sparse_super /dev/sdaX", em que X é o número da primeira partição válida encontrada. Ele cria um sistema de arquivos ext3 (ext2 + journal) sem definir explicitamente o tamanho do bloco. Este é calculado heuristicamente considerando-se o tamanho total do sistema de arquivos. Se o HD for de 1TB, ele deve usar um bloco de 4KB, o que permitiria 1 arquivo de até 2TB (claro, limitado pelo tamanho do disco a 1TB). Então, neste caso, podemos ter um super arquivo que pode atrapalhar a manipulação. E também não sabemos qual o comportamento no momento em que o disco acabar. Precisamos fazer testes, mas acho que 24 horas para o tempo máximo de gravação contínua é suficiente.

Estrurura de dados do Firmware:
Nos últimos dias, eu tenho estudado a parte de Pure Data do firmware (a parte .data no IDA). Descobri bastante coisa interessante. Falta MUITA coisa ainda, é claro. Mas já é um começo, já dar pra visualizar o "esqueleto" principal da estrutura de dados. Inclusive, acho que encontrei o provável local das fontes (posso estar enganado, mas evidências iniciais indicam isso).
Estou com o rascunho aqui, e após aprimorar um pouco mais essa versão preliminar ALFA, eu postarei esses achados iniciais...

Boa notícia! Estamos aguardando.

[rictad]

Olhando no IDA agora, acho que descobri onde está o limitador de 6 horas contínuas de gravação. Se estiver certo, pode ser alterado para mais horas ou retirado. Mas só poderei testar quando meu 601 chegar, pois por enquanto estou sem nenhum STB Zinwell aqui. Se funcionar, postarei os detalhes.

[zeurt]

Oi rictad,

Será que você poderia disponibilizar as versões do zmw_base_zinwell que você obteve pelo método alternativo (aquelas que não dá pra extrair pelo Unsquashfs). Por exemplo: as versões do "tijolão", e se você tiver alguma aí também do Semp e/ou do Aiko seria muito bom (aliás, desses 2 últimos, tem como extrair pelo Unsquashfs, ou também não?).

Quanto mais zmw_base_zinwell, dos mais variados modelos, das mais variadas versões, eu puder ver (e comparar), melhor vai poder ser a minha análise da estrutura de dados do firmware. Eu tenho todos os zmw_base_zinwell dos ZBT-601/633 que extrai dos .zim do site da Ivision (5 até agora). O problema é que a estrutura de dados deles é tão parecida que a comparação entre eles acaba não ajudando tanto... Tenho a esperança que a comparação com as outras versões que eu ainda não tenho possa ser mais frutífera... Obrigado!

[rictad]

Oi rictad,

Será que você poderia disponibilizar as versões do zmw_base_zinwell que você obteve pelo método alternativo (aquelas que não dá pra extrair pelo Unsquashfs). Por exemplo: as versões do "tijolão", e se você tiver alguma aí também do Semp e/ou do Aiko seria muito bom (aliás, desses 2 últimos, tem como extrair pelo Unsquashfs, ou também não?).

Quanto mais zmw_base_zinwell, dos mais variados modelos, das mais variadas versões, eu puder ver (e comparar), melhor vai poder ser a minha análise da estrutura de dados do firmware. Eu tenho todos os zmw_base_zinwell dos ZBT-601/633 que extrai dos .zim do site da Ivision (5 até agora). O problema é que a estrutura de dados deles é tão parecida que a comparação entre eles acaba não ajudando tanto... Tenho a esperança que a comparação com as outras versões que eu ainda não tenho possa ser mais frutífera... Obrigado!

Beleza! Os zmw_base_zinwell que tenho e que foram extraídos pelo método alternativo são os das versões 1.7.2 do ZBT-620A e do ZBT-633, além do da versão 1.0.14c do SEMP. Este último foi-me enviado pelo rafael_netto. Seguem os três em anexo.

Não cheguei a extrair os binários das versões 1.5.5, mas devem ter uma estrutura bem semelhante à das versões 1.7.2. Também não extraí o do Aiko quando testei.

Como você relatou, as versões mais novas (1.13.x, 1.14.x e 1.15.x) do site da Ivison, bem como as modificadas aqui no fórum, são compatíveis com o unsquashfs 3.1. Para outras pessoas que também precisarem, as versões oficiais para o ZBT-601 e ZBT-633 podem ser encontradas aqui. A versão 1.11.6 do ZBT-601 parece ser do tipo que necessita do método alternativo. Como eu estou mexendo no 601, deverei extrair o zmw_base_zinwell dessa versão também.

[zeurt]

Obrigado, rictad! 

[zeurt]

Oi gente,

Estou demorando para divulgar os meus achados sobre a estrutura de dados do firmware porque a cada dia surgem novas questões, novas decobertas, etc. Aí eu acabo me envolvendo nesses "quebra-cabeças", e também acabo adiando os relatos, pensando em trazer algo já mais completo...

De qualquer modo, resolvi deixar aqui um "aperitivo" sobre o que eu estou preparando...
Mostro abaixo algumas telas de background que eu localizei no firmware do ZBT-601 v.1.15.4, extraí, e converti para bitmaps tradicionais. É interessante notar que no firmware do Zinwell existem telas de background/logotipos da Telesystem, Zirok, LBSat, Aiko, e Cromus. E por sinal, são todos muito feinhos, hein...  Sorte que aparentemente não será difícil trocar tudo isso por algo melhor...
Mostro também como aparece um bitmap na parte de dados do firmware. No exemplo, mostro um icone de uma seta para esquerda. Cada pixel é representado por uma palavra de 2 bytes, sendo que o padrão de cores utilizado é o RGB 5-6-5 de 16 bits.

[rictad]

Oi gente,

Estou demorando para divulgar os meus achados sobre a estrutura de dados do firmware porque a cada dia surgem novas questões, novas decobertas, etc. Aí eu acabo me envolvendo nesses "quebra-cabeças", e também acabo adiando os relatos, pensando em trazer algo já mais completo...

De qualquer modo, resolvi deixar aqui um "aperitivo" sobre o que eu estou preparando...
Mostro abaixo algumas telas de background que eu localizei no firmware do ZBT-601 v.1.15.4, extraí, e converti para bitmaps tradicionais. É interessante notar que no firmware do Zinwell existem telas de background/logotipos da Telesystem, Zirok, LBSat, Aiko, e Cromus. E por sinal, são todos muito feinhos, hein...  Sorte que aparentemente não será difícil trocar tudo isso por algo melhor...
Mostro também como aparece um bitmap na parte de dados do firmware. No exemplo, mostro um icone de uma seta para esquerda. Cada pixel é representado por uma palavra de 2 bytes, sendo que o padrão de cores utilizado é o RGB 5-6-5 de 16 bits.

Boa, zeurt! 

Eu estava pensando em remover o logo, pois a exibição dele faz a inicialização demorar um pouco. Já havia começado a identificar a rotina responsável. Mas agora haverá a possibilidade de personalização para o usuário. 


Bom, o meu ZBT-601 chegou e eu pude confirmar que o firmware do ZBT-601 é praticamente o mesmo firmware do ZBT-633 tornando-os compatíveis, considerando que os aparelhos utilizam o mesmo controle remoto. Eu instalei o firmware original 1.14.7 da Ivison do ZBT-633 no ZBT-601 e o aparelho funcionou normalmente, com exceção do painel frontal. Os blocos LOAD, ROOT e KERNEL são idênticos. As poucas diferenças estão no bloco CODE, mais especificamente no arquivo zmw_base_zinwell.

O que não permite instalar os firmwares trocados de forma imediata é o customer number: 6 (0x0006) para o ZBT-601 e 262 (0x0106) para o ZBT-633. Mas com o ZimView é possível alterar o customer number, o que permite intercâmbio de firmwares entre o ZBT-633 e o ZBT-601. Para voltar ao firmware correto do aparelho, o CN deste deve ser alterado também, já que o zmw_base_zinwell irá procurar pelo CN do aparelho a que ele corresponde. Lembrando apenas que isso não deve ser feito com o firmware original do ZBT-620A "tijolão" que, apesar de também possuir o customer number 262, tem um controle remoto incompatível com os ZBT-601 e ZBT-633.

Assim, continuarei trabalhando com o firmware 1.14.4 beta, agora também com uma versão adaptada para o ZBT-601, que inicializa corretamente o painel frontal daquele aparelho. A versão oficial 1.15.4 do ZBT-601 parece não possuir nenhuma grande diferença em relação à 1.14.7 do ZBT-633. Além disso, eu notei que a mesma possui um pequeno bug que liga o closed caption após um pendrive ficar alguns minutos conectado: aparece a informação de que o USB foi desconectado seguida da informação de que o mesmo foi conectado e o CC liga.

A rotina que inicializa o painel frontal do ZBT-601 é a seguinte:

Código: [Selecionar]

.text:004DB904                          # executa frontpanel init do ZBT-601
.text:004DB904
.text:004DB904                         sub_4DB904:
.text:004DB904
.text:004DB904                         var_18          = -0x18
.text:004DB904                         var_14          = -0x14
.text:004DB904                         var_10          = -0x10
.text:004DB904                         var_8           = -8
.text:004DB904                         var_4           = -4
.text:004DB904
.text:004DB904 6E 00 1C 3C AC 43 9C 27                 la      $gp, unk_6E43AC
.text:004DB90C 21 E0 99 03                             addu    $gp, $t9
.text:004DB910 D8 FF BD 27                             addiu   $sp, -0x28
.text:004DB914 24 00 BF AF                             sw      $ra, 0x28+var_4($sp)
.text:004DB918 20 00 B0 AF                             sw      $s0, 0x28+var_8($sp)
.text:004DB91C 18 00 BC AF                             sw      $gp, 0x28+var_10($sp)
.text:004DB920 AC 80 90 8F                             la      $s0, unk_D50000
.text:004DB924 34 80 85 8F                             la      $a1, aWarningUnknown
.text:004DB928 98 8B 99 8F                             la      $t9, sub_451D98
.text:004DB92C D0 D7 04 26                             addiu   $a0, $s0, (unk_D4D7D0 - 0xD50000)
.text:004DB930 09 F8 20 03                             jalr    $t9 ; sub_451D98
.text:004DB934 20 DB A5 24                             addiu   $a1, (a7401uarta_0 - 0x690000)  # "7401UARTA"
.text:004DB938 18 00 BC 8F                             lw      $gp, 0x28+var_10($sp)
(...)
(...)
(...)
.text:004DBA6C
.text:004DBA6C                         loc_4DBA6C:                              # CODE XREF: sub_4DB904+150_j
.text:004DBA6C 24 00 BF 8F                             lw      $ra, 0x28+var_4($sp)
.text:004DBA70 20 00 B0 8F                             lw      $s0, 0x28+var_8($sp)
.text:004DBA74 08 00 20 03                             jr      $t9
.text:004DBA78 28 00 BD 27                             addiu   $sp, 0x28
.text:004DBA78                          # End of function sub_4DB904

Assim como a "executa 8051 fp init" do ZBT-620A, ela também depende e é chamada pela rotina "pré-executa fp init". Portanto, a versão 1.14.4 beta para o ZBT-601, à qual eu denominei 1.14.4b beta, foi criada a partir da versão 1.14.4a beta do ZBT-620A aqui do tópico, bastando apenas alterar 1 apontamento na GOT (endereço da rotina "executa 8051 fp init" para o endereço da "executa frontpanel init do ZBT-601" acima).

Além disso, para manter o customer number do ZBT-601, garantindo a compatibilidade com futuras versões de firmware para o aparelho, tive que achar a rotina que verifica o CN e modificá-la. A rotina é a sub_49E880 e o trecho alterado é o seguinte:

Código: [Selecionar]

.text:0049E910 09 F8 20 03                             jalr    $t9
.text:0049E914 21 20 40 02                             move    $a0, $s2
.text:0049E918 21 28 40 00                             move    $a1, $v0
.text:0049E91C 01 06 02 24                             li      $v0, 0x601       # 601 = 0x106 = 262 no ZimView (customer number)
.text:0049E91C                                                                  # alterar para 0x600 = 0x006 = 6 no ZimView
.text:0049E920 1A 00 A2 10                             beq     $a1, $v0, loc_49E98C
.text:0049E924 10 00 BC 8F                             lw      $gp, 0x40+var_30($sp)
.text:0049E928 34 80 84 8F                             la      $a0, aWarningUnknown  # "Warning: unknown JFIF revision number %"...
.text:0049E92C 30 8A 99 8F                             la      $t9, sub_666260
.text:0049E930 01 06 06 24                             li      $a2, 0x601
.text:0049E934 09 F8 20 03                             jalr    $t9 ; sub_666260
.text:0049E938 98 82 84 24                             addiu   $a0, (aIncorrectSWCus - 0x690000)  # "Incorrect S/W customer code from USB S/"...

Parece que o valor mostrado no ZimView não considera que o código é little-endian. 

[rictad]

Consegui retirar a limitação de 6 horas contínuas para a gravação. Para o agendamento, o limite ficou em 23 horas e 59 minutos devido à forma de como o mesmo é feito: na tela de agendamento não é possível escolher a data do fim das gravações mas apenas a data e hora do início, a hora final, o canal a ser gravado e o modo (diário, semanal, uma vez etc).

Esse forma mais simples é bem interessante. A data final é calculada automaticamente, sendo no mesmo dia, caso a diferença entre as horas final e inicial forem positivas ou em d+1 caso a diferença seja negativa. Assim, por exemplo, se programarmos o início de uma gravação no dia d, hora 13:00 e o término para as 12:59, a data final será em d+1, totalizando 23 horas e 59 minutos. Se a hora final for igual (13:00, no caso do exemplo) ele não aceita, pois considera que há sobreposição de gravação. Esse cálculo já era feito anteriormente, mas limitado a 6 horas. Mais que isso havia o aviso de "hora incorreta informada".

Já para o OTR a ideia foi deixar o limite em 24 horas, para ficar compatível com o limite do agendamento e evitar um arquivo gigante. Como teste, cheguei a fazer duas gravações, uma de aproximadamente de 8 horas e meia e outra de um pouco mais de 10 horas. A primeira foi com OTR e a segunda com agendamento.

Bug

Há um bug no firmware original o qual não consegui retirar e que atrapalha agendamentos superiores a 6 horas. Como explicado, quando se tentava agendar uma gravação com horário de término inferior ao horário inicial, a data de término passava a ser o dia seguinte, desde que não fosse superior a 6 horas. Exemplo: inicio às 22:00 e término às 4:00 era aceito (6 horas de gravação). Já início às 22:00 e término às 21:00 não era aceito, pois totalizaria 23 horas de gravação. Porém, ao se tentar agendar um início na faixa da 0 hora (0:00 a 0:59) e um final em horário anterior, mas na mesma faixa da 0 hora, o aparelho, além de aceitar o agendamento, não atualizava a data em d+1. Exemplo: início 20 de abril à 0:15 e término à 0:10 ele aceitava e colocava a data de término como no próprio dia 20 de abril. Nunca tentei gravar assim e não sei o que acontece. Agora, sem o limite de 6 horas, esse tipo de agendamento continua passando. Por enquanto, a sugestão para quem for fazer uma gravação longa de madrugada é não começar na faixa da 0 hora ou, se começar, terminar no máximo na faixa das 23 horas, a não ser que a diferença seja positiva.

Um pequeno resumo sobre a gravação

Como se sabe, o horário de agendamento segue a informação das emissoras, já que o aparelho não possui timer. A gravação é feita em arquivo único quando o disco está em ext3 ou dividida em arquivos de 3,9GB quando o disco está em FAT32, nomeados com a data e a hora inicial da gravação. Neste último caso, a reprodução do aparelho agrupa os arquivos de forma transparente ao usuário, como se fossem apenas uma gravação.

Durante a reprodução, a navegação pode ser agilizada com o uso das teclas numéricas: o tempo de gravação é dividido em 10 partes iguais e podemos saltar diretamente para cada parte pressionando as teclas de 0 a 9 no controle. Isso funciona bem quando o arquivo é único (ext3). Mas quando estamos em FAT32, gera um certo inconveniente. Cada arquivo de 3,9GB é dividido em 10 partes. Então você só pode saltar entre as partes do arquivo atual.

Nos testes que eu fiz, gravando a Globo HD, no limite de 6 horas foram gerados 10 arquivos, totalizando 39GB. Cada arquivo ficou com 36 minutos, divididos em 10 partes de aproximadamente 3 minutos e 40 segundos (3,6 minutos). Assim, se quisesse saltar para o final da gravação mais rapidamente, teria que apertar  a tecla 9 para ir ao final do primeiro bloco (arquivo), selecionar avanço rápido (32x) e esperar ele passar ao próximo bloco. Ao chegar ao próximo bloco, selecionar avanço normal e apertar 9 novamente para ir ao final do segundo bloco e repetir a operação. Enfim, intercalando saltos de 32,4 minutos com correrias de 3,6 minutos. Quando a gravação for muito grande (por exemplo, 24 horas), isso será muito trabalhoso. Mas acho que o único motivo para se fazer uma gravação tão grande em FAT32 será para se tentar alguma edição posterior no PC. Ainda assim, uma forma de facilitar a exibição de uma gravação grande em FAT32 seria alterar os arquivos textos gerados que agrupam a gravação. Pode-se facilmente dividir uma gravação de 12 horas, com 20 arquivos, em 4 gravações de 3 horas, com 5 arquivos cada. Isso não é difícil, mas é necessário olhar os arquivos para se familiarizar e deduzir como é feito. Existe um arquivo .link com a listagem dos blocos, de mesmo nome do primeiro bloco e um arquivo .info contendo apenas o nome do primeiro bloco e também de mesmo nome deste. No exemplo citado, bastaria criar 4 arquivos .link (com 5 blocos cada) e 4 arquivos .info apontando para o bloco que inicia cada uma das novas "seções" criadas manualmente.

Por outro lado, no formato ext3 próprio do aparelho, também podemos ter problemas com gravações muito grandes. Apesar de facilitar a reprodução, já que temos apenas um arquivo para navegar, quanto maior o arquivo, maior o tamanho dos saltos. Em uma gravação de 24 horas teremos 10 partes de 1 hora e 40 minutos cada.

Modificações

Procurei por referências a string que o zeurt havia indicado ("pvr: stream has recode 6hrs") em uma rotina que fazia referências a outras strings relacionadas ao PVR. A rotina é a sub_4BD51C e encontrei as referências nos seguintes pontos, já que o valor de $s5 era 0x690000:

Código: [Selecionar]

.text:004BD814 58 B0 A4 26                             addiu   $a0, $s5, -0x4FA8  # string pvr maximo 6 horas

Código: [Selecionar]

.text:004BD994 58 B0 A4 26                             addiu   $a0, $s5, -0x4FA8  # string pvr maximo 6 horas
Verificando a rotina, há dois pontos em que o cálculo é feito:

Código: [Selecionar]

.text:004BD7B8 49 01 02 3C                             lui     $v0, 0x149       # calculo das 6 horas #1490000 or #9700 =  #1499700
.text:004BD7BC 00 97 54 34                             ori     $s4, $v0, 0x9700


Código: [Selecionar]

.text:004BD94C 49 01 02 3C                             lui     $v0, 0x149       # calculo das 6 horas #1490000 or #9700 =  #1499700
.text:004BD950 00 97 54 34                             ori     $s4, $v0, 0x9700

Deduzi que esses seriam os pontos pois 0x1499700 dividido por 3600 (3600 segundos), depois por 10 e transformado em decimal dá 600 (isso parece BCD para 6 horas, 0 minutos e 0 segundos).

Além desses pontos, existem ainda mais um em outra rotina:

Código: [Selecionar]

.text:004BA72C 49 01 02 3C                             lui     $v0, 0x149       # calculo das 6 horas #1490000 or #9700 =  #1499700
.text:004BA730 00 97 54 34                             ori     $s4, $v0, 0x9700

E uma palavra em:

Código: [Selecionar]

.rodata:0068B490 00 97 49 01             dword_68B490:   .word 0x1499700          # DATA XREF: sub_4BEA88+428_o
.rodata:0068B490                                                                  # sub_4BEA88+430_r ...
.rodata:0068B490                                                                  # limite 6 horas

Essa palavra é referenciada por uma rotina que também está relacionada ao PVR.

Alterar esses valores não permitiu agendamentos superiores a 6 horas. Isso porque essas rotinas apenas verificam se o a gravação atingiu o tempo máximo (e a interrompem). A rotina responsável pelo agendamento e os critérios de aceitação é a sub_4D4C48. Um trecho chamou a atenção:

Código: [Selecionar]

addiu   $v0, $v1, (byte_68D380 - 0x690000)  # 6 horas no agendamento pvr
lbu     $a0, (byte_68D380 - 0x690000)($v1)  # carrega byte 6. 6 horas
lbu     $a2, 2($v0)
lbu     $a1, 1($v0)

Esse trecho carrega em $a0, $a1 e $a2 os valores 0x6, 0 e 0 (bytes que estão a partir de 0x68D380), respectivamente. Isso é BCD, pois somente foi aceito o agendamento de até 23 horas e 59 minutos após eu mudar para 0x24, 0 e 0, respectivamente (ao colocar 0x18, que é 24 em hexadecimal, o limite de horas passou a ser 18 e não 24, o que evidenciou se tratar de BCD). Isso foi mais um indício de que o valor achado anteriormente, 0x1499700, também estava relacionado ao limite.

Ao apenas mudar esse ponto, o agendamento superior a 6 horas passou a ser permitido, mas a gravação ainda era interrompida após completar 6 horas. Então, mudando as 4 ocorrências do valor 0x1499700 apontadas anteriormente para o seu quádruplo (0x5265C00) finalmente foi permitido gravar mais que 6 horas.

A dúvida ainda é saber se a mudança daquele valor para o quádruplo realmente limita a gravação em 24 horas. Pode ser que deixe passar, se o cálculo não for tão simples. No caso do agendamento, isso não tem problema, pois a agenda será seguida (eu testei até 10 horas e pouco) e a gravação será limitada a 23 horas e 59 minutos. Já no caso do OTR eu não tive paciência para testar (interrompi com 8 horas e meia). Então, quando disponibilizar o firmware, fica a sugestão para testes.

Eu imagino que o bug da 0 hora esteja na rotina sub_460178, chamada pela que faz o agendamento. Ela é quem recebe os valores e parece fazer os cálculos das diferenças entre os horários. Ainda não tentei entendê-la, mas qualquer mudança nela deverá ser feita com cuidado, já que é chamada por diversas outras rotinas.

[rictad]

Firmware Rictad versão 1.14.4 beta 2

• Tempo contínuo de gravação por agendamento aumentado para 23 horas e 59 minutos;
• Tempo contínuo de gravação OTR aumentado para 24 horas (ainda não testado completamente);
• Correção de algumas traduções de mensagens exibidas na tela;
• Disponibilizada uma versão para o ZBT-601.

ATENÇÃO:

Por questão de segurança, assim como ocorre com a versão 1.13.6, só atualize para as versões 1.14.4, inclusive a oficial da Ivision, se o aparelho estiver, no mínimo, com a versão 1.5.5. Caso a versão seja inferior a essa, como a 1.3.7 ou a 1.3.8, você deve atualizar primeiro para as versões 1.5.5 ou 1.7.2 que estão disponíveis na Internet, de acordo com o modelo do seu aparelho.

A versão 1.14.4a beta 2 deve ser preferencialmente instalada no Zinwell ZBT-620A "tijolão", de controle grande e prateado. Mas se você instalar no aparelho errado, ainda poderá atualizar com a versão correta depois.
Após a atualização, você não poderá instalar as versões antigas 1.7.2 e 1.5.5 oficiais. Caso isso seja necessário, você só poderá "desatualizar" se utilizar a versão ZBT-620A_1.7.2_back2 especial disponibilizada no tópico.

A versão 1.14.4b beta 2 deve ser preferencialmente instalada no Zinwell ZBT-601. Mas se você instalar no aparelho errado, ainda poderá atualizar com a versão correta depois.
EDIT 30/04/2011: Após o relato abaixo do usuário PedroAcerbi e alguns testes, foi verificado que essa versão só deve ser instalada se a versão atual do ZBT-601 for a 1.11.6 ou a 1.15.4. Caso seja alguma versão 1.14.X, o aparelho deverá ser atualizado antes para a versão 1.15.4 oficial, ou haverá o grande risco de não mais inicializar, sendo recuperável apenas via cabo.
Após a atualização, você poderá voltar para as versões oficiais 1.14.1, 1.14.3, 1.14.4, 1.14.5 e 1.15.4 disponibilizadas no site da Ivision. E assim como ocorre quando se atualiza com as versões oficiais, você não poderá voltar para a versão mais antiga (1.11.6).

A versão 1.14.4c beta 2 deve ser preferencialmente instalada no Zinwell ZBT-620C/633 slim, de controle Zinwell menor e preto. Mas se você instalar no aparelho errado, ainda poderá atualizar com a versão correta depois. Após a atualização, você poderá voltar para as versões oficiais 1.13.6, 1.14.4 e 1.14.7 disponibilizadas no site da Ivision. E assim como ocorre quando se atualiza com as versões oficiais, você não poderá voltar para as versões mais antigas (1.7.2 e 1.5.5). Caso isso seja necessário, você só poderá "desatualizar" se utilizar a versão ZBT-633_1.7.2_back2 especial disponibilizada no tópico.

Quando você atualizar para a versão 1.14.4 beta 2, serão gravados 4 blocos na flash. Então você deverá esperar a barra de gravação encher 4 vezes! Após a atualização, caso o STB já não esteja atualizado com a versão 1.14.4 oficial, o mesmo será reiniciado 2 vezes, a primeira é para apagar a EPROM.

[zeurt]

Verificando a rotina, há dois pontos em que o cálculo é feito:

Código: [Selecionar]

.text:004BD7B8 49 01 02 3C                             lui     $v0, 0x149       # calculo das 6 horas #1490000 or #9700 =  #1499700
.text:004BD7BC 00 97 54 34                             ori     $s4, $v0, 0x9700


Código: [Selecionar]

.text:004BD94C 49 01 02 3C                             lui     $v0, 0x149       # calculo das 6 horas #1490000 or #9700 =  #1499700
.text:004BD950 00 97 54 34                             ori     $s4, $v0, 0x9700

Deduzi que esses seriam os pontos pois 0x1499700 dividido por 3600 (3600 segundos), depois por 10 e transformado em decimal dá 600 (isso parece BCD para 6 horas, 0 minutos e 0 segundos).

Genial, rictad! 
Dá gosto poder acompanhar as suas descobertas!
Quanto ao número 1499700, ele não poderia ser ao invés de BCD, simplesmente o tempo de gravação em milisegundos? Isso porque 1499700h milisegundos / 3600000 = 6 horas (em decimal). Ou será que o aparelho não opera em milisegundos?
Eu entendo que aquele outro trecho parece mesmo BCD, carregando 6, depois 0, e depois 0, mas talvez o primeiro trecho (do numero 1499700) não seja.
Em resumo, o tempo de agendamento poderia ser aramazenado em BCD, enquanto o tempo de gravação poderia ser armazenado em milisegundos, em uma palavra de 4 bytes em hexadecimal. Daí o tempo máximo possível de gravação seria FFFFFFFF milisegundos, aproximadamente 1193 horas... 
Falando nisso, você testou colocar outros valores nesses  6, 0 e 0 para ver o que acontecia? Tipo 0, 15 e 0 para ver se limitava em 15 minutos? Me desculpe por esses preciosismos meio sem finalidade... É que fiquei viajando nesses números...  No fim essas minhas curiosidades não levam praticamente a lugar nenhum já que o problema principal já foi mais que resolvido! 

Já chegou o meu ZBT-601 (na verdade vai ficar com a minha mãe  ). Testei rapidamente o FW original v 1.11.6, e logo atualizei com a sua última versão. Estou com escassez de HDDs aqui (tenho 2 de 500GB, mas cheios e formatados em NTFS). Um deles tinha uma segunda partição de 16GB em FAT32. Tentei fazer uma gravação com ele: gravou, mas sempre que eu tentava acessar os arquivos do HDD (para poder ver a gravação, ou fotos e musica) o aparelho travava: tinha que pressionar power para fazer o reboot. Já li uns relatos de que um HDD com partições NTFS e FAT32 ou ext3 teria problemas com o aparelho. Isso confere?
P.S.: Eu também testei formatar a segunda partição em ext3, mas os resultados foram os mesmos: travava ao acessar o menu de arquivos. Depois, só pra confirmar, eu atualizei com o FW oficial 1.15.4: também não funcionava, só que ao invés de travar, ele fazia um reboot automático (tanto com FAT32 como com ext3). Daí, eu aumentei a partição para 40GB, para tentar gravar alguma coisa: ele não permitia gravar, alegando a ausencia de partição de pelo menos 32GB válida (mesmo com a partição de 40GB lá! É estranho porque com o seu FW pelo menos a gravação era permitida, só havendo problema no acesso à mesma). Será que o problema seria a ordem das partições? Ou seja, a primeira partição valida teria que ser a ext3 ou FAT32, e como a minha era NTFS não funcionava... Será isso? Falando nisso tem como trocar a ordem das partições? Eu usei o GParted num Live Linux pra manipular e formatar as partições.
Só sei que depois (de volta ao seu FW) fiz um teste de gravação com um pendrive "meia-boca" de 4GB, formatado em FAT32, e funcionou perfeitamente: nem pude verificar travamentos ou qualquer outro problema... Acho que dei sorte...

Quanto ao seu projeto do Mini Modo de Desenvolvimento, me tira uma dúvida: com ele seria possível "testar" os zmw_base_zinwell no pendrive, mesmo sem o cabo e o PC?

[rictad]

Quanto ao número 1499700, ele não poderia ser ao invés de BCD, simplesmente o tempo de gravação em milisegundos? Isso porque 1499700h milisegundos / 3600000 = 6 horas (em decimal). Ou será que o aparelho não opera em milisegundos?
Eu entendo que aquele outro trecho parece mesmo BCD, carregando 6, depois 0, e depois 0, mas talvez o primeiro trecho (do numero 1499700) não seja.
Em resumo, o tempo de agendamento poderia ser aramazenado em BCD, enquanto o tempo de gravação poderia ser armazenado em milisegundos, em uma palavra de 4 bytes em hexadecimal. Daí o tempo máximo possível de gravação seria FFFFFFFF milisegundos, aproximadamente 1193 horas... 

Olá zeurt. Deve ser em milisegundos mesmo. Como quadripliquei o valor, então o limite deve ter ficado corretamente em 24 horas. A não ser que não seja milisegundos. 

Falando nisso, você testou colocar outros valores nesses  6, 0 e 0 para ver o que acontecia? Tipo 0, 15 e 0 para ver se limitava em 15 minutos? Me desculpe por esses preciosismos meio sem finalidade... É que fiquei viajando nesses números...  No fim essas minhas curiosidades não levam praticamente a lugar nenhum já que o problema principal já foi mais que resolvido! 

Não cheguei a mexer no que talvez sejam os minutos ou segundos por preguiça. Mas também fiquei curioso.

Já chegou o meu ZBT-601 (na verdade vai ficar com a minha mãe  ). Testei rapidamente o FW original v 1.11.6, e logo atualizei com a sua última versão. Estou com escassez de HDDs aqui (tenho 2 de 500GB, mas cheios e formatados em NTFS). Um deles tinha uma segunda partição de 16GB em FAT32. Tentei fazer uma gravação com ele: gravou, mas sempre que eu tentava acessar os arquivos do HDD (para poder ver a gravação, ou fotos e musica) o aparelho travava: tinha que pressionar power para fazer o reboot. Já li uns relatos de que um HDD com partições NTFS e FAT32 ou ext3 teria problemas com o aparelho. Isso confere?
P.S.: Eu também testei formatar a segunda partição em ext3, mas os resultados foram os mesmos: travava ao acessar o menu de arquivos. Depois, só pra confirmar, eu atualizei com o FW oficial 1.15.4: também não funcionava, só que ao invés de travar, ele fazia um reboot automático (tanto com FAT32 como com ext3). Daí, eu aumentei a partição para 40GB, para tentar gravar alguma coisa: ele não permitia gravar, alegando a ausencia de partição de pelo menos 32GB válida (mesmo com a partição de 40GB lá! É estranho porque com o seu FW pelo menos a gravação era permitida, só havendo problema no acesso à mesma). Será que o problema seria a ordem das partições? Ou seja, a primeira partição valida teria que ser a ext3 ou FAT32, e como a minha era NTFS não funcionava... Será isso? Falando nisso tem como trocar a ordem das partições? Eu usei o GParted num Live Linux pra manipular e formatar as partições.
Só sei que depois (de volta ao seu FW) fiz um teste de gravação com um pendrive "meia-boca" de 4GB, formatado em FAT32, e funcionou perfeitamente: nem pude verificar travamentos ou qualquer outro problema... Acho que dei sorte...

Com o STB, nunca trabalhei em um HD que tenha uma partição NTFS. Pelo que notei, a primeira partição montada (no ponto /mnt/usb) é a primeira partição reconhecida (FAT32 ou ext2/3). A segunda reconhecida fica montada em /mnt/usb1 e por aí vai. Para gravar, ele não pergunta a partição (é sempre em /mnt/usb). Já para reproduzir, ele pede que seleciona a partição. Mas não vejo porque uma partição NTFS não montada poderia dar problemas. Mas é possível. Tem que testar sem a NTFS para ver.

Não dá para trocar a ordem das partições. Só se você mover a partição NTFS para o final e criar a nova partição no espaço inicial. Mas esse processo é arriscado e pode ser bem lento.

Quanto ao seu projeto do Mini Modo de Desenvolvimento, me tira uma dúvida: com ele seria possível "testar" os zmw_base_zinwell no pendrive, mesmo sem o cabo e o PC?

Criei um script inicial que verifica se há um zmw_base_zinwell numa determinada pasta na primeira partição do pendrive. Se ele achar o binário, ele o executa, mas antes dá um kill no processo zmw_base_zinwell atual que está rodando. Isso também é possível de se fazer manualmente, com o cabo. O problema é que ainda tem uma pequena falha que preciso consertar (estava funcionando, mas eu modifiquei para testar uma coisa e parou de funcionar). Mas como estou apenas com ZBT-601, deixei de trabalhar nisso, pois é preciso modificar o bloco ROOT e, caso dê algum problema durante a modificação, eu não poderei recuperar pela rede com o CFE, pois o ZBT-601 não tem porta ethernet.

Mas tem uma outra coisa que está quase me fazendo abandonar o projeto. É o risco de se rodar um zmw_base_zinwell incompatível, que modifique a flash para gravar as configurações pessoas do STB e que torne a flash incompatível com o zmw_base_zinwell dos ZBTs. É o caso do zmw_base_zinwell do SEMP. Como eu e o rafael_netto apontamos, se ele for rodado pelo pendrive, vai alterar a flash e zmw_base_zinwell do próprio aparelho vai ser abortado durante a execução e só será possível fazer a recuperação via cabo. Sem falar no ZBT-601 sem rede. 

[zeurt]

Não dá para trocar a ordem das partições. Só se você mover a partição NTFS para o final e criar a nova partição no espaço inicial. Mas esse processo é arriscado e pode ser bem lento.

Quando eu li a sua prudente recomendação já era tarde: eu já tinha começado a mover a partição para a extremidade final do HDD...  Bom, hoje cedo, quando acordei, o processo já durava 8 horas e tinha movido apenas um terço do total de 425GB. O tempo estimado do termino era 7 horas. Vamos ver se eu dou sorte... P.S.: Dei sorte: a partição foi movida com sucesso, em quase 16 horas, e aparentemente está tudo OK.

Mas tem uma outra coisa que está quase me fazendo abandonar o projeto. É o risco de se rodar um zmw_base_zinwell incompatível, que modifique a flash para gravar as configurações pessoas do STB e que torne a flash incompatível com o zmw_base_zinwell dos ZBTs. É o caso do zmw_base_zinwell do SEMP. Como eu e o rafael_netto apontamos, se ele for rodado pelo pendrive, vai alterar a flash e zmw_base_zinwell do próprio aparelho vai ser abortado durante a execução e só será possível fazer a recuperação via cabo. Sem falar no ZBT-601 sem rede. 

Quando você diz abandonar o projeto, quer dizer o projeto do Mini Modo de Desenvolvimento, ou TODO o projeto de desenvolvimento? 
Eu acompanhei tudo o que aconteceu com a questão do SEMP, etc. mas não tinha me tocado em como isso influenciaria o futuro Mini Modo de Desenvolvimento, com os riscos já descritos...
Eu tenho uma solução meio delirante para você voltar a ter a rede a sua disposição. Já vi relatos no HTForum de 2 usuários que tiveram problemas nas atualizações de seus firmwares e que desistiram de tentar recuperar seus aparelhos. Um deles foi o Cassien. O outro eu não me lembro (tenho que procurar). Ele disse que estava doando seu aparelho ("seria para o bem da ciência"?  ). A condição era que o interessado teria que pegar o aparelho lá na cidade dele.
Bom, a minha sugestão é: você poderia propor uma troca para algum dos dois: trocar o seu ZBT-601 pelo AIKO ou pelo outro aparelho (que não lembro qual clone era...). Todos sairiam ganhando: você teria a rede para os seus desenvolvimentos (caso conseguisse recuperar o aparelho com o cabo, é claro...), e o outro voltaria a ter um aparelho funcionando perfeitamente...
Nessa eu viajei bastante, né? 
De qualquer modo, se você pressente que o Mini Modo de Desenvolvimento não teria futuro (diante dos possíveis problemas), daí nada disso teria muita importância...
P.S.: Caso a minha idéia delirante faça algum sentido, aqui estão os relatos de 2 usuários do HTForum cujos aparelhos "morreram" recentemente durante atualizações de firmware:
1- Aqui está o relato da perda do AIKO HD-1018 pelo "dramático" Cassien: http://ryan.com.br/smf/index.php?action=post;msg=9178550;topic=692.0
2- Por último, o relato da perda do ZBT-620C pelo Route 66: http://www.htforum.com/vb/showthread.php/137198-Clube-do-Conversor-Zinwell-ZBT-633?p=3125237&viewfull=1#post3125237

O Cassien está sumido, mas o Route 66 está ativo no forum. Já um outro usuário que havia oferecido o seu Telesystem F2.0 "morto" para doação, o shizzen, já doou o aparelho.

[rictad]

Quando eu li a sua prudente recomendação já era tarde: eu já tinha começado a mover a partição para a extremidade final do HDD...  Bom, hoje cedo, quando acordei, o processo já durava 8 horas e tinha movido apenas um terço do total de 425GB. O tempo estimado do termino era 7 horas. Vamos ver se eu dou sorte... P.S.: Dei sorte: a partição foi movida com sucesso, em quase 16 horas, e aparentemente está tudo OK.

Que bom que deu certo.

Quando você diz abandonar o projeto, quer dizer o projeto do Mini Modo de Desenvolvimento, ou TODO o projeto de desenvolvimento? 

Não, seria só o Mini Modo de Desenvolvimento. Mas acho que vou retomá-lo. É só esclarecer que há riscos e mostrar quais são. Aí fica por conta de quem utilizar. Mas vou diminuir o ritmo de desenvolvimento agora, pois também vou começar a dar uma olhada no firmware desse player aqui. 

O Cassien está sumido, mas o Route 66 está ativo no forum. Já um outro usuário que havia oferecido o seu Telesystem F2.0 "morto" para doação, o shizzen, já doou o aparelho.

Hum... vou tentar falar com o Route 66 então. Não para trocar, mas para comprar por um preço baixo. Eu tentei com o Cassien, mas até hoje ele não me respondeu a mensagem privada lá.

[rictad]

Seguem algumas fotos que eu tirei dos aparelhos abertos. Imagens internas do ZBT-633 e, principalmente, do ZBT-620A já são bastante conhecidas. Mas as do ZBT-601 parece que não.

Interessante verificar que apesar de o ZBT-633 slim e o ZBT-620A "tijolão" utilizarem a mesma placa (chamada ZBT-620A versão 1.2), ela não está configurada da mesma forma nos dois aparelhos devido ao painel frontal. No caso do tijolão, o painel frontal é totalmente offboard, com o cabo ligado a um conector na placa. Se lembrarmos, esse painel é chamado pelo firmware de "8051 fp". Já no aparelho slim, esse conector não está presente (percebe-se que há espaço reservado também para outros conectores, possivelmente para outros painéis). O painel frontal é montado na placa. Inclusive há um integrado a mais, provavelmente relacionado ao fp. O firmware chama esse painel de "onboard fp".

O ZBT-601, por sua vez, possui uma placa de mesmo nome do aparelho e apresentada como versão 1.1. Como não possui fonte interna, sua carcaça é bem pequena, apenas para acomodar a placa, e feita de plástico, ao contrário dos outros aparelhos, que possuem gabinete de metal. Já com o dissipador de calor do SOC ocorre o inverso: é do tipo não metálico. O painel frontal também é onboard, apesar de ser mais simples (não possui visor digital). O firmware o chama apenas de "frontpanel".

Não consegui localizar a flash do aparelho, talvez devido ao meus poucos conhecimentos em eletrônica. Mas imagino que possa estar do outro lado da placa. Como já divulgado, a flash da placa ZBT-620A é a MX29LV640DBTC-90G. Inicialmente imaginei que o chip embaixo da etiqueta com a versão do firmware seria a flash, mas trata-se do chip SM894051C25SP da Syncmos, um microcontrolador (painel frontal?) compatível com o 8051. O outro chip acima deste é o Toshiba TC90507XBG, um demodulador de sinal digital. Como o rafael_netto já havia postado e considerando as mensagens do firmware, esse chip também deve estar presente na placa ZBT-620A. Como não é visível, eu imagino que esteja dentro da caixa blindada do sintonizador, que é maior naquela placa.

A placa ZBT-601 também possui o conector "Debug Message" para acessar o CFE e o Busybox por cabo, apesar de o mesmo não estar identificado desta forma. Trata-se do conector em posição vertical, abaixo do SOC da Broadcom e bem à esquerda da inscrição "ZBT-601 V1.1"

[rictad]

Verifiquei que o painel frontal do ZBT-601 tem uma característica diferente dos utilizados nos outros 2 aparelhos. Como no ZBT-633, ao ligar na tomada, o STB entra em modo standby sem que o firmware possa ser carregado. Ao apertar a tecla power, o firmware é carregado, mas a partir daí o fp não parece ter mais o controle total sobre o aparelho. Se apertarmos power novamente, antes do zmw_base_zinwell ser carregado, o STB não é desligado. No entanto, em aproximadamente 5 segundos o sistema é reiniciado. O que parece acontecer é o seguinte: o painel envia um sinal ao firmware. Este, ao receber o sinal, é quem desliga o aparelho. Mas caso isso não ocorra em 5 segundos, um reset é dado no sistema, comandado pelo fp. Isso ocorre também quando há um travamento ou quando o painel frontal não é inicializado corretamente (quando eu usei o firmware dos outros aparelhos). Neste caso, a tecla power do fp sempre boota o STB em 5 segundos. E isso não vale para a tecla power do controle remoto, que fica inútil. Ou seja, com um firmware incorreto, a única forma de desligar o aparelho é pela tomada. Já nos outros 2 aparelhos, como relatado anteriormente, a tecla power do painel frontal sempre desliga o STB, independentemente do estado do firmware, e a tecla power do respectivo controle remoto também, pois é a única que sempre funciona de forma direta, sem passar pelo crivo do firmware.

Isso talvez abra uma possibilidade para modificar o firmware de modo a permitir o desligamento utilizando todos os controles suportados, em vez de apenas o controle original de cada aparelho.

[Weverton]

Olá senhores, tentei atualizar meu zbt 633 (620 slim) com a firmware v1.14.7, e o aparelho "morreu"! Estava instalada a v1.14.4.
Ocorreu que ao apertar a tecla vermelha para atualizar o vídeo deu uma "tremida" e depois estabilizou, e nada aconteceu depois; o controle remoto não estava funcionando, nem botões do painel, e deixei assim por uma hora, quando decidi desligar da tomada.
Resultado: quando aperta o power, no controle ou no painel a luz vermelha se apaga, mas o aparelho não inicia, fica estático!
Pergunto: dá pra recuperar?
Desde já, agradecido!

[rictad]

Olá senhores, tentei atualizar meu zbt 633 (620 slim) com a firmware v1.14.7, e o aparelho "morreu"! Estava instalada a v1.14.4.
Ocorreu que ao apertar a tecla vermelha para atualizar o vídeo deu uma "tremida" e depois estabilizou, e nada aconteceu depois; o controle remoto não estava funcionando, nem botões do painel, e deixei assim por uma hora, quando decidi desligar da tomada.
Resultado: quando aperta o power, no controle ou no painel a luz vermelha se apaga, mas o aparelho não inicia, fica estático!
Pergunto: dá pra recuperar?
Desde já, agradecido!

Você tentou atualizar para a versão oficial 1.14.7 da Ivison a partir da versão 1.14.4 também oficial?

[Weverton]

Oi, rictad, isso mesmo, ambas as "firmwares" eram versões originais da Ivision!
Pelo que li aqui no fórum, existe uma remota possibilidade de recuperar o aparelho pela porta ethernet, não é isso?
Agradecido pela atenção!

[rictad]

Oi, rictad, isso mesmo, ambas as "firmwares" eram versões originais da Ivision!

Hum... Então deve estar relacionado com isso, escrito anteriormente:

Exatamente como eu vi em alguns relatos espalhados pela rede, essa versão tem um bug que liga o closed caption (CC) quando você conecta alguma coisa na porta USB. Esse seria apenas um pequeno bug inconveniente se não houvesse outro mais perigoso atrelado, que eu verifiquei. Quando o CC está ligado, o progresso de atualização de firmware some da tela em menos de 1 segundo (só reaparece se alguma legenda de CC é apresentada, alternando junto com ela). Então, se o usuário instalar a versão 1.14.4 e for fazer uma nova atualização no futuro, quando ele conectar o pendrive, o CC será ativado. Quando a atualização começar (e se não tiver passando nada na TV com closed caption), a tela de atualização irá sumir, mas a atualização continuará sendo feita! O usuário, sem saber o que está acontecendo, pode acabar desligando o STB antes da atualização acabar e matar o aparelho (...)

Pelo que li aqui no fórum, existe uma remota possibilidade de recuperar o aparelho pela porta ethernet, não é isso?
Agradecido pela atenção!

Sim, há a possibilidade de recuperar via ethernet caso você construa o cabo e desde que o CFE não tenha sido corrompido. Aqui no tópico há informações que podem te ajudar. Outra possibilidade seria mandar para a assistência técnica, mas provavelmente haverá custos.

[zeurt]

O estranho é que o Weverton disse que só desligou o aparelho após 1 hora...

Só pra deixar claro: a complicação na atualização de FW devido a esse bug da CC pode ser evitada simplesmente se desligando a CC (que tenha sido ligada automaticamente e indevidamente após ter conectado o pendrive), não é isso?

[zeurt]

Nos últimos dias eu andei pesquisando algumas coisas sobre o arquivo .mpg gerado pelo ZBT-601/633.
Na verdade, o arquivo é um MPEG Transport Stream, porém o container usado é muito pouco amigável, de modo que não é possível reproduzi-lo diretamente em Media Players, por exemplo (testei no NMT A-200 que eu possuo). Eu fiquei sabendo que alguns arquivos gerados por outros PVRs já usam o container .TS tradicional e não apresentam esse tipo de limitação.

Os meus objetivos eram:

1-) Conseguir reproduzir os arquivos gravados pelo ZBT-601 no Media Player de mesa (no caso o NMT A-200) da maneira mais simples e rápida possível. Talvez quem estiver lendo possa pensar: pra que reproduzir os arquivos no Media Player se eles podem ser reproduzidos no próprio PVR?? Tenho 2 motivos pra isso:
a-) No Media Player eu posso contar com INÚMEROS recursos úteis na reprodução dos arquivos, os quais não estão disponíveis no ZBT-601, entre eles: função RESUME (que fica na memória mesmo após o Media Player ser desligado), função GOTO/Time Search, Slow Motion, Quadro a Quadro, Avanço e Retrocesso Rápidos melhores, teclas dedicadas para a reprodução no controle remoto, etc.
b-) Como o ZBT-601 fica na casa da minha mãe, as vezes eu posso pedir pra ela gravar algum programa, o qual eu poderei assistir em casa no Media Player. 

2-) Vejam bem, eu particularmente não tenho interesse em reencode dos arquivos para fins de economia de espaço, e arquivamento. O máximo que eu me interessaria seria a opção de "cortar excessos" da gravação, caso isso fosse fácil e rápido.

Depois de procurar bastante, não encontrei uma solução gratuita que cumprisse os objetivos que traçei acima (ainda espero que apareça alguma). O DGAVCIndex é um dos únicos programas gratuitos que faz o Demux do .mpg criado pelo nosso conversor. Porém, não achei uma solução gratuita que fizesse simplesmente o remux dos streams para .TS (tsmuxer), .mkv (mkvmerge), .mp4 (MP4Box), ou o que quer que seja (que pudesse ser reproduzido no meu Media Player). São frequentes os erros decorrentes do áudio da nossa TV Digital Brasileira ISDB-TB: o AAC-LC LATM/LOAS (nas soluções gratuitas que encontrei, o audio sempre tinha que ser convertido primeiro). Muito menos achei solução gratuita que permitisse a edição do arquivo, cortando os excessos, de maneira simples, rápida, e livre de problemas...

Olhando no site do neozelandês tburtenshaw, criador do Zimview, vi que a única recomendação que ele fazia em relação à edição do arquivo .mpg, era o programa VideoReDo TV Suite. Ele estava certo: esse programa faz tudo o que eu estava buscando (descrito acima), de maneira simples e rápida. O .TS gerado (após edição, caso desejada) é reproduzido perfeitamente no meu NMT A-200. O problema é que o programa é pago... 

Link do site do Zinview, falando sobre edição: http://code.google.com/p/zimview/wiki/UsingAndRecordingWithOleviaFirmware

Link do VideoReDo TVSuite: http://www.videoredo.com/en/ProductTVS.htm

[rictad]

O estranho é que o Weverton disse que só desligou o aparelho após 1 hora...

Também achei estranho. No caso de não ter havido nenhuma interferência externa, a atualização deveria ter seguido, ainda que o progresso não estivesse sendo exibido. Mas das inúmeras vezes (e foram muitas mesmo ) que fiz atualizações durante o desenvolvimento, observei algumas instabilidades como essa.

Só pra deixar claro: a complicação na atualização de FW devido a esse bug da CC pode ser evitada simplesmente se desligando a CC (que tenha sido ligada automaticamente e indevidamente após ter conectado o pendrive), não é isso?

Pode ser que sim. Mas eu não consigo lembrar se a versão 1.14.4 com bug também ligava o CC após a confirmação de atualização do firmware. Então talvez o melhor mesmo seja colocar em um canal sem sinal quando for atualizar a partir da versão 1.14.4 oficial.

[zeurt]

Um problema com o Firmware Rictad versão 1.14.4b beta 2 no ZBT-601:
Oi rictad,
Eu detectei o seguinte problema: após o aparelho ficar ligado por algumas horas, não é mais possível desligá-lo pelo controle remoto. Eu pude observar isso algumas vezes (o aparelho não fica em casa). Quando eu verifiquei esse problema, foi assim: após um tempo ligado (talvez 2 horas, mais ou menos), ao tentar desligá-lo pelo controle, a tela ficava preta, o som desaparecia, mas o LED não ficava vermelho. Pressionar POWER no próprio aparelho provocava o reboot (conforme esperado). Daí, ao tentar desligar pelo controle, acontecia a mesma coisa, não desligava.
Esse problema ocorria todos os dias. Esperei uma semana para trocar de firmware e verificar se mudava alguma coisa: atualizei para a versão oficial 1.15.4 específica do ZBT-601, e a partir de então, os problemas não ocorreram mais... 

Realmente, HDDs com partições NTFS e ao mesmo tempo ext3 ou Fat32 não funcionam:
Testei com os 2 HDDs de 500GB que tenho, com partições FAT32 (de 16 e depois 40GB), e ext3 (de 16 e depois 40GB também) e não funcionou.
Mesmo aquele teste meio arriscado que eu fiz, de mover toda a partição NTFS grande para a direita, para colocar a FAT32 na esquerda não funcionou.
Não sei se pode ter a ver com o tamanho das partições, ou outra coisa ainda obscura.
Acho que mais testes podem elucidar melhor isso, mas até que se prove ao contrário, não funciona... 
P.S.: Só pra deixar registrado, acabei fazendo o backup de um dos meus HDDs e o formatei com uma única partição em FAT32, e funcionou.

[rictad]

Um problema com o Firmware Rictad versão 1.14.4b beta 2 no ZBT-601:
Oi rictad,
Eu detectei o seguinte problema: após o aparelho ficar ligado por algumas horas, não é mais possível desligá-lo pelo controle remoto. Eu pude observar isso algumas vezes (o aparelho não fica em casa). Quando eu verifiquei esse problema, foi assim: após um tempo ligado (talvez 2 horas, mais ou menos), ao tentar desligá-lo pelo controle, a tela ficava preta, o som desaparecia, mas o LED não ficava vermelho. Pressionar POWER no próprio aparelho provocava o reboot (conforme esperado). Daí, ao tentar desligar pelo controle, acontecia a mesma coisa, não desligava.
Esse problema ocorria todos os dias. Esperei uma semana para trocar de firmware e verificar se mudava alguma coisa: atualizei para a versão oficial 1.15.4 específica do ZBT-601, e a partir de então, os problemas não ocorreram mais... 

Estranho... Eu observei isso algumas vezes, mas com todos os firmwares e cheguei à conclusão que fosse um bug no painel frontal do 601, independente da versão de firmware. Por exemplo, agora a pouco desliguei normalmente pelo CR o meu 601 com a versão 1.14.4b beta2 que estava ligado por mais de 3 dias (eu quase nunca desligo, mas sempre que o faço é pelo CR e depois de dias ligado). Precisamos de mais testes. Lembrando que a versão 1.14.4 foi feita originalmente para o ZBT-633 e realmente pode ter algo que potencializa esse efeito.

Nos testes que você fez nas duas versões, havia algo ligado à porta USB? Uma das coisas que observei na versão 1.15.4 oficial é que, após vários minutos, ela desconecta o pendrive e o reconecta, ligando o CC. Mas isso com meu pendrive. Não observei esse efeito com um HDD. O meu 601 fica várias horas ligado mas sem nada na USB.

[zeurt]

O problema sempre acontecia sem nada conectado na USB...

[PedroAcerbi]

Pessoal, boa noite!
Sou novo aqui no forum, e gostaria de pedir licença para relatar uma situação lamentável que ocorreu comigo.

Atualizei para a versão 1.14.4. Ate ai tudo bem. Depois atualizei novamente para a versao 1.14.4B que você lançou no fórum e o aparelho morreu.
O aparelho não desliga pelo controle nem pelo botão frontal. So desliga tirando a tomada.
Ligar ele liga. E antes de jogar o logo da Zinwell, ele corta o sinal do cabo HDMI.
Com cabo composto, fica parado no logo da Zinwell.

Será que há alguma esperança para o meu equipamento?
Ou devo tentar devolve-lo para a loja que me vendeu?

Obrigado.

[rictad]

Pessoal, boa noite!
Sou novo aqui no forum, e gostaria de pedir licença para relatar uma situação lamentável que ocorreu comigo.

Atualizei para a versão 1.14.4. Ate ai tudo bem. Depois atualizei novamente para a versao 1.14.4B que você lançou no fórum e o aparelho morreu.
O aparelho não desliga pelo controle nem pelo botão frontal. So desliga tirando a tomada.
Ligar ele liga. E antes de jogar o logo da Zinwell, ele corta o sinal do cabo HDMI.
Com cabo composto, fica parado no logo da Zinwell.

Será que há alguma esperança para o meu equipamento?
Ou devo tentar devolve-lo para a loja que me vendeu?

Obrigado.

Olá Pedro!

Seu aparelho é um ZBT-601, não é?

Pelo que você escreveu, aconteceu uma falha na atualização. Como o logo é exibido, então o zmw_base_zinwell está sendo carregado, o que indica que o CFE está gravado corretamente. Portanto, é possível recuperá-lo via cabo, com o método alternativo descrito pelo rafael_netto (pela linha de comando do busybox), mas com duas partições no pendrive: uma contendo um zmw_base_zinwell alternativo funcional para ser chamado pelo busybox para rodar a interface do STB e a outra contendo uma nova versão do firmware para ser gravada.

[rafael_netto]

A situação do Pedro é parecida com aquela do Cassien, que tentou atualizar um Aiko que tinha um firmware antigo. Será que também é incompatibilidade do rootfs?

Pelo que o Pedro contou no HTF ele fez as atualizações assim que tirou o aparelho da caixa, sem sintonizar canal nenhum. De repente nessas condições o rootfs permanece "limpo" e dá pau com o firmware modificado.

Aproveitando....
Rictad e Zeurt, vocês que andaram fuçando o sistema do aparelho, viram se existe algum tipo de "recuperação de emergência", alguma forma de rodar uma atualização na hora do boot sem ser pela interface?

[rictad]

A situação do Pedro é parecida com aquela do Cassien, que tentou atualizar um Aiko que tinha um firmware antigo. Será que também é incompatibilidade do rootfs?

Pelo que o Pedro contou no HTF ele fez as atualizações assim que tirou o aparelho da caixa, sem sintonizar canal nenhum. De repente nessas condições o rootfs permanece "limpo" e dá pau com o firmware modificado.

Aproveitando....
Rictad e Zeurt, vocês que andaram fuçando o sistema do aparelho, viram se existe algum tipo de "recuperação de emergência", alguma forma de rodar uma atualização na hora do boot sem ser pela interface?

Pois é, eu pensei nisso. Eu estou suspeitando de uma coisa. Ele atualizou para a versão 1.14.4 primeiro. Nunca fiz esse teste, mas a versão 1.14.4 do ZBT-601 tem o mesmo número. Pode ser que o firmware não faça o reset das informações da eeprom do rootfs no primeiro boot, pois ele considera que está na mesma versão e isso pode tornar as coisas incompatíveis. Vou repetir os passos dele agora aqui para tirar a dúvida.

Teve um único momento que eu vi uma espécie de recuperação de emergência. Foi um susto que eu tive quando testei o firmware de um Olevia no "tijolão". Ele gravou o CFE mas não conseguia achar o Kernel Linux. Foi mostrada uma imagem de erro na tela numa caixa no mesmo padrão da interface gráfica do Zinwell, com coisas em chinês e uma mensagem do tipo "procurando firmware de recuperação". Parecia que estava procurando algo na rede, mas não tenho certeza. O susto foi que o prompt do CFE não era mostrado e eu achei que o aparelho estava irrecuperável. Mas depois eu vi que ele tentava achar o firmware, dava uma mensagem de não encontrado (isso no terminal do CFE) e tentava de novo. Aguardei ele tentar várias vezes, umas 30, até que desistiu e mostrou o prompt. Aí pude regravar as coisas pela ethernet.

Enfim, parece haver um método nesse CFE das versões novas (que inclusive é maior e tem um prompt diferente) mas que só é executado quando não acha o Kernel e que não é utilizado de forma correta nos nossos Zinwell.

[zeurt]

Um fato curioso é que tanto a atualização mal sucedida do Weverton como a do PedroAcerbi partiram do FW 1.14.4 Oficial (sendo o primeiro no ZBT-633 e o segundo no ZBT-601). Será que essa versão é mesmo mais propensa a problemas (além do já descrito bug da CC)?

[PedroAcerbi]

Pessoal, boa noite!
Sou novo aqui no forum, e gostaria de pedir licença para relatar uma situação lamentável que ocorreu comigo.

Atualizei para a versão 1.14.4. Ate ai tudo bem. Depois atualizei novamente para a versao 1.14.4B que você lançou no fórum e o aparelho morreu.
O aparelho não desliga pelo controle nem pelo botão frontal. So desliga tirando a tomada.
Ligar ele liga. E antes de jogar o logo da Zinwell, ele corta o sinal do cabo HDMI.
Com cabo composto, fica parado no logo da Zinwell.

Será que há alguma esperança para o meu equipamento?
Ou devo tentar devolve-lo para a loja que me vendeu?

Obrigado.

Olá Pedro!

Seu aparelho é um ZBT-601, não é?

Pelo que você escreveu, aconteceu uma falha na atualização. Como o logo é exibido, então o zmw_base_zinwell está sendo carregado, o que indica que o CFE está gravado corretamente. Portanto, é possível recuperá-lo via cabo, com o método alternativo descrito pelo rafael_netto (pela linha de comando do busybox), mas com duas partições no pendrive: uma contendo um zmw_base_zinwell alternativo funcional para ser chamado pelo busybox para rodar a interface do STB e a outra contendo uma nova versão do firmware para ser gravada.

Certo, então nesse caso, como seria a ligação a se fazer com esse cabo?
Teria que abrir o aparelho e soldar o cabo ou tem algum encaixe na placa?

Ou bastaria um pendrive com duas partições e pronto?
Percebo que ao ligar o conversor com o pendrive nele, o pendrive é acionado.

[zeurt]

Oi PedroAcerbi,

Não precisa soldar o cabo na placa. Existe um conector como o rictad explicou aqui: http://ryan.com.br/smf/index.php?topic=692.msg9178357#msg9178357

Aqui tem as fotos do ZBT-601 feitas pelo rictad (explicando onde está o conector): http://ryan.com.br/smf/index.php?topic=692.msg9178558#msg9178558

Se você precisar do Cabo Serial, esse aqui é uma boa opção: http://ryan.com.br/smf/index.php?topic=424.msg9178370#msg9178370

Para recuperar o aparelho pelo método alternativo 2, pelo prompt do Busybox, ler à partir deste post do rafael_neto: http://ryan.com.br/smf/index.php?topic=692.msg9178513#msg9178513

O método alternativo 1 de recuperação do firmware pelo CFE não pode ser usado no ZBT-601 pois ele não tem ethernet.

[rictad]

Confirmado! Não é viável atualizar o ZBT-601 para a versão Rictad 1.14.4b a partir das versão 1.14.1 ou 1.14.4 oficiais (e eu imagino que valha para todas as 1.14.X). O aparelho ficará inutilizável, recuperável somente via cabo. Mas isso é só para o ZBT-601.

Não sei o porquê, mas o firmware não apaga e não formata as informações de configuração da eeprom e da flash após a atualização. Parece considerar que está na mesma versão. No ZBT-633 isso não acontece. Por exemplo, se o aparelho estiver na versão 1.14.7, ele considera outra versão e reseta as informações. Apenas se estiver na versão 1.14.4 isso não acontece. Mas aí sim, trata-se da mesma versão, o que não dá problemas, pois o formato das informações é o mesmo.

A recuperação para esse caso chega a ser mais simples, mas ainda precisa do cabo e também do Putty configurado no PC. Usa apenas a parte inicial do método alternativo 2. Basta rodar o zmw_base_zinwell da versão 1.15.4 a partir do pendrive. Ele irá formatar a eeprom, zerando as informações e dará um boot. Aí, após o boot, o firmware do 1.14.4b também irá apagar a eeprom, pois a achará no formato da 1.15.4, e dará um novo boot. Depois desses 2 boots, o firmware estará funcional.

Se eu já tivesse lançado o mini modo de desenvolvimento, não precisaria do cabo.

Segue, em anexo, o zmw_base_zinwell da versão 1.15.4 do ZBT-601. Ele deve ser descompactado em um pendrive formatado em FAT32. Com o cabo feito, e o pendrive no STB, deve-se ligar o aparelho e esperar o mesmo bootar, travar e automaticamente entrar no prompt do Busybox. Após isso ocorrer, deve-se montar o pendrive digitando no Putty:

Código: [Selecionar]

mount /dev/sda1 /mnt/usb
Após isso, deve-se entrar no diretório /mnt/usb com o comando:

Código: [Selecionar]

cd /mnt/usb
Agora é possível listar o conteúdo do diretório com o comando

Código: [Selecionar]

ls -al
Como não foi carregado o módulo para exibir arquivos de nomes extensos, o arquivo será abreviado conforme as regras do FAT32. No meu caso, apareceu como zmw_ba~1.4. Após isso, é só chamar o binário da seguinte forma:

Código: [Selecionar]

./zmw_ba~1.4
Se não conseguir digitar o "~" no terminal do Putty, pode copiar e colar.

Para evitar esses problemas e semelhantes no futuro, irei procurar a rotina que faz a verificação da versão e tentarei alterá-la para sempre formatar as informações de configuração, mesmo que a versão seja considerada a mesma.

[PedroAcerbi]

Acreditem ou não... atualizei para a versão 1.14.4, por ter o mesmo número da versão beta do Rictad.
Achei que fosse a melhor versão para servir como base para a atualização para versão Rictad.

Uma daquelas infelizes coincidências da vida.

[PedroAcerbi]

Oi PedroAcerbi,

Não precisa soldar o cabo na placa. Existe um conector como o rictad explicou aqui: http://ryan.com.br/smf/index.php?topic=692.msg9178357#msg9178357

Aqui tem as fotos do ZBT-601 feitas pelo rictad (explicando onde está o conector): http://ryan.com.br/smf/index.php?topic=692.msg9178558#msg9178558

Se você precisar do Cabo Serial, esse aqui é uma boa opção: http://ryan.com.br/smf/index.php?topic=424.msg9178370#msg9178370

Para recuperar o aparelho pelo método alternativo 2, pelo prompt do Busybox, ler à partir deste post do rafael_neto: http://ryan.com.br/smf/index.php?topic=692.msg9178513#msg9178513

O método alternativo 1 de recuperação do firmware pelo CFE não pode ser usado no ZBT-601 pois ele não tem ethernet.

Muito obrigado Zeurt. Vou tentar fazer algo com essas informações que você passou.
Uma perguntinha de newbie: O que seria o "Busybox"?

[zeurt]

De acordo com o slogan, "O Canivete Suiço dos Linux Embarcados", o Busybox é um conjunto de programas e ferramentas necessários para a execução de um sistema Linux. Como ele ocupa pouco espaço, ele se torna ideal para ser usado em Linux embarcado, como é o caso dos ZBT-601/633 e inúmeros outros aparelhos de vários gêneros.
De acordo com o rictad, se você conectar o cabo corretamente no aparelho, com o pendrive com as 2 partições inserido como explicado, e com o Putty devidamente configurado no PC, ao ligar o aparelho (e ele travar) o prompt do Busybox já irá aparecer no Putty, e daí é só digitar os camandos que ele recomendou acima...

[rictad]

De acordo com o slogan, "O Canivete Suiço dos Linux Embarcados", o Busybox é um conjunto de programas e ferramentas necessários para a execução de um sistema Linux. Como ele ocupa pouco espaço, ele se torna ideal para ser usado em Linux embarcado, como é o caso dos ZBT-601/633 e inúmeros outros aparelhos de vários gêneros.
De acordo com o rictad, se você conectar o cabo corretamente no aparelho, com o pendrive com as 2 partições inserido como explicado, e com o Putty devidamente configurado no PC, ao ligar o aparelho (e ele travar) o prompt do Busybox já irá aparecer no Putty, e daí é só digitar os comandos que ele recomendou acima...

Certo! Mas basta uma única partição no pendrive, pois ele só vai rodar o zmw_base_zinwell de dentro dela. Não precisa de outra com a imagem de um firmware, pois não será necessário reatualizar.

[rafael_netto]

Rictad, Zeurt,

algum de vocês chegou a ver a parte de sintonia e medidores de sinal?
Eu gostaria de poder debugar os medidores de sinal no Semp, fazê-los funcionar como os dos Zinwell 1.7.2 e posteriores. Infelizmente não tenho a habilidade de vocês de fuçar o código...

Fazer o PVR funcionar no Semp, no meu caso, não é prioridade.

[rictad]

Rictad, Zeurt,

algum de vocês chegou a ver a parte de sintonia e medidores de sinal?
Eu gostaria de poder debugar os medidores de sinal no Semp, fazê-los funcionar como os dos Zinwell 1.7.2 e posteriores. Infelizmente não tenho a habilidade de vocês de fuçar o código...

Fazer o PVR funcionar no Semp, no meu caso, não é prioridade.

Eu ainda não olhei essa parte, rafael.
Mas ainda vou tentar fazer isso. 

[zeurt]

Rafael,
Ultimamente eu tenho investigado apenas a parte de dados do firmware (.data no IDA), ou seja, a parte que interessa à você está na parte do código, e eu tenho estado longe dela...

[alex h guerra]

pessoal    tenho um zinwell 620 tijolao  que o tuner esta bem deficiente......   hora funciona, hora não funciona.....   hora pega todos os canais, hora não.....   ja dediquei uma antena para o aparelho, mas nada...
como o equipamento no demais esta funcionando, para resolver o problema apliquei o flash ZBT-620A_1.14.4a.beta.rar para ver ser resolvia o problema.....   nao resolveu ....

quando plugo o aparelho em uma tv analógica, tenho a impressão que o mesmo está sofrendo um pouco com interferencia.....   aterramento....  o mesmo efeito nao aparece no hdmi...   então estou supondo que o mesmo esteja na parte analógica.....

estou procurando uma forma de atraves do shell linux do conversor buscar informações/diagnoticar se o problema é no componente tuner....  alguem tem dicas de como fazer isto?

Grato!