NanoPC-T4 display port

[rvalle]

Has anybody successfully used the USB type-c displayport of the nanopc-t4?

 

How do you configure it?

 

It works on the images provided by friendlyelec, so, I guess it is just a config/install issue ?

[LEARNER]

I am also trying to use USB type-c display port of the SOM-RK3399 board(Freindly ELEC), but display side "No HDMI signal from the device" error is shown. Any clue to how to verify?

[Oleksii]

On 7/11/2019 at 6:32 PM, rvalle said:

Has anybody successfully used the USB type-c displayport of the nanopc-t4?

 

How do you configure it?

 

It works on the images provided by friendlyelec, so, I guess it is just a config/install issue ?

Are you referring to mainline 5.* kernels? If so, display-port cannot work there due to such reasons:

 

1. If you enable cdn_dp node in device-tree, its driver will fail to bind making parent rockchip_drm driver to also fail due to incomplete structure - you will loose all other working video outputs (including HDMI) in this case  This happens because of:

2. There is no extcon notifications support in the present fusb302.ko driver. Rockchip's cdn_dp driver doesn't simply know when DP sink is connected and what is current pin assignment without extcon notification.

3. There is no DisplayPort alternate mode handling in the same fusb302 driver. This is very important thing which actually enters DP mode and enables physical link between DP and your monitor. 

 

I've been working on this subject in kernel driver till today and already implemented missing things. But my NanoPC T4 board died, so I cannot continue anymore and desperately give up ... 

 

[PatM]

Sorry to hear that. I have two nanopct4s and am learning about type c usb.

It is a tricky topic and I hope to learn it. From one day of review it seems

the 4.4.223-legacy armbian kernel doesnt really support type c.

It doesnt appear to load the typec module at all. I dunno.

My guess it is setup to work as a usb 3 host port.

It seems 5.4.y is compiled more correctly w.r.t type c

but it doesnt work yet.

 

I purchased a 7-1 anker type c hub today it arrived.

The ethernet port and storage ports work on bionic.

the hdmi well I am trying now...

[Werner]

4 hours ago, PatM said:

the 4.4.223-legacy armbian kernel doesnt really support type c.

While the overall stability and support seems better on the 4.4 legacy kernel a well known downside - you guessed that - is the lack of proper USB type C support. Unfortunately there is not much what can be done about that if noone spends time to fix this...

[Oleksii]

2 hours ago, Werner said:

While the overall stability and support seems better on the 4.4 legacy kernel a well known downside - you guessed that - is the lack of proper USB type C support. Unfortunately there is not much what can be done about that if noone spends time to fix this...

 

Mainline kernel is of fairly decent quality in regard to most popular RK3399 boards. All critical components work fine and have really good support. But something, which makes such boards outstanding, still doesn't work in 5.*  It is normal for the situation when vendor's developers are locked inside of their private sandboxes (they call it SDK, LTS branch whatever, we call it simpler - "legacy") and do not really see the world is bigger outside  . However, I have good news for those who own RK3399 based SBCs with Fairchild FUSB302 controller responsible for type-c handling and power delivery protocol. This chip is widely popular, so there are some other users of its driver in the kernel and driver itself is very well elaborated (IMHO again). But it still misses many things that we, Rockchip+FUSB302 owners, really need. There is absolutely no need to write new drivers or wait when developers from Rockchip will do it (they won't). The driver deserves some extension and we will get both DisplayPort and properly working Type-C port (not statically fixed to USB3 host in the dtb, as many present maintainers do for their boards, but real DRD with role switching based on cable detection). I was working on this subject for two (or even three of last weeks, don't remember exactly anymore  ) and managed to fill this gap and get working DP on this "silently abandoned" port. Dual Role support for Type-C was in progress, but it can be solved too indeed. Right now, I have neither technical possibility nor motivation nor even time to continue anymore. The best what I can do is to recover what I've lost and handover my patches to some other volunteers who can/want to continue development (but even this needs a lot of time). My plan A was to deliver those features to my lovely Armbian community, and then try pushing it upstream.

[Oleksii]

6 hours ago, PatM said:

It seems 5.4.y is compiled more correctly w.r.t type c

but it doesnt work yet.

It is not only a matter of compilation, some important stiff is not yet there, so nothing to compile to get proper Type-C in 5.* kernels  Don't look for black cat in the dark room, it will not help ....

[PatM]

Thanks. I want to understand this USB system.

But thanks for your contributions. I personally dont really need type c functionality.

But it would be nice. It is a little too advanced for me but I will look at your work.

