Jupiter 2: BootROM and booting over UART

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!

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.

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

OK! I have success!

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

2 Likes

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

1 Like

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?

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.