No início de maio recebi do IFPR Campus Ivaiporã uma BTV B13 — uma das várias TV boxes apreendidas pela Receita Federal que chegaram à instituição. A missão proposta pelo Prof. Me. Ronan Anacleto Lopes, coordenador do curso de Sistemas de Informação (no qual estudo), era simples: avaliar o que dava pra fazer com esse hardware. Servir como servidores educacionais? Estações leves? Lixo? Comecei pela BTV E13 e não fui longe. Mudei pra BTV B13 e já tive um começo com bons resultados. Três dias depois, consegui rodar Debian 13 + XFCE direto do eMMC, ligando em 5 segundos, e a ideia tinha crescido — sugestão do Prof. Lucas dos Santos Umeoka — pra mini-desktop portátil capaz de programar Arduino para aulas de robótica na instituição. Esse é o relato do processo, das descobertas técnicas e do que deu pra extrair desse hardware reciclado.

Resumo

  • Hardware: BTV B13 (Amlogic S905X4, 4× Cortex-A55, 2GB DDR4, 16GB eMMC)
  • Contexto: avaliação técnica de TV boxes apreendidas pela Receita Federal, recebidas pelo IFPR Campus Ivaiporã, pra uso educacional
  • O desafio: o u-boot vendor proprietário não boota Linux do eMMC porque o layout de partições é AML (não-MBR), e pendrive permanente não escala num lote de várias TV boxes
  • A solução: ESP32 como adaptador UART → acesso ao prompt do u-boot vendor → sequestrar a partição "factory" (originalmente pra DRM) pra carregar um script u-boot custom → bootar Debian do eMMC
  • Bônus: otimização do XFCE (GPU estava travada em 1/3 da capacidade)
  • Resultado: serve bem como servidor low-power (Apache, NGINX, Node, MQTT) e como mini-desktop portátil pra tarefas leves (programar Arduino, edição de código, atividades educacionais)
  • Tudo no GitHub: github.com/gabclima/b13

Como tudo começou

A Receita Federal apreende milhares de TV boxes piratas todo ano. Parte dessas apreensões é destinada a programas de inclusão digital e doação institucional — algumas acabam em escolas, universidades e institutos federais. O IFPR Campus Ivaiporã recebeu um lote desses dispositivos, e o Prof. Me. Ronan Anacleto Lopes, coordenador do curso de Sistemas de Informação, propôs uma análise técnica: dá pra fazer essas TV boxes rodarem Linux e virarem ferramentas úteis pra instituição, em vez de lixo eletrônico?

A pergunta tem peso prático. Cada uma dessas TV boxes recebidas pela gente vem com:

  • ARM 64-bit (4 cores Cortex-A35 ou A55)
  • 1–2 GB de RAM DDR3/DDR4
  • 8–16 GB de eMMC
  • Ethernet, HDMI 4K, WiFi, Bluetooth

A custo zero pra instituição, é mais hardware do que um Raspberry Pi básico custa novo. Se conseguir fazer rodar Linux mainline neles.

O problema é que essas TV boxes não têm suporte maduro fora da caixa. O bootloader é proprietário Amlogic, os drivers WiFi são out-of-tree (fechados), o layout de partições não é MBR/GPT padrão. Pra cada modelo, alguém precisa fazer engenharia reversa do boot e mapear os drivers.

Comecei pela BTV E13 (SoC Amlogic S905W2, família Meson S4). Foi um desastre inicial — o suporte mainline pra família S4 ainda é experimental, e não consegui bootar do eMMC. A E13 rodava Debian, mas só em modo live via pendrive USB.

E aí veio o problema institucional real: pendrive permanente não escala. O IFPR tem mais de uma TV box no lote. Se cada uma precisar de um pendrive plugado pra funcionar, é logística ruim (caro) — pendrives somem, quebram, e não vai ter sempre um disponível pra cada estação. Era óbvio que pra essas TV boxes virarem ferramentas reais (servidores, estações de trabalho), o Linux precisava bootar do eMMC interno.