Could you give me a pointer to your contributions in a conventient manner.

8 hours ago, Oleksii said:

It is not only a matter of compilation, some important stiff is not yet there, so nothing to compile to get proper Type-C in 5.* kernels  Don't look for black cat in the dark room, it will not help ....

 

[PatM]

I am learning the USB subsystem. I understand the SCSI subsystem and how USB interacts with that.

But this typec stuff is a whole nother level. It is extremely interesting and important, as far as I can tell.

I looked at the tcpm and the fusb302 code. I want to learn how to use usbmon  and will be looking at logs

with this. I have an Anker 7 in 1 hub. I assume that is a proper TypeC cable. It does support Type C Power.

I am going to understand that. I have an Anker 5 in 1 hub for my second T4.

Mostly the storage  and ethernet seem solid. On to deeper things.

I like having the second ethernet on my legacy t4...

anyway I see Google and Intel are the primary developer of this stuff.

so SCSI became "fabric space" and USB is dynamic access to the fabric?

I mean I would asssume so since this is a Google spec somewhat, OP1 or whatever.

I am learning Gadget. I see Design Ware studying the RK3399.

Who coded the RK3399 PCI and USB subsystems? Google?

I see Design Ware everywhere...anyway I am going to do what I can do

[Oleksii]

10 hours ago, PatM said:

I am learning the USB subsystem. ...I see Design Ware everywhere...anyway I am going to do what I can do

 

Hold on ... it seems you are going too deep and too everywhere  Things are not so bad to learn and "fix" everything at once. IMHO, fusb302, extcons, alternate modes handling in PD protocol and Rockchip's CDN_DP driver are the only things that worth research if you just want to see a picture on your DP monitor  

[PatM]

yeah I know. the reason is that I only really need ethernet/storage/type a and

actually Design Ware is fascinating. I have been learning RK3399 and their

The Technical Reference. I reviewed and indeed DesignWare comes from a company

named Synopsys. So that company probably coded the RK3399 controllers of interest:

Synopsys is a fascinating company. very large and they seem to have charted their

course well. I realize that TypeC was probably not even around for ubuntu 18.04 era.

I am also using USB as an exercise in kernel configuration -- since I can compile now.

USB and PCI are why we have RK3399. I wonder if PCIe is Synopsis design.

[I have no PCIe devices] we are safe!

I did learn how to config the USB subsystem. I assume that the DP problem

is  going to be related to my second HDMI port problem. Since that is what I have.

or should HDMI work without actual FUSB302 usage. I doubt it.

in other words I do not have a DP monitor at the moment actually.

I have an Anker with HDMI and  Type C Power.

 

I have read over the FUSB302 file. I leaned about the Software Interface (UCSI).

The Software Interface and Power Delivery seems to be what TypeC is about.

Most of FUSB appears focused on PD which makes sense since was Fairchild

a power company? I dunno. old name.

 

I suppose USB Platform Policy Management will be interesting developments.

I can see how all of this works together in a rich "managed" multimedia environment.

so I am learning how to work with the latest kernel on this topic.

Maybe I can find something useful. I did see a strange USB config issue.

this seems weird: why KOMEDA and no MALI?

#
# ARM devices
#
# CONFIG_DRM_HDLCD is not set
# CONFIG_DRM_MALI_DISPLAY is not set
CONFIG_DRM_KOMEDA=m
# end of ARM devices

 

I made some progress. I learned about /sys/kernel/debug/usb

I am learning the architecture of USB.  I can unplug a USB3 type a hub

and see chatter on usb/u0 ... I am going to learn how to read that.

I can see the debug info for tcpm and fusb

but when I plug in my Anker 7-1 I should see some chatter

but I dont. That is just a "hub" with type c interface

I watched a few Synopsys videos on USB 4 and PCIe 5.

I am going to review T4 Tech Reference to see if I can understand

more of it...

 

Armbian Build 20.05 for NanoPC-T4 has some weirdness about DWC3.

In my Armbian Ubuntu 18 the dwc3.ko is being built

but now in Build 20.05 it is not being built.

. also reference to dwc3-rockchip.ko in 18 but

these actually dont exist in the kernel/drivers/usb folder but they

are listed as "builtin".

 

Armbian Build 20.05 definitely doesnt run a kernel config.

I see someone else is having this problem. I am going to run

menuconfig and see if I can get a new kernel compiled with

dwc3.ko being built.

 

only some "glue" module dwc3-etc.ko is being built.

 

[PatM]

I have compiled Minimal Server versions of Bionic and Focal and Buster

both current and legacy. RUnning Bionic-legacy allows me to use usbmon

to watch when I connect an Anker 5-1 to the port C.

a whole ton of talk appears. SO at least it works like we knew Bionic-legacy works.

New hardware...so I can study legacy and current bionic and start looking at

config variations. The USB is just an excuse to learn Armbian Build and kernel config/device tree.

But I am starting to see how this process roles. and USB is fascinating

 

usbmon on bionic-legacy does not present fusb302 and tcpm interfaces,

as suspected.

[PatM]

I've made some progress. I have been building Minimal Kernel for legacy and current, Bionic and Focal (and some Buster).

I now understand the differences and how 4.4.213 is from FriendlyArm.

I understand the SDK lockin since I have been studying Firefly and Friendly for over a year

and know the history of the Rockchip 4.4 SDK. I guess being stuck at 4.4 SDK is the lockin problem.

The 4.4.213 kernel is pretty good though. My 256G workstation SD is now running

legacy Focal with Ubuntu-Desktop-Minimal.

 

That is the starting point of my desktop. I dont want the gnome evolution stuff.

whatever. I know embedded people have unique interests but the RK3399 is my

lowend targetted ARM platform. They call that highend I  think LOL.

I think Minimal installs of Server and Desktop is a good starting point.

I have been munching Debian packages for a couple years. My FireFox AV1 system

is working pretty well. bluetooth,pulseaudio. I need to clean that up though.

I will be exploring more Armbian Deb config simplifications .

 

I think I will specialize in Synopsys ARM SoC. I have learned enough Armbian Build

to move on to KConfig analysis. I assume legacy SDK is involved but there is a ton of

weird stuff in the FriendlyArm .config. For example I have just built a kernel

without ChipIdea USB platform. It compiled so I will find out what breaks if I leave it out.

I also leave out a couple of other strange options. Why Sunxi platform ?? I just select Rockchip platform.

I am going to run my first modified kernel today.

 

I dont think I need WireShark USB capabilities to get going. I need to keep learning Armbian Build

and KConfig in a cross - compile environment. So I am managing config files and deb/img outputs.

From there I need to learn more about Device Tree (I am learning u-boot and DT).

I suspect there is PHY stuff going on here and I need to learn how to trace that stuff.

I have gotten very familiar with the USB logging and USBMON.

 

so I am going to learn DesignWare and keep going.

I am pretty certain I should see some USBMON chatter on my channel when

I attach my Anker 5-1 Type C Hub. Well what happens exactly when I plug my Hub in?

I will know soon enogh. There are PHY issues here.

 

[PatM]

I compiled latest Focal 5.4.46 and I stripped out a lot of strangeness in Kconfig for NanoPC-T4.

I can confirm that I am running the new kernel and nothing broke. How's that? that counts.

I am committed to cleaning this system up. I dont want 3 Platforms selected.

And I dont want two USB frameworks activated.  So IdeaChip is gone and Sun-Xi weirdness gone.

Here's something weird:

 

The Legacy image 4.4.213 has no source code for typec in the compiled kernel (I compiled it and looked)

no fusb302 and tcpm. But there are messages in the log from those modules.

Somehow Legacy kernel actually does have fusb302 and tcpm running.

I suspect that I need to reach into the lower depths: what blobs are being inserted and how?

I see the "patch ram" stuff. I dont really know what blobs I am running.

I will find out. I am focused on RK3399 so I want to strip it all down to basics.

I will search for fusb302 in the legacy source.

 

more weirdness:

On Current 5.4.46 focal, I can see (using USBMON) messages from fusb302 and tcpm.

but nowhere in dmesg or logs are any messages at all.

 

so legacy represents a lot of ARM historical weirdness. what else is new?

I need to get comfortable with the blobs being inserted and how. I dont know that stuff.

I think we are trying hard to get away from all that right?.

 

so I need to look at the DeviceTree and PHY world.

 

[PatM]

two new directions. I installed Wireshark. I am trying to understand how to capture USB with Wireshark.

OK that is weirder than it should be but I also want to learn PCI and Ethernet [DesignWare] so I am going to

be staying with the USB - Wireshark level until I get USB tracing working. but I am looking at DeviceTree.

I see this weirdness:

pat@nanopct4:/proc/irq$ tree | grep usb
│   ├── rockchip_usb2phy
│   ├── rockchip_usb2phy_bvalid
│   ├── rockchip_usb2phy
│   └── xhci-hcd:usb5
│   └── xhci-hcd:usb7
│   ├── ehci_hcd:usb1
│   ├── ohci_hcd:usb3
│   ├── ehci_hcd:usb2
│   ├── ohci_hcd:usb4

 

