Mudanças entre as edições de "GC150ATA"
Linha 100: | Linha 100: | ||
==== Via Soquete PLCC ==== |
==== Via Soquete PLCC ==== |
||
− | Desoldar o chip, conectá-lo a um conversor PLCC→DIP e utilizar o TL866CS para fazer o dump. |
+ | Desoldar o chip, conectá-lo a um conversor PLCC→DIP e utilizar o [[TL866CS]] para fazer o dump. |
'''CONTRAS:''' Procedimento invasivo. Ter que soldar um soquete no lugar, e depois ter que remover/reinserir toda vez que for atualizar o firmware. Pode danificar o componente pelo esforço mecânico. |
'''CONTRAS:''' Procedimento invasivo. Ter que soldar um soquete no lugar, e depois ter que remover/reinserir toda vez que for atualizar o firmware. Pode danificar o componente pelo esforço mecânico. |
Edição das 00h27min de 9 de julho de 2014
descrição geral
Display VGA SYS-GC150ATA
É um painel LCD comum. Meu interesse nele está em reprogramar o firmware pra fazer coisas inusitadas. Como ele tem um sistema de OSD (On-Screen Display), podemos fazer animações por cima do vídeo que estiver vindo pelo conector VGA. Dá também pra fazer isso de forma interativa, já que o display tem 4 botões (além do liga-desliga) na parte da frente.
Principais componentes
CPU
MYSON mtv312mv64 - variante de 8051
Datasheet em: http://www.telemaster.ru/minitv/pdf/MTV312MV64.pdf
chip de vídeo
Controlador GENESIS gmZAN1
Datasheet em: http://www.datasheetarchive.com/dlmain/Datasheets-312/182051.pdf
EPROM
Memória EPROM serial (I2C) ATMEL 24C21
Datasheet em: http://www.datasheetcatalog.com/datasheets_pdf/2/4/C/2/24C21.shtml
Estratégias de Engenharia Reversa
Dump de fw
Via I2C
A placa mãe tem um conector de 4 vias com alabel P303. Foi a primeira coisa que me saltou aos olhos quando abri o equipamento pois era o único conector da placa que não tinha cabo nenhum conectado. Portanto estava bem claro pra mim que deve se tratar de uma interface de programação do dispositivo que é usada na fábrica pra gravar o firmware inicial.
Os sinais desse conector são:
- VCC (5V)
- SCL
- SDA
- GND
As duas vias do barramento i²c estão ligadas aos pinos HSCL e HSDA do 8051.
O datasheet descreve o procedimento para apagar a memória flash por meio da interface I2C, mas imagino que dê também pra fazer o dump. Um dos comandos se chama "data read" e aparentemente é usado para verificação de uma gravação.
O datasheet diz também que o slave address da interface i2c é especificado pelo firmware por meio de uma escrita ao SFR (special funciona register) ISPSLV (In-System Programming Slave Address)
<quote> After Power On/Reset, The MTV312M runs the original Program Code. Once the S/W detects an ISP request (by key or IIC), S/W can accept the request following the steps below:
- Clear watchdog to prevent reset during ISP period.
- Disable all interrupt to prevent CPU wake-up.
- Write IIC address of ISP slave to ISPSLV for communication.
- Write 93h to ISP enable register (ISPEN) to enable ISP.
- Enter 8051 idle mode.
</quote>
Como não temos acesso ao firmware (ainda) não temos como saber qual é o endereço usado. Então resolvi tentar todos! De acordo com a descrição do protocolo de programação da Flash, são 6 bits de endereços possíveis (apesar de i2c permitir 7 bits, um deles - o menos significativo - é usado pra indicar se é acesso de comando ou acesso de dado).
Usando o BusPirate
http://dangerousprototypes.com/docs/Bus_Pirate
Preciso achar o meu que eu perdi ou comprar um novo.
O legal é que dá pra fazer uns scripts pra automatizar o sniffer...
Usando o USBTinyISP
https://learn.adafruit.com/usbtinyisp/
Pensei na possibilidade de modificar o dispositivo para se comunicar por i2c também. Ele é originalmente projetado pra falar SPI (Serial Peripheral Interface).
Cheguei a montar um e compilei o firmware a partir do source, mas quando gravei ele no attiny2313, não funcionou. Quando gravei de volta a imagem de fw precompilada disponivel pra download no site, voltou a funcionar. Talvez a versão do compilador avr-gcc que estou usando não esteja a ideal para geração de código que caiba na flash pequena desse dispositivo.
<quote> You must use avr-gcc v3.4.6 and avr-libc v1.4.4 as part of Winavr-20060421 to compile the firmware. Please do not post to the forums asking for help on how to compile or burn the firmware. </quote>
Achei meio esquisito... Meu avr-gcc 4.5.3 é mais recente que isso (e obviamente eu não uso Windows) mas é isso que eles indicam no site.
Usando a porta VGA
Isso é genial! http://www.instructables.com/file/FZTD0AYFFAOSLO5
Tentei fazer, mas ainda não rolou. :-P
O conector VGA contém uma interface i2c (chamada DDC - Display Data Channel) que é usada para que o monitor informe ao PC suas características como resolução, profundidade de cores, etc. E também permite setar a intensidade de brilho, ajuste de componentes de cor, etc...
Aí a gente pode simplesmente escrever código C que manipula de forma arbitrária essa "porta" i2c pra controlar o que a gente quiser. O adaptador é super simples. É só um conector VGA com os 4 fios que nos interessam (GND, VCC, SDA e SCL).
Inicialmente não consegui baixar o código do cara, por que o site dele estava extremamente lerdo. Então copiei uns trechos do source do ddccontrol-0.4.2 e adaptei para o meu propósito, implementando um algoritmo de dump com base na descrição do datasheet e usando a porta VGA do meu notebook como bridge i2c.
Depois de fazer modprobe i2c-dev e modprobe i915, o comando i2cdetect -l me listou várias interfaces /dev/i2c-0 até /dev/i2c-6.
Fiquei na dúvida de qual era a correta mas a minha intuição apontava para a /dev/i2c-1 (descrita como "i915 gmbus vga") e para a /dev/i2c-6 (descrita como "DPDDC-B") Então fiquei rodando meu código alternando entre essas duas opções pra ver no que dava.
No dia seguinte consegui baixar o código do site do cara, mas ainda não tive tempo de testá-lo.
Para tirar a dúvida sobre qual o /dev correto, dei uma olhada no código do driver da placa Intel i915 no kernel Linux e vi que o nome "gmbus vga" corresponde ao GPIOA que é usado para controlar o DDC, então o /dev correto é mesmo o /dev/i2c-1 no meu laptop.
Usando algum outro bridge USB->I2C
Preciso comprar um desses pra tentar.
Via Soquete PLCC
Desoldar o chip, conectá-lo a um conversor PLCC→DIP e utilizar o TL866CS para fazer o dump.
CONTRAS: Procedimento invasivo. Ter que soldar um soquete no lugar, e depois ter que remover/reinserir toda vez que for atualizar o firmware. Pode danificar o componente pelo esforço mecânico.