FORUM.RYAN.COM.BR

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?

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:

.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

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

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.

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:
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:
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:
.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:
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":
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:
.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.

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.