sjgallagher2/am335xbootromEngenharia reversa da ROM de inicialização do TI AM3358
Já faz provavelmente dezoito meses desde que coloquei as mãos em algumas placas Beaglebone Black, salvas do lixo. Infelizmente, as placas não funcionaram de imediato. Bem, esta era a primeira vez que trabalhava com uma dessas placas, ou com qualquer computador de placa única, então não sabia se o problema era algo que eu estava fazendo ou algo errado com as próprias placas (talvez por isso estivessem indo para o lixo em primeiro lugar). Levei bastante tempo e um grande esforço para fazer essas placas realmente começarem a inicializar, mas, caramba, consegui. E aqui está o que aprendi ao longo do caminho.
Incluí alguns utilitários neste repositório, juntamente com um arquivo XML exportado do Ghidra que contém todos os símbolos que obtive até agora com a engenharia reversa. Usei este post para exportar sem o firmware real, evitando quaisquer problemas de direitos autorais, por precaução. Se você quiser depurar a boot ROM por conta própria, já terá o JTAG conectado, então poderá despejar a boot ROM (de 0x20000 a 0x2BFFF) você mesmo.
Para carregar os símbolos:
0x20000; você também pode definir o nome do bloco como bootrom.main(), ou para o handler de boot do cartão MMC/SD.Para começar, eu sabia que estas eram versões personalizadas do Beaglebone Black padrão, então desde cedo determinei que poderia ser algo faltando na própria placa, como um identificador de placa. O que eu via ao inicializar um cartão SD padrão formatado com balenaEtcher era simplesmente nada. Eu esperava que os LEDs da placa começassem a piscar e que conectar um cabo UART para USB me permitisse ver o processo do U-Boot. No entanto, a UART permanecia muda. Se eu removesse o cartão SD, ela emitia a letra C repetidamente, o que é um comportamento esperado para um boot UART/serial. Ela definitivamente estava tentando inicializar, e o cartão SD estava alterando esse comportamento, mas eu não tinha mais visibilidade. A maior parte da solução de problemas na web usava a saída do U-Boot como ponto de partida para diagnosticar problemas. Acho que eu não teria esse luxo.
Nesse ponto, imaginei que valeria a pena conectar uma sonda de depuração. Infelizmente, não tinha um conector compatível com o footprint existente, então fiz o meu próprio.
A placa Beaglebone tem um conector com designação P2 que expõe as conexões JTAG. Conectei alguns fios deste conector a um conector fêmea para poder me comunicar com ela por meio do meu J-Link.
Ao iniciar o Ozone (o depurador da Segger), configurei o J-Link e comecei apenas tentando encontrar o ponto de entrada. Eu pensava que um reset-halt me colocaria onde eu precisava, e foi assim que cheguei à suposição (incorreta) de que o ponto de entrada era 0x2148a, embora certamente tenha notado que isso não era consistente. Mais tarde, percebi que as placas AM335x não se dão muito bem com o reset-halt do J-Link, então havia na verdade um atraso de talvez algumas centenas de ciclos de clock, fazendo-me parar em algum lugar dentro de um handler de boot, de forma indeterminística. (Acabei contornando isso escrevendo um arquivo GEL para o Code Composer Studio da TI, que suporta depuração via J-Link — no reset, o registrador PC é definido para o handler de reset, os registradores são limpos e o modo de instrução é forçado para ARM.)
Em um tópico nos fóruns da TI (AM335x: Funcionários da TI, onde posso obter o código-fonte/símbolos do ROM Bootloader?) peguei alguns símbolos de depuração: SPI Initialize em 0x231e0, SPI ReadSectors em 0x23230, e 0x24bfa é uma rotina que executa uma leitura UART. Isso é uma boa ajuda, eu acho. Notei que o boot falhava ao cair em um loop infinito em 0x402f0440, um loop morto. Hmm, bem longe do restante da boot ROM, deve ser em RAM ou algo assim. Provavelmente é hora de ir para o manual de referência técnica (TRM)!
O Capítulo 26 do TRM contém uma tonelada de informações sobre boot. Temos a seguinte visão da boot ROM:
Descrição:
A arquitetura do Public ROM Code é mostrada na Figura 26-1. Ela é dividida em três camadas principais, em uma abordagem de cima para baixo: alto nível, drivers e camada de abstração de hardware (HAL). Uma camada se comunica com uma camada de nível inferior por meio de uma interface unificada. A camada de alto nível é responsável pelas principais tarefas do Public ROM Code: configuração do watchdog e dos clocks e a rotina principal de boot. A camada de drivers implementa os protocolos lógicos e de comunicação para qualquer dispositivo de boot, de acordo com a especificação da interface. Finalmente, a HAL implementa o código de nível mais baixo para interagir com os IPs da infraestrutura de hardware. Os dispositivos de boot finais são conectados aos pads de I/O do dispositivo.
A Figura 26-2 ilustra o fluxo de alto nível do procedimento de boot do Public ROM Code. Neste dispositivo, o Public ROM Code começa após a conclusão da inicialização segura (executada pelo Secure ROM Code). O ROM Code então realiza a configuração e inicialização da plataforma como parte do procedimento público de inicialização. A lista de dispositivos de boot é criada com base nos pinos SYSBOOT. Um dispositivo de boot pode ser um dispositivo de boot por memória (memória flash soldada ou um dispositivo de boot temporário, como um cartão de memória) ou uma interface periférica conectada a um host. O loop principal do procedimento de boot percorre a lista de dispositivos de boot e tenta procurar uma imagem no dispositivo de boot atualmente selecionado. Esse loop é encerrado se uma imagem de boot válida for encontrada e executada com sucesso, ou quando o watchdog expira. O procedimento de autenticação da imagem é realizado antes da execução da imagem em um dispositivo HS. A falha no procedimento de autenticação leva a um desvio para um "loop morto" na ROM Segura (aguardando um reset do watchdog).
Mapa de memória! Vetores de exceção! Fluxogramas! Muita informação nesta seção. Meu trabalho ficou muito mais fácil.