No usb3phy in the DTS.

I am looking at the magical "compatible" string in DTS.

there are rk3399-dwc3 and dwc3 ... that is confusing.

so my goal is to focus on Synopsis and Rockchip device IO platforms

and I simplify and break. like replacing all rk3399-dwc3 with plain dwc3

is not a working idea.

 

 

[PatM]

I have WireShark running well. I traced USB ports. I can see my

Type=A 4 port USB 3.0 hub on USBMON8.  a bit of chatter

when I replug. Nothing on USBMON6 except the linux root hub.

I enjoy this. I did find FUSB302 in the legacy kernel.

FUSB is a Multi-Function-Device. This makes sense,

from SBC design that there would be quite of few of these.

the Arm PMU is a power device. I see it in the DT.

So the FUSB302 driver is logging in the legacy kernal

and may actually be working. LOL i dunno.

I will trace USB type C on my legacy 4.4.213 kernel.

 

[PatM]

a brief update. I managed to get the Type-C to actually work in Current Focal as a hub as it did in Legacy Bionic.

It involves setting dr_mode to "host". the root rk3399 config is to set dr_mode="otg".

I will learn more about "dr_mode". the type-a port is set to "host" but the type-c wasnt.

 

but I have invested in learning the /sys structures.

esp. /sys/bus/platform /sys/devices/platform /sys/firmwar

I also know the DT for my T4. I am learning Arm architecture

so I am learning the details and know the structure of USB

pretty well now.

 

I also am on my fourth iteration of simplifying the RK3399

kernel config. I have simplified Platform selection,

AV device selection, and USB configuration.

the /sys/bus/platform/drivers folder is greatly reduced.

The kernel is functional enough to boot a desktop so it cant be too bad.

I am breaking something with ULPI and the OF_SIMPLE_ DWC3 parameters.

I am going to learn more about why the driver selection uses "simple' DWC3 driver.

this involves some interaction with DT so it is interesting

 

anyway I am committed to being able to work with this "chosen" Arm platform.

I noticed ASUS RK3399Pro system uses Debian 9 .... 4,4 *sigh*

git werkin

 

 

 

[PatM]

a final update on this for now:

 

there are issues with setting dr_mode and phys properly.

the nanopi4.dtsi wants to set one usbdrd dr_mode to "host" but it

sets a reference to an "otg" port phys.

If I set both dr_modes (there are only two usb3 targets) to "host"

then both port phys to the proper "host" phy phandles.

then my type c port works correctly with both Anker C hubs:

the 5 in 1 and 7 in 1.

 

if both usb ports dr_modes are set to "otg" and phys are left pointing to "otg" phy usb ports,

then it doesnt work. I am going to test that again. for some reason both ports dr_modes

set to "otg" is a problem. but setting both to "host" requires changing the phys string.

to point to "host" ports. that works.

 

anyway I can trace my Hubs now and use WireShark to trace USB and understand more about,

I havent tested alt-modes or power-distribution. USB4 will be awesome so I will be doing

this for a while LOL

 

 

[PatM]

I am working away learning type-c. I know I am in the eye of the storm here.

Massive changes. I see a dozen drivers have disappeared including rockchip-dwc3 and replaced with

of-simple-dwc3(sic) etc etc. But USB4 is like ARM64. a whole new level of power. literally.

it is exciting and I am accumulating some insights;

for example the real issue appears that OTG is not working at all.

that should not be surprising.  has anyone even tested OTG yet? LOL

I havent. I suppose I can attach one nano to another and see what happens.

I am planning nice investments to test TYPE-C throughly.

In the meantime set dr_mode to host and forget about type c. ugh

not really. I am thinking about changing kernel off 5.4.y trunk to 5.7 or something.

but  I am on this all of the time now. I want to learn 50Gbps

usb/pcie integration WOW! and I am going to invest in some TYPE  C Power Delivery

(probably the Anker .... $100! wow)

 

[PatM]

I discovered a use for my 16GB emmc: a linux test setup. I now run

Armbian Minimal Server (Legacy for "default", Current and now Dev for "testing")

So I figured out how to compile all possible Focal Armbian Minimal Servers for NanoPC-T4.

I also rebuilt my Firefly RK3399 for testing. What I have discovered is that

Ubuntu Minimal Desktop (Gnome 3)  works pretty well on Armbian Legacy Server.

"Current" Servers running 5.4.y work extremely well. I am now compiling "Dev".