Mudei o foco pra BTV B13 (SoC Amlogic S905X4, família SC2). Suporte mais maduro, hardware mais bem documentado pela comunidade Armbian/LibreELEC. E foi nela que a coisa toda destravou.

Identificando o hardware

A BTV B13 é vendida como "TV Box Android 11" com promessas de 4K, WiFi dual-band, etc. Abrindo a caixa, o hardware real é:

Placa B13

Pela foto da placa dá pra identificar os principais chips:

  • SoC: Amlogic S905X4 (família SC2, codename interno ohm), 4× Cortex-A55 @ 2.0 GHz, Mali-G31 MP2
  • RAM: 2 GB DDR4 (chip único Rayson RS512M32LM4)
  • eMMC: 16 GB Samsung KLMAG1JETD (11.36 GB úteis no Android, ~12.9 GB livres pro Linux)
  • WiFi/BT: Unisoc UWE5621DS (chip combo SDIO — não MediaTek MT7668 como o driver vendor sugere)
  • Ethernet: PHY interno do SoC, 100 Mbps somente
  • UART: 4 pads expostos com serigrafia GND/TX/RX/3V3, do lado das USBs

Confirmei tudo isso instalando o AIDA64 no Android original e cruzando com fotos da placa:

AIDA64 Sistema B13 AIDA64 Processador B13

Notei algo interessante: a caixa diz "Bluetooth 5.0", mas o AIDA64 reporta como Bluetooth 4+. O chip oficialmente suporta 5.1, mas o vendor BTV não habilitou as features 5.x. Esse tipo de inconsistência entre o que o marketing promete e o que o firmware real entrega é a regra, não exceção, em TV box pirata.

O problema real: bootar Linux do eMMC

A primeira tentativa óbvia: gravar uma imagem Debian num pendrive (usei o excelente projeto devmfc/debian-on-amlogic), plugar na B13, acertar o botão UPDATE embaixo da carcaça com um toothpick (veretinha), ligar — Debian boota. Funciona. Mas é a mesma solução da E13, que não atende ao objetivo institucional. Precisava bootar do eMMC.

E aí encontra a parede: o u-boot vendor da Amlogic não consegue bootar Linux do eMMC. Não porque seja proibido — é porque o layout de partições do AML (proprietário) não bate com o MBR/GPT padrão que o Linux espera. Quando o u-boot tenta fatload mmc 1, ele responde "Unrecognized filesystem type" e desiste.

Procurei na internet semanas. Achei tutoriais pra modelos próximos (S905X3, S905X2) mas nada pra B13 especificamente. Cada SoC da Amlogic tem peculiaridades no boot vendor, e a S905X4 (SC2) é nova o suficiente pra não ter muito conteúdo.

A solução demandou três descobertas em sequência.

Descoberta 1: ESP32 como adaptador UART

Pra entender o boot vendor, preciso ver o que ele está fazendo. A B13 tem 4 pads UART expostos na placa — mas vêm sem pinos, só furos. Pra acessar, soldei pinos macho header de Arduino:

Pads UART com solda Pinos instalados Setup ESP32 conectado

Pra conversar com o UART precisaria de um adaptador USB-Serial 3.3V. Em vez de comprar um FTDI ou CH340 dedicado, usei um ESP32 que tinha sobrando. ESP32 tem UART2 livre (GPIO16/17), trabalha em 3.3V (mesma tensão do SoC Amlogic — sem level shifter), e um sketch de 20 linhas vira bridge USB-Serial:

void setup() {
    Serial.begin(115200);
    Serial2.begin(115200, SERIAL_8N1, 16, 17);
}
void loop() {
    while (Serial2.available()) Serial.write(Serial2.read());
    while (Serial.available()) Serial2.write(Serial.read());
}

Wiring é trivial:

ESP32 GND     ─── BTV GND
ESP32 GPIO16  ─── BTV TX
ESP32 GPIO17  ─── BTV RX

