Jupiter 2: BootROM and booting over UART

Jupiter Jupiter2
1

Hi! I just got a couple of Jupiter 2 boards in. The preinstalled Bianbu is nice, but I need to figure out how to put my own OS on it before I can use it, and I’m also going to want to build custom versions of all of the low level firmwares I can get sources for. It seems that most of those sources are available, and I can probably figure it out as I go, but I need to be ready to un-brick if anything doesn’t work on the first try.

Looking at the K3 datasheet, it seems there is an option to boot over UART, but I’m not clear how to trigger this on the Jupiter 2 board. Can anyone give me any guidance on how to put the BootROM into the boot-over-UART mode?

Thanks!

2

By the way, have you found an answer for your question?
If you find the answer, please add this solution to this topic.
It will be very useful for me too. I would appreciate it.

3

Sadly no, I’m still looking.

I find the SoC docs [1], which say I’m looking for GPIO pins 68 and 69, but where are those on the Jupiter 2?… I don’t find any clue.

[1] SpacemiT

4

OK! I have success!

[Edit] Below is a guide to put the Jupiter 2 into UART download mode; however, it seems that contrary to my initial impression, the K3 BootROM implements fastboot directly, so there is little motivation to use a UART download to introduce a boot image. It’s faster to simply use fastboot, and this is equally as effective. See reply #11 for a good guide on how to build and boot low level firmwares on the Jupiter 2. [/edit]

This took quite a bit of digging and cross referencing, and I tell you, hardware schematics are not my forte… But here’s the abridged version if anyone’s interested how I got here:

How I identified and located GPIO pins 68 and 69

SpaceMIT docs give us the boot modes which tells us that we need to pull these Strap[2] and Strap[3] pins (which are GPIO 68 and 69) high to enable download mode (Strap[3]) and set that download mode to UART download (Strap[2]). OK, so pull GPIO 68 and 69 to 1.8v and you should get UART boot. Simple enough, except where are they?

Trenching through the hardware schematic, in the middle of page 14, we see that GPIO 68 and 69, which are also identified Strp 2 and Strp 3, which we cavalierly assume to be the same as Strap[2] and Strap[3], connect to various places, but notably for our purposes, connect to R.GMAC3_TX_D2 and R.GMAC3_TX_D3.

Armed with that knowledge, we consult the K3 Pico-ITX’s user guide’s FPC pinout (go to section 5.1) where we make another cavalier leap of faith that, in the 36-pin connector, the R_TX_D2 and R_TX_D3 pins are in fact none other than our old friends, R.GMAC3_TX_D2 and R.GMAC3_TX_D3!

Thus, as a result, we determine (read: conject) that the pins we want are, pins 10 and 11 of the 36-pin FFC header, and also pins 1 and/or 2 which can supply us with the 1.8v hot signal we’ll need to pull pins 10 and 11 up.

In conclusion, these pins are on the 36-pin FFC header. Pull pin 11 high to enable download mode, and pull 10 high to download over UART. Jumper to pins 1 & 2 to pull high. So how does one actually use this knowledge? Well, for starters you’ll need some additional hardware.

Where I bought FFCs and breakout boards

I don’t think there’s any feasible way to jumper those pins to hot without plugging something into that 36-pin FFC header. I opted to find a suitable FFC and a breakout board. Here are the links where I got them, in case anyone wants them. I would not say this is probably the best way to get them in the US, but it works fine:

That place also has 26-pin cables and breakouts if you want them; I picked some up just in case I ever need to use the 26-pin header for anything in the future.

I had to buy more than I needed due to MOQs so I am willing to send prepared kits to others who need them. PM me if interested.

From there, I just connected the breakout board to the 36-pin header and jumpered pins 10 and 11 to pins 1 and 2 (1 and 2 are the same so which one goes to which doesn’t matter) and then powered the Jupiter 2. The result:

sys: 0x10001a00
bm:1
ROM: uart download handler
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

Bliss!

Good luck and happy hacking!

Pinging @BlackS who was interested in a solution

3 Likes
5

Thanks a lot for the ping
Great work
Will try to repeat

1 Like
6

And how about just pressing the FDL flashing button as per section 3.1. “Method 1: Flashing via Type-C Data Cable” of the k3_pico_ug_en.pdf, which is SW1 in section BOOT on sheet 32 of the schematics SCH-146-V10_K3_DEB1_P1_LP5315B_PDF.pdf?

7

No, that’s not what we’re talking about here. That gets you fastboot, which is OK if you want extremely basic (and yes, performant) flashing of someone else’s images to the internal UFS, but if you plan on building or modifying your OS or other low level assets, you definitely want to go to the BootROM directly. For that, you need UART.

Fastboot is convenient, but UART is reliable. If something goes wrong at the fastboot level, you need UART to debrick and keep going.

8

OK, so I’m realizing that I must have made a mistake here. It was my understanding from various docs I’ve read that u-boot on the K3-Pico-ITX is what implements fastboot… and while that is true, I guess the BootROM also implements fastboot, so you can use the FDL flashing button to load an image directly to the BootROM, not relying on a higher level (i.e., u-boot) firmware to implement that fastboot protocol…

