Rock 5C - System hangs at DPHY access after swapping rk3582 with rk3588s

Hi all, as the title says, we wanted to give the rock-5c a try with the rk3582. We wanted to take the chance and try to see if the GPU was working but that wasn’t successful for our case. Instead of purchasing another board, we had someone swap the SoC with the rk3588s since they were pin-to-pin compatible.
We then ran the same system on an sdcard but then it hangs at the dsi panel initialization and particularly at the dphy register access. At first we thought that guy messed up the swap process so we tried again with another rk3588s. It landed the same results.

Going further, we spotted that the TAF can be responsible for activating some subsystems but this is done at the boot-up part and is part of u-boot, which remained unchanged.

So we want to know if there are other things to consider that are responsible for allowing access ro certain subsystems like NVM data to be written?

And, will a stock SoC be working as expected compared to for example to those rk3588s soldered on rock-5c?

Or is it just that the guy messed up the board twice, that simply?

Thank you in advance for the answers and clarification. We are looking into getting our system back for further development, but also to understand what is responsible to run what.

Which image do you use for the 5C switched rk3588s?

rk3588s and rk3582 are pin to pin compatible, but rk3588s2 is not.

That would be rock-5c_debian_bullseye_kde_b2.img

Hi jack, can you please comment if there is NVM data needed for stock rk3588s?

No NVM data is required.

The reason DHPY hangs is because the ROCK 5C image is for rk3588s2 not rk3588s.

Thanks for the reply. Do you have a suggestion for the necessary change to make it work?
Or do we need a completely different kernel and/or u-boot?

You need to revert the patches that support rk3588s2, @ken will send you more details.

Pls have a try with this image:
https://github.com/radxa-build/rock-5c/releases/download/rsdk-b1/rock-5c_bookworm_kde_b1.output.img.xz

Hi ken, sorry for the long delay, been occupied a bit.
Now that I tried the suggested image. It still fails to go past DSI/panel configuration. The test is as simple as:

  • Flash the sdcard
  • Boot into the system
  • Using rsetup, enable the RPI display overlay, save and reboot

which RPI display? can you take a photo with the whole device connection include 5c and display