Liga a B13, abre Serial Monitor a 115200 baud, e aparece o log de boot do u-boot vendor.

Aperta uma tecla na janela curta de "Hit any key to stop autoboot" e cai no prompt sc2_ah212#. Agora estou dentro.

Descoberta 2: mapeando as partições AML

No prompt do u-boot, printenv mostra tudo:

bootcmd = run start_autoscript; run storeboot

start_autoscript =
    if mmcinfo; then run start_mmc_autoscript; fi;
    if usb start; then run start_usb_autoscript; fi;
    run start_emmc_autoscript     ← este SEMPRE roda no final

E o start_emmc_autoscript por default é:

start_emmc_autoscript = if fatload mmc 1 1020000 emmc_autoscript;
                        then autoscr 1020000; fi;

Ele tenta carregar um arquivo emmc_autoscript direto da raiz do eMMC, sem especificar partição — e falha, porque o eMMC tem layout AML (não tem "raiz" no sentido FAT padrão).

Mas espera: se eu conseguir colocar um arquivo emmc_autoscript num lugar que o u-boot leia, ele vai executar. E mmc part mostra as partições AML do eMMC:

Part   Start    Sectors  Size  Name
00         0      8192   4MB   bootloader
01     73728   131072   64MB   reserved
02    221184  1638400  800MB   cache
03   1875968    16384    8MB   env
04   1908736    65536   32MB   recovery
05   1990656     4096    2MB   frp
06   2011136    16384    8MB   factory       ← 8 MB de FAT12 "KEYBOX PART"!
07   2043904    49152   24MB   vendor_boot
...
21   2764800  3276800  1.6GB   super         ← coincide com /boot FAT32!
22   6057984 24727552   12GB   userdata      ← coincide com rootfs ext4!

Duas coisas saltam aos olhos:

  1. A partição factory (mmc 1:6) é uma FAT12 de 8 MB com label "KEYBOX PART", originalmente destinada a armazenar chaves DRM do Android. Ela é acessível tanto via Linux quanto pelo u-boot vendor. Caminho perfeito pra colocar nosso script.

  2. As partições super (mmc 1:15 hex = 21 decimal) e userdata (mmc 1:22) começam em setores idênticos ao que o sfdisk cria pra um MBR Linux com start=2764800 e start=6057984. Isso significa que se eu particionar o eMMC com MBR Linux usando esses offsets exatos, o u-boot vendor consegue ler a FAT32 e ext4 do Linux sem entender MBR, simplesmente apontando pra mmc 1:15.

Isso era a pista que faltava.

Descoberta 3: o sequestro da factory partition

Com as duas descobertas anteriores juntas, o plano se desenhou:

  1. Particionar o eMMC com MBR Linux usando os offsets mágicos (sectors 2764800 e 6057984)
  2. Copiar/boot (FAT32) e rootfs (ext4) Debian pra essas partições
  3. Escrever um script u-boot emmc_autoscript que carrega o bootscript Debian de mmc 1:15
  4. Gravar esse script na factory partition (mmc 1:6)
  5. Modificar a variável start_emmc_autoscript do u-boot vendor pra apontar pra mmc 1:6 em vez do default genérico
  6. Salvar com saveenv (persiste entre reboots)

A partição factory é montável via Linux com:

mount -t vfat -o loop,offset=1029701632,sizelimit=8388608 /dev/mmcblk1 /mnt/factory

(1029701632 = sector 2011136 × 512 bytes)

A modificação do env do u-boot é feita pelo prompt do u-boot vendor (acessado via UART):

setenv start_emmc_autoscript 'if fatload mmc 1:6 1020000 emmc_autoscript; then autoscr 1020000; fi;'
saveenv

Boot:

$ uname -a
Linux tvbox 6.18.28-meson64 #1 SMP PREEMPT aarch64 GNU/Linux

$ systemd-analyze
Startup finished in 890ms (kernel) + 3.987s (userspace) = 4.877s

