December Adventure 2025

I learned about December Adventure in the middle of December last year, which is probably quite typical. I don't think most people get the words out in sync with the hacking and so there is a delay. Obviously that didn't exclude me, it wasn't the spirit of the event after all, but I didn't have the capacity.

I thought I would make an attempt at December Adventure this year. I've been trying hard for a while to focus on about 1 thing at a time. I thought for DA this year I would try and make progress on this summers project: Port FreeBSD to the Allwinner H616.

This blogpost will update as I do stuff through December, so don't expect a real feed of updates. I want to keep the entry effort down to a minimum so most will be more running chain of thoughts rather than fully explained post. If you have questions send me an email and I'll add more detail until it makes sense. I am going to buck tradition and keep it in chronological order too.

Background

I was super intrigued by the Sipeed Nano Cluster when it was annouced and redacted video .

The Nano Cluster is a carrier board for up to 7 modules, with an integrated switch and network port. It is about the size of a small beer and fits in your hand. Sipeed designed 3 different modules that fit the form factor, a CM4/5 adapter, some AI SOC and a Allwinner H618 module based on the Orange Pi Zero3.

The H618 was the cheapest module on offer and Allwinner have a pretty good reputation of reasonable levels of hardware openness.

I ordered a cluster with two H618 modules to begin with, but the Sipeed project timeline wasn't very concrete. I wasn't really sure if these would ship in days or months and as it was June and I wanted a summer project I also went to Aliexpress and bought two different Android tv devices which advertised themselves as using the H616. Delivery times for me for Aliexpress stuff is somewhere between 1 day and 1 month so I thought I'd have a target to get started with.

You may have noticed me jumping between using H618 and H616, well that is because I couldn't keep the numbers straight in my head at all. In the end it turned out that the H616, H616 and H700 are all very similar and need the same hardware support. The H700 is actually in the Anbernic gaming device I got last year.

Anyway, with hardware bought and on its way to my home in Scotland I had to leave the country for the next three months on very short notice.

Summer 2025

Separated from hardware I was able to do some of the inital work on a port. I acquired the Nano Cluster files from Sipeed, but didn't look at them. I went digging into the first thing you need for an embedded port and acquired a device tree (source) file for the h616.

From there I was able to make a table mapping out which device tree nodes will be support by which existing drvier in FreeBSD. A lot of the time support is a matter for adding a compat string to a table and maybe some supporting data from the datasheet.

I got to the point where I had a table like this:

dts file: sun50i-h616.dtsi

mmio-sram
snps,dwmac-mdio
sun50i-h616-ccu                 per soc
sun50i-h616-crypto
sun50i-h616-dma                 a10_dma, a31_dmac (h3 config)
sun50i-h616-ehci
sun50i-h616-emac0               if_awg                  test
sun50i-h616-emmc                aw_mmc                  test
sun50i-h616-gpadc
sun50i-h616-i2c
sun50i-h616-iommu
sun50i-h616-ir                  aw_cir                  test
sun50i-h616-lradc
sun50i-h616-mmc                 aw_mmc                  test
sun50i-h616-musb
sun50i-h616-nmi                 aw_nmi                  not sure what this needs isn't in datasheet
sun50i-h616-ohci
sun50i-h616-pinctrl             aw_gpio
sun50i-h616-r-ccu
sun50i-h616-r-pinctrl
sun50i-h616-rsb                 aw_rsb                  needs config values
sun50i-h616-rtc                 aw_rtc                  need to check h3 table is correct
sun50i-h616-sid                 aw_sid                  needs config table (check linux)
sun50i-a64-sid
sun50i-h616-spdif               h3_padconf (and others)
sun50i-h616-spi
sun50i-h616-system-control      aw_syscon
sun50i-h616-ths                 aw_thermal              needs config table
sun50i-h616-usb-phy             aw_usbphy               needs config table
sun50i-h616-wdt                 aw_wdog                 needs config values
arm,cortex-a53
arm,gic-400
cache
snps,dw-apb-uart
arm,armv8-timer
arm,cortex-a53-pmu
arm,psci-0.2
fixed-clock
simple-bus

