Jump to content

Recommended Posts

Posted

It's been a while since I used Armbian. I have tons of ARM SBCs from a few years back because I think they're fascinating but they either wind up being too slow or just not worth using it for whatever since x86 "SBC like" boards exist and are pretty cheap. Fast forward to now and I'm doing some touchscreen development and just because of how I have things setup I needed 3 things, I2C, Interrupt capable GPIO and an actual DisplayPort. That combination of things is surprisingly hard to find.

 

I had a couple of things on hand, (Seeed Odyssey x86, Odroid H2/H3, Rpi's, Nvidia Jetson Nano). I spent way more time than I should have trying to make each of these work, in the end only the Rpi4 worked because the GPIO is good, problem is the HDMI ports are native. That's kind of a thing with ARM SBC's that's opposite from x86 and desktop GPU's...the native display interface is usually DisplayPort of some form on x86. So with the Pi4 I had to use one of the few HDMI->DP adapters I could find (the other way is common, this way is rare) and it worked but it's kind of jank. The other SBCs had various issues with GPIO even though they had displayports.

 

So I picked up the Orange Pi 5 Plus because it has a typeC/DP which is fine. I think I tried the latest image of Armbian first, and it doesn't boot, there was a post here over a month ago about it so I wound up dropping Armbian cuz that's not a good start. Manjaro Rpi images work well, they have a dev image for the orange Pi but their device tree is missing the typeC displayport connections. Then I tried Orange Pi OS / Arch which looks ugly but the DP works....though the colors are swapped, like the red/green channels are mixed up. I couldn't get I2C2 working either. I saw a post on here about it mentioning the kernel version etc. but I couldn't get it by device wouldn't show up on a scan.

 

So I came back to Armbian, slightly older image with the vendor kernel. Has pretty much the same issues. After some messing around I found that the I2C4_M3 mux overlay works to put the I2C4 bus into play, this one worked for me. So I was able to compile my driver module against the orange Pi source and get it working but I still have this issue with the DP colors being swapped and slightly shifted. Something is off about the DP configuration. Right now I have enough to do what I need to do but I will have to resolve that. I'm leaning towards the issue being in the DT. If anyone has any ideas about this it'd be much appreciated.

 

Just figured I'd tell that little story in case some of the Armbian devs are looking for feedback. Think I'll stick with Armbian since it works better than anything else, though I much prefer Arch based distros. As for the Orange Pi itself, this thing is great. It's an actual development board, with enough interfaces to actually develop something, so I think I'll actually use this one.

Posted

OK I've actually found the crux of the issue, though I haven't tried to figure out specifically what causes it yet.

 

I ordered another Dumb TypeC->DP adapter cuz I figured there might be a bridge in my last one that was messing things up. It did the same thing with the messed up colors and shifted image. Then I remembered I have a typeC dock that's smart and has a DP port and it works fine. Checking Dmesg I noticed the dock sets up link training for 2 lanes @ 8.1Ghz. The dumb adapters with the bad color train 4 lanes at 2.7Ghz because that's what my display advertises.

 

The Orange Pi5 Plus manual states:
1 x Type-C (DP 1.4A) output, up to 4K@60FPS 

 

To meet that bandwidth it needs to supply either 4 DP lanes @ HBR2 or 2 DP lanes @ HBR3. 

I reprogrammed My display's bridge (it's custom) to advertise only 2 DP lanes at 2.7Ghz. Now that's what the Opi does and the image is perfectly fine.

 

So I think what happens here is the Orange Pi 5 may not actually have 4 lanes to supply over type C but it's configured so that it will try if requested. The 2 lanes of DP it can supply are incomplete as they are expecting to be merged with the other 2. When using a smart typeC dock, it intercepts the display's DPCD report and says "I only have 2 lanes at HBR3 so that's what I want". On a Type C dock with USB ports it's not possible to pull 4 lanes out of the host connection because the other 2 lanes have to be used for USB3.x.

 

So basically the Opi has to be told the sink only has 2 lanes or it will screw up when it delivers 4 lanes and can't. I assume that's the correct assessment cuz I can plug this thing into any other PC with a real DP or type C alt and the color is fine, reporting 4 lanes over DPCD. 

I assume this is probably a device tree thing, I'll update the git issue on Opi's kernel repo, just figured it'd be good to let anyone trying to use it what might be going on.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines