Help with ROC RK3399-PC SD Image

Currently I’m able to cross-build an SD Image to get it to boot, and it has HDMI output and even gets to some part of Stage 2 boot, But shortly into the stage 2 boot, the whole thing powers off.

It shuts off so fast I can’t see an error so I’m at a bit of a loss on how to debug and figure out what’s failing. Maybe someone whos gotten some of the SBCs working might have some insite, on what steps I can take. Or maybe someone has some experience to suggest if I have the wrong kernel modules or something like that.

I started with @samueldr’s repo GitHub - samueldr/wip-roc-rk3399-pc but it seems some parts have changed since then with respect to cross compilation and U-Boot in nixpkgs. So I rewrote parts of it in my current version and made is fairly specific to my setup at GitHub - wkral/roc-rk3399-pc-nixos-image: Builds a nixos SD image to boot the ROC RK3399-PC.

I’d appreciate some help, even if it’s just a way to figure out if there even is an error message.

You’ll have to make sure that one of the following drivers, not sure which, isn’t being enabled or probed. Either typec or fusb302 (going from memory).

In that older repo, I’m doing it by disabling the module outright:

The way all this is implemented in Linux assumes that Type-C power can be disabled for a few moments when enabled, assuming battery power. I figure you understand that if the kernel disables Type-C power when powering the board from Type-C, bad times happen.

Note that if you use the RTC battery in the board, the RTC battery may hold the fusb controller in that powered-off state, and the board will not power back up when connected to Type-C power! It almost looked like a brick on my end when it happened, and it took a few (like 2) hours of debugging to find out that removing the RTC battery was needed to revive the board.

I don’t have anything “fresh” to share though, sorry :/.

Yeah, that makes sense, might be why see no error. I don’t have an RTC battery installed so that shouldn’t be the issue. Thanks, I’ll try adding that config change back in and see if that gets me further.

Thanks! That was totally the issue. Am I correct in assuming that this means the Type C ports wont be usable with this setup? The config seems like it just disables Type C to avoid the initialization issue.

I’m starting to understand why your repo looks the way it does since I’ll have to compile the kernel to add that config item from now on, including from the device itself, so you have the cross path and the native path.

In any case, my formally expensive brick is now a functioning computer. Thanks again.

I’m not sure what this actually means for Type-C support. I “paused” working on the NixOS setup a while back waiting for upstream changes, but never ended up investigating if there had been any. It has been useful as a native AArch64 builder with NVMe for a while, and then was replaced by a cloud provider. Right now it’s a test target for Tow-Boot when changing the more scary things.