So yes, this does call into question the necessity of downloading over UART, except that I can’t find any docs anywhere on how you use fastboot to boot an image… You can’t just run fastboot boot FSBL.bin as would be expected, so what are you supposed to do with it? No docs…

1 Like
9

Guess what, you can just fastboot FSBL.bin. The ROM has the logic to do some rudimentary fastboot protocol. From there, you can load the u-boot payload, handoff to u-boot, and u-boot can do a proper fastboot from there. The workflow looks like this:

Upon power-on, you’ll see ROM emits something like

ROM: usb download handler
 rst
done H
setup= 0x1000680 0x400000,
 rst
done H
setup= 0x60500 0x0,
setup= 0x1000680 0x120000,
setup= 0x2000680 0x90000,
setup= 0x2000680 0x200000,
setup= 0x3000680 0xff0000,
setup= 0x3020680 0xff0409,
setup= 0x3010680 0xff0409,
setup= 0x10900 0x0,
usb_rx_bytes : start len[4096]
setup= 0x3020680 0xff0409,
setup= 0x3040680 0xff0409,

and the host side finds a fastboot device:

kernel: usb 3-1.4: new high-speed USB device number 69 using xhci_hcd
kernel: usb 3-1.4: New USB device found, idVendor=361c, idProduct=1001, bcdDevice= 0.01
kernel: usb 3-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: usb 3-1.4: Product: USB download gadget
kernel: usb 3-1.4: Manufacturer: DFU

At this point, we can load the FSBL (u-boot SPL) payload via:

$ fastboot stage FSBL.bin
$ fastboot continue

The ROM code processes the payload and start running u-boot SPL:

setup= 0x80 0x20000,
fastboot_handle_command: max-download-size
usb_tx_bytes : start len[14]
usb_rx_bytes : start len[4096]
fastboot_handle_command: 00074000
Starting download of 475136 bytes
usb_tx_bytes : start len[12]
usb_rx_bytes : start len[475136]
usb_tx_bytes : start len[4]
usb_rx_bytes : start len[4096]
fastboot_handle_command: continue
usb_tx_bytes : start len[4]
j...

U-Boot SPL 2022.10 (Jul 24 2026 - 07:12:47 +0000)
DDR Part Number: MT62F1G32D2DS, Size: 4096MB, Data Rate: 6400MT/s
DDR training consume 2992ms

And the u-boot fastboot logic takes over:

kernel: usb 3-1.4: USB disconnect, device number 69
kernel: usb 3-1.4: new high-speed USB device number 70 using xhci_hcd
kernel: usb 3-1.4: New USB device found, idVendor=361c, idProduct=1001, bcdDevice= 2.23
kernel: usb 3-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: usb 3-1.4: Product: USB download gadget
kernel: usb 3-1.4: Manufacturer: U-Boot
kernel: usb 3-1.4: SerialNumber: COM3K3081280372

Now u-boot proper can be loaded:

$ fastboot stage u-boot.itb
$ fastboot continue

Device response:

.....[  15.327]

U-Boot 2022.10 (Jul 24 2026 - 07:12:47 +0000)

[  15.330] CPU:   rv64imafdcvh
[  15.332] Model: spacemit k3 com260 ifx board
[  15.337] DRAM:  8 GiB
[  15.348] reset driver probe finish
[  15.436] eSPI not ready, skipping EC probe
[  15.440] Core:  631 devices, 35 uclasses, devicetree: board
[  15.444] WDT:   Started watchdog@d4014000 with servicing (60s timeout)
[  15.449] MMC:   spacemit_sdhci sdh@d4280000: probe done.
[  15.455] sdh@d4280000: 0
[  15.457] Loading Environment from mtdENV... k1x_qspi spi@d420c000: qspi iobase:0x0x00000000d420c000, ahb_addr:0x0x00000000b8000000, max_hz:26000000Hz
...
1 Like
10

I figured these out by reading spacemit’s official flash script: K3-Ubuntu-Images/image_flash.py at main · spacemit-com/K3-Ubuntu-Images · GitHub and Fedora’s documentation Architectures/RISC-V/SpacemiT/K3-Pico-ITX - Fedora Project Wiki. The binary blobs can be downloaded from unpacking https://archive.spacemit.com/image/k3/version/ubuntu/26.04/20260730/ubuntu-26.04-preinstalled-desktop-riscv64.tar.gz

One caveat is that the u-boot.itb is only intended for flashing. It’s not for regular boot. Spacemit’s using the edk2 as the runtime bootloader/UEFI firmware, so we might need some effort to somehow combine the two, and make fastboot useful for regular bootflow as well. FYI, The FSBL (u-boot SPL) and u-boot.itb can be obtained from spacemit’s PPA: https://launchpad.net/~spacemit/+archive/ubuntu/k3-preview/+files/u-boot-spacemit_1.0.5_all.deb You can also get other binary blob from the PPA as well.

I’ll dig deeper on this, as I’ll surely be hacking OpenSBI anyway.

1 Like
11

For anyone interested, I’ve manged to put up a complete fastboot guide for firmware hackers: K3-Docs/hacking/README.md at master · ganboing/K3-Docs · GitHub

3 Likes