and the supporting patches for the changes I had made. This was a good to do list.

Then rather than getting to a point where I had builds, but no device I swapped summer project from "write some code" to read 15 books. This was cathartic and it finally settled a question from the last time I had a block of time off - yes reading a lot of books is good, but it doesn't leave you full, you have to do other things.

After Summer

Once I finally made it home I unpacked the hardware, took the android boxes apart and photographed their insides (I'll add these pictures soon). The two devices were basically identical, they have a cool led panel on the front driven by gpio showing wifi status and disk access.

One is called a "H96 Max" or H96 for any files I dump from it, it has a blue PCB and the other is T95 Pro and it has a black PCB. Both boards have a pin header on the board by the SD card slot labeled with RX, TX, GND.

I connected PCB Bite probes to each and booted them up. They are both running android and drop you to a shell once they have booted. The H96 gave me a root shell, whereas the T95 gave me a user shell, so the H96 is going to get all the initial attention.

The H96 is very noisy once it has booted, I resolved [this by changing a logging sysctl] (https://superuser.com/questions/351387/how-to-stop-kernel-messages-from-flooding-my-console):

    sysctl -w kernel.printk="3 4 1 3"

I wasn't able to break into uboot on either device, as far as I can tell from reading the uboot sources, you should be able to break into its prompt if it shows you "Hit any key to stop autoboot", but I couldn't manage.

With root on the system I instead dumped out uboot configuration from the emmc and used set to rewrite the autoboot delay field from 0 to 10. This didn't work, but it didn't work enough to stop the system booting, leaving me at a uboot prompt (so a win I guess?).

I saved a copy of the strings output of the uboot binary image I dumped, but in a fat fingered moment I overwrote the good original uboot config.

So that left me with a device I could boot and could access the uboot prompt on. That is more than enough to do a port from.

November Warm up

I realised December Adventure was coming and I killed the power supply in my other evening project really knocking my enthusiasm down a bit.

I set out to get a working development set up for the H96 before December started so I wouldn't be too bogged down.

I set up a usb serial adapter hanging off uart I soldered a header to. I added in an sdwire sd-mux board which allows you to share an sd card between a DUT and as TS. Finally to enable remote working on the device I added a pi pico running micropython and a relay to control power, giving me a remote off switch. This is really handy when you need to reboot a system from cold power on.

At some point I pulled a FDT off the board with something like:

# cat /sys/firmware/devicetree | nc host port

With that in place I then got the Sipeed sources building as a close enough initial target and copied out that uboot onto a PINE64-LTS FreeBSD 16 image.

FreeBSD provides aarch64 images, but Arm platforms are still a mess in the DTS world and all require boot firmwares in different places. I checked through all the build configs ( src/release/arm64/*config ) and verified that the PINE64-LTS image has enough space before the first data partition to fit the Allwinner uboot.

With all that background we can now move into the December Adventure log:

20251129

Image I built yesterday onto the freebsd pine64-lts image didn't boot. It is probably because I didn't set up the mdconfig image with sectors.

I tried copying to the sd card directly like so:

 sudo dd if=build/u-boot-sunxi-with-spl.bin of=/dev/da3 bs=1024 seek=8 conv=sync

And managed to hit a useful error:

U-Boot SPL 2024.01-rc2-00076-g94b814f631e (Nov 28 2025 - 16:42:46 +0000)
DRAM:This DRAM setup is currently not supported.                        

resetting ...

I thought that maybe the h616 was like a NXP platform and that firmware specifics set the DRAM size and I spent a bit of time looking at ways the size might be configured. There isn't anything that responsible in the working dts, the memory section is commented out and the extracted dts doesn't indicate a range.

The extracted DTS doesn't build, which is its own issue for later.

I eventually grepped in the u-boot sources.

This hits a pretty unique bit of u-boot for this platform, which I have no idea what is needed to resolve.

For each type of memory there is a possible selection of bus widths and ranks. I'm not sure what ranks here means, so it is time to go to the datasheet.

The datasheet section on SDRAM is 1 page of bullet points.

There is a set of registers (20k) for DRAM_CTRL

If the datasheet is no help I think I need to enable debug prints from u-boot. afsaf debug is defined in log.h and is enabled if DEBUG is defined in a file.

20251130

There is basically nothing in the user manual about the usage of the DRAM controller. This ties up really well with a comment or commit message in u-boot where the author says most values just come from the boot0 logs.

So now to enable debug on uboot and start littering the sun50iw9 paths with prints to see what actually happens before this DRAM error.

I am going to set the device tree back to the longan pi 3 one for test builds.

sudo sd-mux-ctrl --ts -e da12 
sudo sd-mux-ctrl --dut -e da12

The first u-boot path came from the longan build scripts, this dd pulls u-boot from the actual build dir.

    sudo dd if=build/uboot/u-boot-sunxi-with-spl.bin of=/dev/da3 bs=1024 seek=8 conv=sync

The value to define to get debug_ printfs is _DEBUG

/* Show a message if DEBUG is defined in a file */
#define debug(fmt, args...)                     \
        debug_cond(_DEBUG, fmt, ##args)

That gets us:

U-Boot SPL 2024.01-rc2-00076-g94b814f631e-dirty (Nov 30 2025 - 09:44:30 +0000)
DRAM:testing 32-bit width, rank = 2
read calibration failed!
testing 32-bit width, rank = 1
read calibration failed!
testing 16-bit width, rank = 2
read calibration failed!
testing 16-bit width, rank = 1
read calibration failed!
This DRAM setup is currently not supported.

resetting ...

More debug prints indicate that u-boot things this is lpddr4, but the boot0 log has:

[94]DRAM_VCC set to 1500 mv
[97]DRAM CLK =648 MHZ
[99]DRAM Type =3 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4)
[107]Actual DRAM SIZE =4096 M
[110]DRAM SIZE =4096 MBytes, para1 = 310b, para2 = 10000000, dram_tpr13 = 6041
[123]DRAM simple test OK.

So maybe this error is due to detecting the wrong ddr type somewhere.

Our copied u-boot defconfig has:

CONFIG_MACH_SUN50I_H616=y
# CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER is not set
CONFIG_ARM_BOOT_HOOK_RMR=y
CONFIG_SUNXI_DRAM_LPDDR4=y

There isn't an unset version for ddr3, inventing one in the config breaks the build so there is some digging to do. The ddr3 config that uboot ships has the memory speed at 1333MHz, boot0 indicates the memory speed is much lower, but maybe we can just hacking this to work?

For some reason the uboot build is failing, but without stoping the makefile, which is pretty annoying. The real result is a lack of an output binary in the u-boot directory.

building u-boot constantly:

gmake clean; gmake sun50iw9-h616-h96_defconfig
gmake -j 16

Progress to a hang:

U-Boot SPL 2024.01-rc2-00076-g94b814f631e-dirty (Nov 30 2025 - 10:32:46 +0000)
DRAM:testing 32-bit width, rank = 2
mctl_phy_init:885 DDR3
mctl_phy_init:1114 READ CALIBRATION
read calibration failed!
testing 32-bit width, rank = 1
mctl_phy_init:885 DDR3
mctl_phy_init:1114 READ CALIBRATION
mctl_phy_init:885 DDR3
mctl_phy_init:1114 READ CALIBRATION
mctl_phy_init:885 DDR3
mctl_phy_init:1114 READ CALIBRATION
mctl_phy_init:885 DDR3
mctl_phy_init:1114 READ CALIBRATION
MBUS port 0 cfg0 0100000d cfg1 00640080
MBUS port 1 cfg0 06000009 cfg1 01000578
MBUS port 2 cfg0 0200000d cfg1 00600100
MBUS port 3 cfg0 01000009 cfg1 00500064
MBUS port 4 cfg0 20000209 cfg1 1388157c
MBUS port 5 cfg0 00640209 cfg1 00200040
MBUS port 6 cfg0 00640209 cfg1 00200040
MBUS port 8 cfg0 01000009 cfg1 00400080
MBUS port 11 cfg0 01000009 cfg1 00640080
MBUS port 14 cfg0 04000009 cfg1 00400100
MBUS port 16 cfg0 2000060d cfg1 09600af0
MBUS port 21 cfg0 0800060d cfg1 02000300
MBUS port 25 cfg0 0064000d cfg1 00200040
MBUS port 26 cfg0 20000209 cfg1 1388157c
MBUS port 37 cfg0 01000009 cfg1 00400080
MBUS port 38 cfg0 00640209 cfg1 00200040
MBUS port 39 cfg0 20000209 cfg1 1388157c
MBUS port 40 cfg0 00640209 cfg1 00200040
 4096 MiB

The ddr3 config option carrying a speed is pretty annoying. It is only considered in two places, one sets the type and the other is blob:

 static const u8 phy_init[] = {                         
 #ifdef CONFIG_SUNXI_DRAM_H616_DDR3_1333                
         0x07, 0x0b, 0x02, 0x16, 0x0d, 0x0e, 0x14, 0x19,
         0x0a, 0x15, 0x03, 0x13, 0x04, 0x0c, 0x10, 0x06,
         0x0f, 0x11, 0x1a, 0x01, 0x12, 0x17, 0x00, 0x08,
         0x09, 0x05, 0x18                               
 #elif defined(CONFIG_SUNXI_DRAM_H616_LPDDR3)           
         0x18, 0x06, 0x00, 0x05, 0x04, 0x03, 0x09, 0x02,
         0x08, 0x01, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
         0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x07,
         0x17, 0x19, 0x1a                               
 #elif defined(CONFIG_SUNXI_DRAM_H616_LPDDR4)           
         0x02, 0x00, 0x17, 0x05, 0x04, 0x19, 0x06, 0x07,
         0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
         0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x01,
         0x18, 0x03, 0x1a                               
 #endif                                                 
 };

With no documentation, I'm not really sure what to do to get a compatible u-boot built. I can getting hold of the stock u-boot the board shipped with, either by chasing down whatever might be on the aliexpress listing from 6 months ago (lol), or by dumping u-boot from android and having a look at a disassembly.

I checked mount in android to find somewhere writable, this was /data/media

dd if=/dev/block/mmcblk0 of=h96rawdisk1M.img bs=1M count=1

and then I configured a static address to a test machine and used nc to copy the uboot dump off the device.

Then I dropped the first 8k of the disk to get a uboot blob:

dd if=h96rawdisk1M.img of=h96uboot.img bs=1024 iseek=8 conv=sync

this might not actually be all of uboot, but whatever.

Honestly, this is pushing what I can do with hardware re. I'm just not able to eyeball instructions out of an aarch64 hexdump yet.

I should switch to booting FreeBSD from an sd card using the vendor uboot, but maybe I could poke at this using radare2.

I mean, I might just need a series of writes to PHYS_CTRL 0x0480000 , surely that shouldn't be too hard to pull from uboot?

I spent the evening reading the radar2 book and looking up RE projects on uboot. While I was doing this the sunxi wiki was down, but later in the day it came back up.

The boot wiki page informated me that DRAM parameters are set between the board vendor and Allwinner using special tools, but they are carried as a configuration file at the start of the SPL boot loader.

That explains the DRAM.ext file in the uboot blob I extracted and gives me a final (I promise) thing to try before paying attention to the port again.

20251201

I wrote up all my existing notes and added 1800 words - which hasn't really matched the "make entries easy" goal.

Installed sunxi-tools.

From yesterdays last minute discovery that there was tooling to help on the wiki I read more of the wiki pages on early boot.

The boot0 page includes a header for the boot0/spl, this is helpful for looking at the dump I took, even if I don't really need it.

    Offset  Name    Size    Notes
    0x00    B_INS   4       Branch instruction to Code Starting Point
    0x04    Magic   8       Ascii string "eGON.BT0" (No Null-terminated )
    0x0c    Checksum        4       Simple 4-bytes Checksum (Before calculate checksum this must be 0x5F0A6C39 )
    0x10    Size    4       Size of Boot0, it's must be 8-KiB aligned in NAND and 512-Bytes aligned in MMC
    0x14    Code    -       Code of SPL. The size depends on the processor and if it 's loaded from SPI, NAND or MMC

The DRAM settings sunxi wiki page has a link for getting parameters from boot0 https://linux-sunxi.org/U-Boot#DRAM_Settings, this is using 'sunxi-fw' which isn't in sunxi-tools on freebsd.

A little Makefile hacking later:

    diff --git a/Makefile b/Makefile
    index 8c16c01..23fe451 100644
    --- a/Makefile
    +++ b/Makefile
    @@ -1,6 +1,6 @@
     SH=/bin/sh
    -CC=${CROSS_COMPILE}gcc
    -CFLAGS=-Wall -g -O
    +CC=${CROSS_COMPILE}cc
    +CFLAGS=-Wall -g -O -I/usr/include -I/usr/local/include
     PREFIX ?=/usr/local
     all: sunxi-fw

And I had a working tool. Pointing it at my extracted uboot bits from the h96 showed something:

    $ ./sunxi-fw/sunxi-fw info -a h96rawdisk1M.img
    @   0: mbr: DOS MBR
            protective MBR, GPT used
            GPT version 00010000
            usable disk size: 29783 MB
            number of partition entries: 17
    @  16: boot0: Allwinner boot0
    @ 512: boot0: Allwinner boot0

but it wasn't great compared to the uboot I built myself:

    $ ./sunxi-fw/sunxi-fw info -a ../LonganPi-3H-SDK/build/uboot/u-boot-sunxi-with-spl.bin 
    @   0: spl: U-Boot SPLv2
            DT: sun50i-h618-longanpi-3h
    @  64: fit: U-Boot FIT image
            fit:uboot: "U-Boot (64-bit)"
            fit:atf: "ARM Trusted Firmware"
            fit:fdt-1: "sun50i-h618-longanpi-3h"
            configuration: sun50i-h618-longanpi-3h

The eGON header is there in the dump, so I am not really sure what is wrong. Lets park that for now. The sdmux is painfully slow to dd a full image to, so last night as a last thing I left the computer copying over a fresh PINE64-LTS image, which shouldn't be able to boot at all.

Lets try and boot a kernel from the vendor uboot using the vendor uboot.

20251202

If I am going to use the vendor uboot then I can start working on getting a kernel booting at all from uboot. I have done this a ton of times on different boards and so I tried to track down an example command.

The best I could do was this:

fatload mmc 1:1 0x48000000 dtb/starfive/jh7110-visionfive-v2.dtb
fatload mmc 1:1 0x44000000 efi/boot/bootriscv64.efi
bootefi 0x44000000 0x48000000

fdt_addr_r=0x51ff8000
kernel_addr_r=0x50200000

fatload mmc 0:1 0x51ff8000 dtb/bl808-pine64-ox64.dtb
fatload mmc 0:1 0x50200000 efi/boot/bootriscv64.efi
bootefi 0x50200000 0x51ff8000

from my (unpublished) artilce on running FreeBSD on the Pine Ox64 riscv SBC.

It is all pretty straight forwards until we hit the bootefi command. I doubt the uboot on the h96 has this. There are other options to boot a loader or kernel, I'd prefer to use a efi loader if I can.

I aimed to do more in the evening at the hackerspace, but a stop off at Aldi on the way and forgetting a usb-c cable for my ridiculous setup stopped that.

20251202

The best I could do was this:

    fatload mmc 1:1 0x48000000 dtb/starfive/jh7110-visionfive-v2.dtb
    fatload mmc 1:1 0x44000000 efi/boot/bootriscv64.efi
    bootefi 0x44000000 0x48000000

    fdt_addr_r=0x51ff8000
    kernel_addr_r=0x50200000

    fatload mmc 0:1 0x51ff8000 dtb/bl808-pine64-ox64.dtb
    fatload mmc 0:1 0x50200000 efi/boot/bootriscv64.efi
    bootefi 0x50200000 0x51ff8000

from my (unpublished) artilce on running FreeBSD on the Pine Ox64 riscv SBC.

I aimed to do more in the evening at the hackerspace, but a stop off at Aldi on the way and forgetting a usb-c cable for my ridiculous setup stopped that.

20251203

Lets take a dump of the available uboot commands on the h96:

    Hit any key to stop autoboot:  0
    => help
    ?       - alias for 'help'
    base    - print or set address offset
    bdinfo  - print Board Info structure
    boot    - boot default, i.e., run 'bootcmd'
    bootd   - boot default, i.e., run 'bootcmd'
    bootm   - boot application image from memory
    bootp   - boot image via network using BOOTP/TFTP protocol
    cmp     - memory compare
    colorbar- show colorbar
    coninfo - print console devices and information
    cp      - memory copy
    crc32   - checksum calculation
    echo    - echo args to console
    editenv - edit environment variable
    efex    - run to efex
    env     - environment handling commands
    erase   - erase FLASH memory
    fastboot- fastboot - enter USB Fastboot protocol
    fatinfo - print information about filesystem
    fatload - load binary file from a dos filesystem
    fatls   - list files in a directory (default /)
    fatsize - determine a file's size
    fatwrite- write file into a dos filesystem
    fdt     - flattened device tree utility commands
    flinfo  - print FLASH memory information
    go      - start application at address 'addr'
    gpt     - GUID Partition Table
    help    - print command description/usage
    i2c     - I2C sub-system
    itest   - return true/false on integer compare
    loadb   - load binary file over serial line (kermit mode)
    loads   - load S-Record file over serial line
    loadx   - load binary file over serial line (xmodem mode)
    loady   - load binary file over serial line (ymodem mode)
    logo    - show default logo
    loop    - infinite loop on address range
    md      - memory display
    memtester- start application at address 'addr'
    mm      - memory modify (auto-incrementing address)
    mmc     - MMC sub system
    mmcinfo - display MMC info
    mw      - memory write (fill)
    nfs     - boot image via network using NFS protocol
    nm      - memory modify (constant address)
    pbread  - read data from private data
    poweroff- Perform POWEROFF of the device
    printenv- print environment variables
    protect - enable or disable FLASH write protection
    pst     - read data from secure storageerase flag in secure storage
    reset   - Perform RESET of the CPU
    run     - run commands in an environment variable
    saveenv - save environment variables to persistent storage
    screen_char- show default screen chars
    setenv  - set environment variables
    setexpr - set environment variable as the result of eval expression
    sleep   - delay execution for some time
    source  - run script from memory
    sprite_test- do a sprite test
    sunxi_axp- sunxi_axp sub-system
    sunxi_bmp_info- manipulate BMP image data
    sunxi_bmp_show- manipulate BMP image data
    sunxi_card0_probe- probe sunxi card0 device
    sunxi_flash- sunxi_flash sub-system
    sunxi_nand_test- sunxi_nand_test sub systerm
    sunxi_so- sunxi_so sub-system
    tftpboot- boot image via network using TFTP protocol
    timer_test- do a timer and int test
    timer_test1- do a timer and int test
    uburn   - do a burn from boot
    version - print monitor, compiler and linker version

There are some new sunxi_ commands there, but nothing for usb. Try as I might I can't get uboot to pick up the sd card I have inserted. Trying a USB stick gives me:

    [00.796]usb prepare ok
    [01.599]overtime
    [01.603]do_burn_from_boot usb : no usb exist
    [01.607]boot_gui_init:start
    FAT: Misaligned buffer address (bbe78ad8)
    32 bytes read in 4 ms (7.8 KiB/s)
    tcon_de_attach:de=0,tcon=2[01.891]boot_gui_init:finish
    [01.895]bmp_name=bootlogo.bmp

Maybe the other port will work, but the cat is insisting that I remain seated. There is a lack of a usb command in the help output. Also missing from this uboot is an fel command to drop back into the default loader.

At this point I might have hit enough walls trying to get this board to boot and should probably try something else. Not being able to get the dram parameters despite seemingly having all the right tools is frustrating.

I had a look again at the cluster boards and they seem like much more annoying targets for doing bring up. A nice thing about this random h96 thing is that I am already controlling it with a relay and can reflash the sd card remotely, it just doesn't work. Maybe I can get enough ddr3 parameters together to make progress.

I don't want to give up yet. Looking at my list of commands and I noticed the fdt command. Running fdt print generated a 6000 line output file!

This seems to include the same parameters I could get with the sunxi-fw tool, but I'm not sure if this maps to the magic bytes I need to configure for the phy.

Thinking about this more while brushing my teeth and I really might only need to know the phy init sequence. This feels like a great chance to try using radare2 on a target. I have a clear goal, get the writes to a certain address, and a lot of supporting facts already, register map and many common values.

20251204

Time to hit the book . There is a handy firmware section of the radare2 book and it helpfully tells you to not bother with the project support.

The reason for not using projects is because usually these targets
require some special setups, custom scripts, manual tries and errors
and obviously not using the default autoanalysis.

The firmware section shows initial set up and some tricks, but it is probably a requirement to read more of the book to know what is happening and what to do next.

I need to both learn radare2 and some more facts about the soc and where it places things early in boot.

We know what upstream uboot does to set up dram, the code leading to the phy_init copy is:

writel(val, SUNXI_DRAM_PHY0_BASE + 0x14);                
writel(val, SUNXI_DRAM_PHY0_BASE + 0x35c);               
writel(val, SUNXI_DRAM_PHY0_BASE + 0x368);               
writel(val, SUNXI_DRAM_PHY0_BASE + 0x374);               

writel(0, SUNXI_DRAM_PHY0_BASE + 0x18);                  
writel(0, SUNXI_DRAM_PHY0_BASE + 0x360);                 
writel(0, SUNXI_DRAM_PHY0_BASE + 0x36c);                 
writel(0, SUNXI_DRAM_PHY0_BASE + 0x378);                 

writel(val2, SUNXI_DRAM_PHY0_BASE + 0x1c);               
writel(val2, SUNXI_DRAM_PHY0_BASE + 0x364);              
writel(val2, SUNXI_DRAM_PHY0_BASE + 0x370);              
writel(val2, SUNXI_DRAM_PHY0_BASE + 0x37c);              

ptr = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0xc0);              
for (i = 0; i < ARRAY_SIZE(phy_init); i++)               
    writel(phy_init[i], &ptr[i]);                    

if (para->tpr10 & TPR10_CA_BIT_DELAY)                    
    mctl_phy_ca_bit_delay_compensation(para, config);

We have these constants from uboot and the base address matches up with the datasheet.

#ifdef CONFIG_MACH_SUN50I_H616
#define SUNXI_DRAM_COM_BASE             0x047FA000
#define SUNXI_DRAM_CTL0_BASE            0x047FB000
#define SUNXI_DRAM_PHY0_BASE            0x04800000
#endif

From the table above we know the first 4 bytes should be a branch from the boot0 header to code. If I swap the r2 mode from 64 bits to 32 (though this feels like a proble of its own, certainly it indicates a knowledge gap), when we get some sensible disassembly for the first instruction.

 0x08000000      be0400ea       b 0x8001300                 ; pc=0x8001300 -> 0xeaffffff

Lots of questions from these first steps:

how does aarch64 boot?
- is it in 32bit mode
how to search for addresses in assembly in radare2
how can I get up to speed on aarch64 assembly quickly?
- (oh shit, I have a book on it

The book isn't really any help, it is a programming book rather than an architecture or systems reference. It is remarkably difficult to find aarch64 instruction encoding information, but wikipedia at least says:

Instructions are still 32 bits long and mostly the same as A32 (with
LDM/STM instructions and most conditional execution dropped)

I don't think the processor has started in 32 bit mode. Instead r2 is having trouble with that first branch.

The header is:

00000000  be 04 00 ea 65 47 4f 4e  2e 42 54 30 bf 3a 40 9d  |....eGON.BT0.:@.|
00000010  00 00 01 00 30 00 00 00  00 00 00 00 00 00 02 00  |....0...........|
00000020  00 00 02 00 00 00 00 00  00 00 00 00 34 2e 30 00  |............4.0.|
00000030  00 00 00 00 03 00 00 00  88 02 00 00 03 00 00 00  |................|

so the first instruction is:

be 04 00 ea

[0x08000000]> e asm.arch=arm
[0x08000000]> e asm.cpu=v8
[0x08000000]> e asm.bits=64
[0x08000000]> pd 1
        0x08000000      be0400ea       ands x30, x5, x0, lsl 1     ; lr=0x0 ; zf=0x1 ; nf=0x0 ; cf=0x0 ; vf=0x0
[0x08000000]> e asm.bits=32                                                                                        
[0x08000000]> pd 1
    ┌─< 0x08000000      be0400ea       b 0x8001300                 ; pc=0x8001300 -> 0xeaffffff

So one of these is doing something that makes sense and the other isn't. I find this so confusing that I tried using capstone, which I think underlies radare2 for disassembly manually:

$ cstool arm64 be0400ea        
 0  be 04 00 ea  ands   x30, x5, x0, lsl #1

when that didn't give me the answer I wanted I tried some online disassemblers, but they all gave me the same result. This mystery will persist until I can find someone to ask what is going on.

So, lets say the first opcode is an immediate jump to #1300, which makes sense. How do I look through the rest of this binary for my addresses of interest using r2?

It seems that r2asm can't disassemble from a file:

$ rasm2 -a arm -b 32 -f h96uboot.img   
ERROR: Cannot assemble '' at line 1                              
$ rasm2 -a arm -b 32 -D -f h96uboot.img
WARN: Invalid hexpair string

And neither can cstool, but it can give you detailed info on an instruction:

$ cstool -d arm be0400ea
 0  be 04 00 ea  b      #0x1300
    ID: 11 (b)
    op_count: 1
        operands[0].type: IMM = 0x1300
    Registers read: pc
    Registers modified: pc
    Groups: branch_relative arm jump

And rasm2 can tell you what a pneumonic means:

$ rasm2 -a arm -b 64 -w b                       
branches the program counter to dst (pc aka r15)

So, lets pretend everything is fine and just continue in 32 bit mode for today.

I next need to ask people some questions about Allwinner SOC start up and figure out how to search for accessed addresses in r2.

I did a little more reading after shutting down the computers for the night and found some uboot documentation which is pretty clear about the A64 start up process:

Newer Allwinner SoCs feature ARMv8 cores (ARM Cortex-A53) with support for
both the 64-bit AArch64 mode and the ARMv7 compatible 32-bit AArch32 mode.
Examples are the Allwinner A64 (used for instance on the Pine64 board) or
the Allwinner H5 SoC (as used on the OrangePi PC 2).

These SoCs are wired to start in AArch32 mode on reset and execute 32-bit
code from the Boot ROM (BROM). As this has some implications on U-Boot, this
file describes how to make full use of the 64-bit capabilities.

That explains exactly what I am seeing. Next I need to figure out how the transition to 64-bit mode happens and identify that in the disassembly. I'm not aware of any debugging tools that handle mixed mode executables well, most choke on the entire notion of the instruction set changing.