Analysis of bootloader

dj53144 · August 3, 2025, 7:34pm

Milk-V Megrez Bootloader Analysis Report

1. Overview

Bootloader Binary: bootloader_milkv-megrez-2025-0224.bin
U-Boot Version: 2024.01-gc9221cf2 (compiled Feb 24 2025)
Architecture: RISC-V (RV64IMAFDC_ZBA_ZBB)
Key Features:
- Supports eMMC/SD, USB, SATA, NVMe, and Ethernet boot.
- Includes U-Boot Boot Menu (interactive).
- Device Tree (DT) warnings suggest minor compatibility issues.

2. Key Findings

A. U-Boot Details

Version: U-Boot 2024.01-gc9221cf2 (likely customized by Milk-V).
Boot Methods:
- Distro Boot: extlinux, PXE, EFI.
- Scripts: boot.scr or extlinux.conf support.
- Boot Devices: MMC (eMMC/SD), USB, SATA, NVMe, Ethernet.
Warnings:
- Device tree includes old 'u-boot,dm-' tags: please fix by 2023.07! (DT needs updates).
- WARNING: could not set u-boot,version %s. (non-critical).

B. Hardware Initialization

DRAM: 16GB (from DTS, memory@80000000).
Storage:
- eMMC (8-bit, HS400) at mmc@50450000.
- SD Card (4-bit) at sd@50460000.
Debug UART:
- UART0: serial@50900000 (likely 115200 baud, stdout-path).

C. Boot Flow

SPL: Initializes DRAM, loads U-Boot proper.
U-Boot:
- Loads kernel/DTB from configured boot source (e.g., extlinux.conf).
- Supports fallback to USB/SD if primary boot fails.
Kernel: Handed control with bootargs (rootfs location, etc.).

3. User-Accessible Features

U-Boot CLI: Interrupt boot to access command line (e.g., modify bootcmd).
Boot Menu: Interactive menu (visible via UART).
Custom Boot: Override bootcmd to load custom kernels/DTBs.

4. Known Issues

Deprecated DT Tags: Old u-boot,dm-* tags need updating (non-breaking but recommended).
UART Debugging: Ensure correct baud rate (likely 115200) and 3.3V TX/RX.

5. Next Steps

Extract U-Boot: Use dd/binwalk to isolate U-Boot from the binary.
Disassemble: Analyze with riscv64-unknown-elf-objdump.
Debug UART: Capture boot logs to verify hardware init.
Update DTS: Modernize u-boot,dm-* tags for compatibility.

6. Resources

U-Boot Source: Check Milk-V’s GitHub for gc9221cf2 commit.
Pinout: Verify UART/GPIO pins from schematics (if available).
Community: Share findings with Milk-V forums for collaborative fixes.

Here’s a memory/section map of the bootloader_milkv-megrez-2025-0224.bin file based on the binwalk and strings analysis:

Bootloader Binary Section Map

File: bootloader_milkv-megrez-2025-0224.bin

Offset (Hex)	Size (Bytes)	Section/Content	Description
`0x00000`	`~0x61720`	U-Boot SPL	Secondary Program Loader (DRAM init, loads U-Boot proper).
`0x61720`	`40481`	Flattened Device Tree (DTB)	Hardware description (CPU, peripherals, clocks). Extracted as `devicetree.dtb`.
`0x244058`	`~0x90B88`	U-Boot Proper	Main U-Boot binary (2024.01-gc9221cf2). Contains boot logic and CLI.
`0x2D4C40`	`~0x66D28`	Bitmap/Logo Data	Boot logo (256x144, Windows 3.x format). Likely unused.
`0x2FBE10`	`~0x17D18`	Android Boot Header	Corrupted/invalid Android `bootimg` header (likely vestigial).
`0x313B28`	`~0x2680`	Firmware Paths	References to `/lib/firmware/eic7x/lpcpu_*.bin` (coprocessor firmware).
`0x33A5C0`	`~0xE9464`	Secondary Bitmap/Logo	Another 256x144 image (possibly fallback logo).
`0x423A28`	`40481`	Secondary DTB	Duplicate/redundant Device Tree Blob.
`>0x423A28`	Variable	U-Boot Environment	Persistent variables (`bootcmd`, `bootargs`, etc.).

Key Observations

U-Boot Structure:
- SPL (early init) → U-Boot Proper (main logic) → DTB (hardware config).
- Redundant DTB: Two identical DTBs found (likely a build artifact).
Anomalies:
- Android Header: Invalid but suggests historical Android boot support.
- Bitmap Data: Unused logos (may occupy unnecessary space).
Firmware Hints:
- Paths like /lib/firmware/eic7x/lpcpu_boot.bin imply a secondary CPU (MCU/DSP).

Next Steps for Reverse Engineering

Extract U-Boot Proper:

dd if=bootloader_milkv-megrez-2025-0224.bin of=u-boot.bin bs=1 skip=$((0x244058)) count=$((0x2D4C40 - 0x244058))

Disassemble:

riscv64-unknown-elf-objdump -D -b binary -m riscv u-boot.bin > u-boot.disasm

Validate Boot Flow:
- Check UART logs for SPL → U-Boot handoff.
- Interrupt boot to access U-Boot CLI.

Memory Regions of Interest

Address Range	Purpose
`0x80000000`–`0xC0000000`	Linux kernel load address (from DTS).
`0xC0000000`–`0xC4000000`	PLIC (interrupt controller).
`0x50450000`–`0x50460000`	eMMC controller registers.

ganboing · February 1, 2026, 3:02am

Pure AI slop. Disregard unless you want to be mislead.

dj53144 · February 1, 2026, 4:10am

What are you talkin bout? You?

ganboing · February 1, 2026, 4:36am

Your post is just loads of AI Bullshit. Refer to my post on the Sifive forum for a proper explanation:

And a more detailed version:

github.com/ganboing/EIC770x-Docs

board/bootchain/UART-Boot.md

main

## HiFive P550 UART Boot Guide

Some background regarding P550 bootflow. For P550, it's a 1 DIE configuration (EIC7702 is 2 DIE).
Thus, the stock stable bootchain (w/o secure boot) comes only with 3 parts:

- Secondary Boot aka. "FIRMWARE": A tiny blob right after firmware to do basic initialization, such as PLL clock.
- DDR Init aka. "DDR": Blob for initializing DDR memory. ~200KB.
- U-Boot/OpenSBI payload aka. "BOOTLOADER": The actual bootloader.

These parts are packaged in a container image (bootchain) with ESWIN custom format that's similar to tar/cpio.
The program `nsign` is used to generate such container image. For each component in the image, there's
also metadata to describe its type FIRMWARE/DDR/BOOTLOADER, the load and entry point address, and the
CPU (SCPU or MCPU) that's responsible for running it. In regular boot configuration, such image is
flashed to boot SPI, and DIP switches are set to `[0 0 1 0]`. After power-on, the SCPU (32bit) starts
executing Masked ROM, where there's logic to check DIP switch states and parse, then load the blobs
from the bootchain and invoke them in a pre-defined order: FIRMWARE->DDR->BOOTLOADER

For bootloader developers, such as OpenSBI/U-Boot or EDK2, it might be helpful to a. replace the "BOOTLOADER"
at will, and b. start JTAG debugging as early as possible. EIC7700(X)/P550 has the ability to boot from UART.
In UART boot mode, the bootchain image is read from UART, bypassing boot SPI. Hence, there's zero possibility

This file has been truncated. show original