5 segundos do power-on ao login screen, sem pendrive, sem toothpick (ficar apetando o botão UPDATE), sem ESP32 — só ligar na tomada.

Otimizando o XFCE engasgado

Depois do boot autônomo funcionando, abri o XFCE pra ver. Decepção: mouse travado, janelas com lag visível, menus animando aos trancos. Pra um hardware com 4× Cortex-A55 @ 1.8 GHz e Mali-G31, isso não fazia sentido.

Investigando, achei a causa real:

$ cat /sys/class/devfreq/fe400000.gpu/cur_freq
285714281
$ cat /sys/class/devfreq/fe400000.gpu/available_frequencies
285714281 400000000 500000000 666666666 846000000

A GPU Mali-G31 estava travada na frequência mínima (285 MHz, 1/3 do máximo). O governor padrão do devfreq é simple_ondemand, tunado pra cargas sustentadas de jogos — não pra burst de UI. Mover uma janela dura 100ms, abaixo do threshold pra rampar o clock.

Solução: forçar governor performance:

echo performance > /sys/class/devfreq/fe400000.gpu/governor

Resultado imediato: glxgears subiu, mouse fluido, sensação geral de máquina normal. Persisti via systemd unit pra reaplicar no boot.

Outros ajustes que ajudaram: forçar DRI3 + PageFlip no Xorg (/etc/X11/xorg.conf.d/20-meson.conf), ligar compositor XFWM4 com vsync. O tutorial completo do XFCE tá no README do repo.

Uma armadilha que perdi tempo descobrindo: mouses gamer 8000 Hz são incompatíveis com ARM modesto. Tinha um mouse Razer 8K HS plugado por padrão. Xorg saturava 37% de CPU só processando interrupts do mouse. Trocando por um mouse comum Compx 2.4G a 125 Hz, Xorg caiu pra 6-10%. Detalhe pequeno, impacto enorme.

Benchmarks reais

Pra caracterizar a B13 como ferramenta de uso real, rodei testes definitivos:

Térmica (stress-ng 4 cores, 5 min):

  • Idle: 40°C
  • Stress 100% com EMI shield com folga: pico 58°C
  • Stress 100% com shield apertado: pico 51°C
  • Sem throttling em nenhum cenário

Rede (iperf3, ethernet 100M):

  • Download: 93.4 Mbps
  • Upload: 94.1 Mbps
  • 1 retransmissão em 60s total

Satura 100% do hardware. Como confirmei via análise dos DTBs, a B13 é 100 Mbps por hardware (PHY interno do SoC, sem PHY gigabit externo).

eMMC (fio com --direct=1, em /root):

  • Read sequencial 4M: 140 MB/s
  • Write sequencial 4M: 65 MB/s
  • Random read 4k: 16 MB/s / 3940 IOPS
  • Random write 4k: 19 MB/s / 4726 IOPS

eMMC midrange/econômico. Bom o suficiente pra workloads de servidor (SQLite, NGINX, Node). Lento pra copiar arquivos grandes.

Tempo de boot total: 4.877 segundos (890ms kernel + 3.987s userspace).

Casos de uso reais — o que a B13 reciclada serve hoje

Depois de tudo testado, com honestidade técnica:

✅ Funciona muito bem como servidor low-power:

  • NGINX / Apache (Servidores Web)
  • Home Assistant
  • MQTT broker (Mosquitto)
  • SSH bastion / jump host
  • Docker leve (1-2 containers)
  • Node de cluster K3s
  • Cron jobs, backups, monitoramento

✅ Funciona como mini-desktop portátil pra tarefas leves:

Esta foi a expansão de escopo proposta pelo Prof. Lucas dos Santos Umeoka (IFPR Ivaiporã) quando comentei sobre o XFCE rodar razoavelmente bem depois das otimizações: usar a TV box reciclada pra programar Arduino. Faz total sentido — Arduino IDE é leve, a única exigência real é uma porta USB pra programar o microcontrolador, e a B13 tem 2 portas USB. Casos de uso similares onde a B13 atende:

  • Programação Arduino / ESP32 / microcontroladores (Arduino IDE roda razoavelmente em Debian + XFCE)
  • Edição de texto/código com editores leves (Geany, nano, vim, micro — VSCode é pesado demais)
  • Atividades educacionais de programação básica (Python, Scratch, Thonny)
  • Estação SSH terminal pra estudantes acessarem servidores remotos da instituição
  • Navegação web leve (Firefox abre, mas Chrome moderno satura — Falkon ou Midori são melhores escolhas)

Vira laboratório portátil de R$0 por estação — em vez de comprar 20 PCs novos pra uma sala de aula de Arduino, recicla 20 TV boxes que iam virar lixo eletrônico.

⚠️ Funciona com limitações:

  • WireGuard VPN (~30-50 Mbps, CPU é gargalo na crypto)
  • Servidor de arquivos LAN pequena (rede 100M = 12 MB/s teto)
  • Nextcloud pessoal leve

❌ NÃO serve pra:

  • Desktop com Firefox/Chrome moderno como uso primário
  • Mediabox 4K com Kodi (sem decode hardware no Mesa mainline)
  • Servidor de mídia com transcoding (Jellyfin/Plex)
  • Workstation Linux normal de uso diário

A pergunta natural é: "se no Android original funciona 4K perfeitamente, por que no Debian engasga?". Resposta: mesmo hardware, stacks de software diferentes. O Android tem o driver Mali r25p1 proprietário integrado ao V4L2 (decoder de vídeo do SoC), com zero-copy entre decoder e GPU. No Debian mainline ganhamos OpenGL ES via Panfrost (open-source) — perdemos a integração com V4L2 e algumas extensões proprietárias. A B13 não é pior — a stack mainline genérica é menos otimizada pra esse hardware específico que a stack Android oficial.

O que ficou pendente

Coisas que ainda quero atacar:

  • WiFi (Unisoc UWE5621DS): chip detectado pelo kernel mas com IDs zerados — falta DTB com power-on correto. Driver out-of-tree uwe5631-aml do CoreELEC existe mas precisa porte pra kernel 6.18. Por enquanto: dongle USB WiFi (R$20) ou ethernet.
  • Bluetooth: mesmo chip, mesma situação. Controle remoto da B13 é BT, então sem driver não tem controle remoto nativo.
  • Áudio HDMI: driver meson-aiu mainline tem suporte parcial pra SC2. Workaround: jack 3.5mm analógico (não testado) ou USB DAC.
  • Versão 2 do AmlBoot: pendrive auto-installer (sem precisar de UART). O setenv start_emmc_autoscript pode ser feito a partir de um bootscript embutido no pendrive — eliminando a barreira do ESP32 + soldagem. Isso é importante pra escalar pro lote inteiro do IFPR sem precisar abrir e soldar UART em cada TV box.
  • BTV E13: aplicar a mesma metodologia. Suporte mainline pra família S4 ainda é experimental, mas o approach da factory partition pode funcionar quando o kernel maturar.

Lições do processo

Algumas coisas que ficam pra próxima vez:

1. ESP32 é o adaptador UART perfeito pra hardware ARM 3.3V. Não precisa de FTDI ou CH340 dedicado, não precisa de level shifter, custa R$30. Tem GPIO sobrando pra projetos paralelos.

2. Sempre olhe a foto física do chip antes de assumir baseado no driver. O driver wifi MediaTek empacotado pela devmfc me fez acreditar por dias que o chip era MT7668. Era Unisoc.

3. Mouse gamer 8K HS é incompatível com ARM modesto. Em PC com Xeon ou Ryzen, 8000 Hz é luxo. Em Cortex-A55, é tortura.

4. EMI shield em TV box pirata frequentemente tem folga sobre o SoC. É projetado pra blindagem eletromagnética (compliance FCC/CE), não pra dissipação. Apertar ou colar thermal pad melhora 5-10°C sem custo.

