four0four

Zynq BootROM Secrets: Exposing the bootROM with the UART loader

Last time I wrote about this, I lied a little - There is an interesting bug in the UART loader, and it may have been exactly why Xilinx didn't document it. In short: The UART loader writes the entire UART payload to a location in memory (nominally 0x4_0000). The ROM is architected such that when the boot mode is selected, it registers a callback that is called when the ROM wants more data from the boot device. For the UART loader, this is pretty simple - here's the whole thing:

; void uart_callback(u32 r0_offset, void* r1_dest, i32 r2_nbytes)
ROM:0000A578 PUSH            {R3,LR}
ROM:0000A57C MOV             R3, #uart_buff
ROM:0000A584 MOV             R12, #1
ROM:0000A588 LDR             R3, [R3]

four0four

Zynq BootROM Secrets: UART loader

Recently I acquired (md5: ADF639AFE9855EE86C8FAAD216C970D9) the Zynq bootrom, and during the reversing process uncovered some interesting secrets, one of which is an as-of-yet undocumented UART loader. As documented the Zynq bootrom will load from NOR/NAND/SPI flashes, eMMC/SDIO-based storage (unfortunately) not USB, or anything else more complex.

Not sure why Xilinx didn't document this. In my brief testing it is super unreliable if you just spit everything at once - they reset the RX/TX paths during the process, so timing is critical, but that might be the janky meter-long ftdi cable. You can change the baudrate during the process, but I was too lazy to do the math.

Here's the disassembly that made me look twice (that, and checks for the MIO boot_mode[2:0] that weren't specified in the docs :)):

ROM:0000A220 BL              uart_init

four0four

#include <stdint.h>
#include <string.h>
#include <avr/io.h>
#include <avr/interrupt.h>

/*
 * NA202MD08BC pinout:
 *    1     2
 * [-----|-----]
 * [ vcc | vcc ]

four0four

diff -Naur urjtag-2018.09.orig/bindings/python/chain.c urjtag-2018.09/bindings/python/chain.c
--- urjtag-2018.09.orig/bindings/python/chain.c	2018-09-25 14:32:40.583308869 -0700
+++ urjtag-2018.09/bindings/python/chain.c	2018-09-25 14:33:31.924518776 -0700
@@ -243,7 +243,7 @@
 urj_pyc_partid (urj_pychain_t *self, PyObject *args)
 {
     urj_chain_t *urc = self->urchain;
-    int partno;
+    unsigned int partno;
     if (!PyArg_ParseTuple (args, "i", &partno))

four0four

#!/usr/bin/env python3

from serial import Serial
from crcmod.predefined import mkPredefinedCrcFun

class PowerSupply():
    def __init__(self):
        self.v_set = 0.0
        self.i_set = 0.0

four0four

source [find cpu/arc/arcompact.tcl]
source [find cpu/arc/em.tcl]

set _CHIPNAME arc600
set _TARGETNAME $_CHIPNAME.cpu

jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -expected-id 0x200024b1

target create $_TARGETNAME arc600 -chain-position $_TARGETNAME 

four0four

/*  8 bit brainfuck cpu
**  Author's note: This is a really bad processor. It does all sorts of stupid/bad things in the aim of brainfucking hardware.
**  codeMem  -> 3 bit wire, input opcodes from code memory
**  codeAddr -> 8 bit address, current pc (usually)
**  dataMem  -> 8 bit read/write to the working array
**  dataAddr -> 8 bit address to working array 
**  !USE READ FIRST!
*/

four0four

#!/usr/bin/python2

import sys
import md5

if len(sys.argv) < 2:
  print "Usage: " + sys.argv[0] + " [eagle 7.5.0 binary]\nWindows patches will be applied if .exe"
  sys.exit()

# offsets

four0four

Keybase proof

I hereby claim:

• I am four0four on github.
• I am four0four (https://keybase.io/four0four) on keybase.
• I have a public key whose fingerprint is 6920 2A52 483C 3974 7EEB 64D7 8343 5753 3862 EFD9

To claim this, I am signing this object:

four0four

//-----------------------------------------------------------------------------
// This file is for use in Embedded Control when using the SDCC compiler
//
// Directions:
//
// This file should be saved to the following directory on your laptop:
// C:\Program Files\SDCC\include\mcs51
// Save as c8051_SDCC.h
//
// In your program, you need to include this header file as #include <c8051_SDCC.h>