FORUM.RYAN.COM.BR

Obrigado, Ryan.

Só para atualizar, os "conversores chineses da última semana" até agora incluem as seguintes "etiquetas", provavelmente existem e existirão muitas outras:

Ekotech (que foi lançada como Zinwellbr e depois tomou processo da Zinwell de Taiwan pelo uso indevido da marca)
Neo
Elsys
LBSat (modelos 15T e 20T)
Digital Tech
Telesystem (modelo 2300)
Aquário
Castelo
Cromus (modelo 11B)
Mixlaser
Lenoxx
Shuray
CCE (até eles...)
Vicini
Fortrek
Bedin Sat

Todos eles são baseados no chip Mstar MS7828, apresentam interfaces parecidas (até nos erros de tradução), com as mesmas funcionalidades, limitações e bugs (o mais comum a imagem ficar em "câmera lenta" no futebol da Globo). Todos são fabricados na China e muitos deles podem ser encontrados no alibaba.com. Típicos produtos baratos de prateleira, vendidos por empresas que não colocam nada além do nome.

Existe inclusive a suspeita que essa plataforma bugada está sendo usada até mesmo em TVs com sintonia digital.

Quanto a Proview, o histórico do DVP-858 acabou enganando muita gente no HTForum, a marca acabou superestimada por causa disso.

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.

É, 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
#! /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:
#!/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:

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


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:
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?

Citação de: rafael_netto em Março 25, 2011, 10:58:23 pm

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?