5. A factory partition (mmc 1:6, "KEYBOX PART") da Amlogic é um vetor incrível pra hardware hacking. Originalmente serve pra armazenar chaves DRM do Android, mas é FAT12 escrível via Linux E lível pelo u-boot vendor. Resto da estrutura pode ser similar em outras TV boxes Amlogic.

6. Reciclar pra educar é uma proposta concreta, não filosofia abstrata. Brasil tem milhões de TV boxes piratas instaladas, e a Receita apreende lotes desses todo ano. Com a metodologia de boot autônomo via factory partition, viram mini-PCs Linux com 2GB RAM, 16GB storage, ethernet, HDMI 4K. Casos de uso reais pra ensino de eletrônica (Arduino), Linux, redes — e custo zero pra instituição.

Esse caso de uso — TV box pirata reciclada como ferramenta educacional — já tem precedente brasileiro. O projeto EducaBox do IFMS (Instituto Federal de Mato Grosso do Sul) documentou esse fluxo pra 29 modelos diferentes de TV box, com 3 famílias de SoCs (Amlogic, Allwinner, RockChip). Eles não tinham a BTV B13 nem a BTV E13 no catálogo deles. Esse trabalho preenche esse gap pra B13 e fica como base pra E13. Tem espaço pra uma colaboração entre o IFPR Ivaiporã e o IFMS no futuro — filosofia idêntica, modelos complementares.

Documentação completa

Tudo que descobri tá no repositório:

🔗 github.com/gabclima/b13

Lá tem:

  • TUTORIAL.md — procedimento passo a passo replicável (~500 linhas)
  • DIARIO.md — diário técnico completo com benchmarks, análises de DTB, descobertas detalhadas (~900 linhas)
  • scripts/ — bootscripts u-boot, sketch ESP32, config Xorg, systemd unit
  • imagens/ — fotos do hardware, screenshots AIDA64, fotos do processo de hacking

Se você tiver uma BTV B13 e quiser tentar, o tutorial é replicável em ~3 horas (incluindo soldagem dos pinos UART). Se tiver outro modelo Amlogic e quiser adaptar a metodologia, o diário tem detalhe suficiente pra você se virar.

Comentários, dúvidas, ou casos de uso interessantes — manda no issues do repo ou aqui mesmo nos comentários.

Agradecimentos

  • Prof. Me. Ronan Anacleto Lopes — coordenador do curso de Sistemas de Informação no IFPR Campus Ivaiporã, pela proposta inicial do projeto e por confiar o equipamento pra análise.
  • Prof. Lucas dos Santos Umeoka — IFPR Campus Ivaiporã, pela sugestão de expandir o escopo das TV boxes recicladas pra mini-desktops portáteis voltados a programação Arduino e atividades educacionais leves.
  • IFPR Campus Ivaiporã — pelo equipamento e pelo contexto institucional que viabilizou esse trabalho.
  • Projeto devmfc/debian-on-amlogic — base do pendrive Debian usado nas primeiras tentativas.
  • Projeto EducaBox / IFMS — inspiração filosófica e referência metodológica pra reciclagem educacional de TV boxes piratas.

Sobre o autor

Sou Gabriel Cezar Lima (ou apenas Gabriel Lima), discente do Curso de Bacharelado em Sistemas de Informação pelo IFPR Campus Ivaiporã, onde também sou egresso do Curso Técnico em Informática. Trabalho com projetos open-source há mais de 7 anos em áreas como Eletrônica, Robótica, Automação e IoT.

Mais sobre o que faço:

Esse foi um daqueles projetos que começam com "vou abrir só pra dar uma olhada" e terminam três dias depois com soldador na mão e backup do u-boot original em quatro lugares diferentes. Valeu cada hora.

Última atualização:

Marcado em:

tvbox, amlogic, arm, debian, hardware-hacking, tutorial, linux, reciclagem