[oh yeah extremely well not including type-c and wireless ...

5.4.y performance and sophistication overall is amazing]

 

anyway, I know a lot more about USB. I read over my Firefly device tree for comparisons.

clearly NanoPi descended from Firefly. I am aware of the EXTCON issue and DRD vs OTG.

I have to get APTLY going today and then I will be able to focus again on USB 100%.

Of course I am also learning linux kernel configuration in general but USB in particular.

[PatM]

I really like the magician who compiled Armbian Legacy Minimal Server using Focal.

I then plop Ubuntu Focal Minimal Desktop and things work very, very well.

I have done this for one of my NanoPCT4s and my Firefly RK3399.

I can watch the kernel logs easier than using wireshark.

In fact I think watching the logs and /sys is all I will probably need.

Here's the thing: right now USB TYPE C is at least working properly wrt to what I can see.

It correctly sets PD of my Anker Type C hub to 5V. The FUSB has to be connected to the DWC3

via setting "extcon" to the phandle of the FUSB. That will probably fix the connection issue at least.

The rockchip code is probably going to handle this in the drd.c file.

Armbian Build has placed me further on the #trunk and I have some X resolution problems.

I dont actually have a DisplayPort. I intend to get one. I have a DVI monitor.

I am going to try to switch to Dev mode on the NanoPCT4.

It only supports Current.

 

[PatM]

A brief update: I read over the USB section of the RK3399 TRM.

Clearly the RK3399.dtsi has been hosed in the linux 5.x.y series.

But the situation is this: I am happy running the Focal Armbian Legacy Server (4.4.213) /Ubuntu Desktop.

I even ditched Bionic / XFCE on my other NanoPCT4.

Both are running Gnome3/Focal and that is very nice.

So obviously the USB transition from linux 4.4 to 5.4 is a "learning experience" for me LOL

Hey but I did buy an Anker PD brick.

I am afraid to plug it in. Can someone tell me what happens?

I have $50,000 insurance policy so I will try it out on my FIRELY.

HA, I will get back with that experiment.

USB PD is an interesting topic and the FUSB is really more concerned with that then DisplayPort.

I understand that the HDMI is just a Gadget interface. I only use HDMI/DVI and have no DisplayPort.

But OK this is the point: The Legacy Kernel 4.4.213 very well might work with TypeC.

It appears to. I see a function PD device. USB PD appears to be active and TypeC connections are indeed handled.

Its just that the software architecture from linux 4.4 to 5.4 is completely different for USB.

pretty much. But the FUSB is "part of USB" in 5.4 but is just an "multi-function" device in 4.4

 

Well I am going to focus on how well TypeC works in Armbian Legacy.

 

[PatM]

Anyway I doubt anyone here expected USB PD to work. I did plug my Anker TypeC PD to both NanoPCT4 and Firefly.

And they didnt work in different ways. The FireFly ignored the TypeC connection and stayed Host.

When I plugged type C power into my 7-1 hub, then the hub came to life and worked.

The NanoPCT4 was more sophisticated. Running "Legacy" in both cases, but Firefly is different from NanoPC.

The DisplayPort on the NanocPCT4 is probably working but I dont have a DP monitor.

When a TypeC connection is made, the Nano FUSB302 wakes and it configures DP with pin connection Ox8,

and it sets itself up as "Downward Facing Port". OK this is interesting stuff to understand and

important for embedded.  but it is a hack. when I plug my 7-1 Anker into my NanoPC,

the NanoPC switches to Upward Facing Port and accepts power from the Anker.

OK. That is not what I want since my 7-1 hub is no longer something interesting to my Nano.

anyway I will conclude by saying I may be missing something but partly did anyone expect it to work?

No. I dont know what happened when my Nano "accepted power" from Anker and went into UFP mode.

except I probably dont want that to happen. but the hack is if you connect a DP Monitor to the Nano

it is going into DP mode. ....

 

I am using Armbian Build and run  images it creates onto local SD.

My Legacy Nano build is 4.4.213 from FriendlyArm repo but FireFly I think is from kernel.org

anyway I am not going to plug Anker PD into my Anker 7-1 Hub.

One day it may work. I am following a path that everything will just plug into

a USB4 fabric on my desktop ... compute sticks, network cards.

my desktop will just be a USB4 fabric right?

 

I hope rockchip is forking a 5.9.y SDK for their USB4 chips...

I am interested. in the meantime I will stick with Legacy and not

really do USB PD at the moment. I bet I can plug a DP port in and it will work.

just do offer power to the nano. I am going to keep studying the TRM and DeviceTree

but I will conclude now