Um celular.
Outra vida.

A entrada no projeto foi um Mi 8 Lite com bootloader desbloqueado, condição confirmada por Fastboot e pela recovery. Essa verificação abriu a possibilidade de iniciar imagens de teste e, depois, gravar uma imagem de boot própria. Os registros sustentam a confirmação do desbloqueio, não uma nova execução da ferramenta de unlock nesta fase.

Antes das mudanças persistentes, houve backup e conferência de integridade de partições. A recovery OrangeFox foi mantida como caminho de recuperação. Partições de identidade, calibração e modem ficaram fora do escopo de escrita.

A bancada inicial usou o kernel comunitário SDM660 e ferramentas do ecossistema postmarketOS/Nura. Imagens temporárias permitiram observar o kernel e um console de diagnóstico por USB sem confundir esse ambiente com uma instalação Arch.

O primeiro obstáculo não era uma tela de login: era uma tela preta com a iluminação acesa. O kernel respondia, mas a imagem desaparecia. Manter clocks e reguladores ligados não resolveu o sintoma. O teste negativo ajudou a abandonar a hipótese errada.

Tela e toque compartilham o controlador TDDI NT36672A. O driver de touch reinicializava o chip e apagava a configuração de vídeo herdada do bootloader. Sem um driver completo do painel para reconstruí-la, a tela ficava preta.

Impedir o carregamento do driver original trouxe a imagem de volta. Em seguida, um módulo adaptado evitou o reset e o corte de alimentação durante sua inicialização. Imagem e multitoque foram confirmados fisicamente. O console continuou apoiado no framebuffer/simpledrm; isso não representa aceleração 3D da GPU.

O ADSP e o codec interno foram integrados ao caminho de áudio. O receptor frontal emitiu som e o microfone principal capturou fala reconhecível. O alto-falante inferior exigiu trabalho adicional no caminho ASoC, no amplificador TFA98xx e no pinmux MI2S.

Uma rota de áudio que aparecia ativa nos registros ainda não produzia som: os pinos não tinham sido atribuídos à função correta. A correção do pinmux tornou o falante audível, mas com volume baixo. Calibração e proteção CoolFlux seguem incompletas. Não foi considerado seguro promover volume máximo como recurso pronto.

O userspace oficial do Arch Linux ARM foi adaptado ao kernel e ao hardware do Platina. O caminho de inicialização passou a carregar o Arch, em vez do Android, com systemd como PID 1, pacman, usuário de trabalho e serviços persistentes.

A evolução incluiu correções no provisionamento, compatibilidade do initramfs, criação de usuário, console e passagem para a raiz real. O rootfs foi inicialmente acomodado na partição de sistema e depois migrado para uma árvore persistente em userdata, aproveitando o armazenamento maior sem uma nova formatação.

“Substituir o Android” aqui significa que ele deixou de ser o sistema inicializado. Não significa apagar todas as partições do fabricante: recovery, calibrações e firmware necessários foram preservados.

A base validada é o kernel 7.0.14-sdm660. Foram adaptados módulos, Device Tree e initramfs, mantendo compatibilidade de ABI. Até o tamanho da estrutura de módulo precisava coincidir: apenas ter o mesmo nome de versão não bastava para carregar um driver externo.

A integração do Wi-Fi exigiu revisar reguladores, memória reservada, MSS, dados de placa e serviços auxiliares. O firmware Qualcomm original foi reaproveitado e auditado, não reescrito. A partição que o contém foi usada somente para leitura; o RMTFS também permaneceu em modo de leitura.

Na V10, a configuração de UART e seu alias permitiu inicializar o controlador Bluetooth e carregar seu firmware. Isso comprovou a presença do HCI, mas não pareamento, áudio ou transferência.

O WCN3990 apresentou quedas de firmware durante a atividade do rádio. Foram confrontadas hipóteses sobre dados de placa, bandas, canais, capacidades, DMA, IOMMU e sequência de inicialização. Um monitor aparentemente estável, sem receber quadros, não foi aceito como prova de rede funcional.

Depois de alcançar busca e associação, surgiu outra barreira: o caminho de transmissão reportava HTT5, sem obter tráfego útil. A candidata com ajuste do ciclo VDEV_DOWN passou por compilação e testes offline, mas no re3 não obteve IPv4. No re4, atribuir um IP manualmente também não trouxe respostas na LAN.

O firmware WLAN foi estudado como ELF Qualcomm Hexagon, executado no DSP, não como código do kernel Linux. REA e Ghidra foram usados para descobrir funções e recuperar pseudocódigo; o assembly LLVM serviu como conferência independente.

A análise alcançou WLAN, CORE_USER e MBA. Imagens analíticas de ADSP e MODEM foram reconstruídas a partir de segmentos locais já inventariados, com validação de hashes. Para ADSP e MODEM, o resultado foi um overview de descoberta, não a descompilação integral de todas as funções.

Um achado importante: HTT5 não indicava exclusivamente “fila cheia” naquele firmware. A análise estática identificou outras origens possíveis do status. Ela estreitou a investigação, mas não provou qual ramo executou no teste físico. Pseudocódigo recuperado também não é o código-fonte original.

No re5, a combinação dos módulos candidatos com wpa_supplicant e DHCP separado completou autenticação WPA2/CCMP, obteve endereço e respondeu aos testes de tráfego LAN. Nenhuma linha HTT5 ou crash de modem foi registrada nessa tentativa.

A credencial existente foi reutilizada somente em memória, por pipe anônimo, sem ser impressa ou copiada para um novo arquivo. A primeira tentativa SSH chegou ao servidor, mas a chave do usuário foi recusada. A rede havia funcionado; a autorização SSH era um problema diferente.

A troca de supplicant estabeleceu um caminho funcional, mas não isolou sozinha a causa interna da falha com IWD. Estabilidade prolongada e desempenho máximo também não foram inferidos dessa amostra curta.

A autorização SSH foi corrigida preservando as chaves existentes e a autenticação exclusivamente por chave. A rede ganhou um gerenciador permanente, serviços separados, tentativas limitadas e tratamento de falha. Um teste detectou um problema na vigia: ela poderia parar o próprio gerenciador. O comportamento foi corrigido antes da integração.

A V11 preservou os bytes de kernel e Device Tree da base validada, incorporando as mudanças de userspace e initramfs. A imagem foi gravada somente em boot. Depois de um reboot autorizado, Arch, Wi-Fi automático e SSH pela WLAN foram comprovados novamente.

A releitura da imagem gravada confirmou seu SHA256. A recovery permaneceu com o mesmo hash. O estado “Arch instalado persistente” passou a ter prova tanto no processo de gravação quanto no sistema realmente iniciado.

O atalho SSH do Windows ainda apontava para uma ponte antiga por USB. Ajustar somente destino e porta permitiu entrar diretamente pela WLAN, com a mesma chave. Login e terminal remoto foram verificados separadamente.

O próximo trabalho foi transformar a infraestrutura em algo público: Docker ARM64, Nginx, arquivos estáticos e uma entrada HTTPS exclusiva para este projeto. O conteúdo fica no Mi 8 Lite; uma VPS cuida do certificado e encaminha as conexões por um túnel criptografado. O computador Windows não participa desse caminho.

Este site não representa um port completo de todos os periféricos. Ele representa o marco de um aparelho com Arch nativo que já pode servir um projeto real.