Oleksii
-
Posts
23 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Oleksii
-
-
20 hours ago, Akeo said:
Thanks to @Oleksii for figuring out that the issue is that the USB-C controller is set to OTG mode rather than host mode.
So, as @Oleksii pointed out, dr_mode is set to "otg" rather than "host", and that is why the USB-C port is treated as a USB peripheral rather than a USB host, and why you can't get any device plugged onto that port to be recognized.
Good work! Although, it solves some problem for you, I want to mention additionally: what you did and what I suggested - is just a very specific workaround rather than permanent fix
. This port configuration is set to otg by default in the master (board family) dtb file purposely, and imho this is right, not a mistake anyway. Because this board supports Dual Mode on USB Type-C port, if you have proper support in all concerned drivers and enabled Dual Mode in kernel, of course. Real actual role of the port should be determined by the system automatically, based on the negotiation with other party (I purposely simplify things a lot ). This port capabilities detection and further toggling is performed by the driver of a dedicated programmable PD chip (FUSB302), which then should notify all other concerned underlaying drivers about the new role decision. My conclusion, after some intensive research performed, makes me confident to state, that current mainline fusb302 driver still misses a lot of desired functionality to support needed interaction with dwc3 driver e.g. in a right fashion 
If there are experts around who may argue and confirm that I'm not right, I'll be only happy to hear this!
-
On 10/21/2020 at 4:41 PM, tobefond said:
Same problem for me: I upgraded my NanoPC T4 and spent a lot of time to configure everything. At the end I noticed USB-C is not working to connect my essential backup drive. I spent many hours for nothing, because I thought a "stable" release means that at least basic I/O functionality was tested. I understand that testing takes manpower and money. But if it is missing the releases should me called "stable" for a referenced device. I do not know how many other users run into the same problem and waste their time.
How come, USB Type-C port will magically start working if there is no proper support for this in the mainline kernel for this board family? Even if kernel version is declared as stable, this doesn't mean that 100% of the "expected" functionality will work on 100% of the platforms. If you decided to base your work on the mainline kernel versions for this board, you should already know about hardware limitations related to the presence of proprietary vendor's drivers that are not really maintained by the vendor.
-
On 9/2/2020 at 4:02 PM, RussianNeuroMancer said:
Please try DisplayPort kernel for NanoPC-T4 published here. DisplayPort function does not work, but there is good chances that at least Ethernet adapters or flash-drives could work. Patches used for building this kernel is published here, so please redirect your feedback regarding this kernel to Oleksii thread.
USB Type-C port will work as USB 3.0 port in HOST ONLY mode (which, as it appeared, is enough for the vast majority). And the only needed and sufficient change for this:
&usbdrd_dwc3_0 {
dr_mode = "host";
};is to be added to the DTB
-
2 hours ago, RussianNeuroMancer said:
I briefly tested 5.7.6 kernel and found that Samsung 970 EVO still doesn't work with same PCIe link training gen1 timeout error.
Rollback to 5.4.49, and it works again.
My Transcend 110S SSD stoped working due to some driver changes in v5.4. But started to work again since next 5.5
-
On 5/8/2020 at 2:08 AM, RussianNeuroMancer said:
Ok, I get why you won't to submit this change. Just want to notice that it looks like Type-C port is in host mode in case legacy 4.4 kernel and in FriendlyDesktop (I don't remember kernel version, probably 4.4 too). So it looks like Type-C is intended to run in host mode after all.
If you are still interested in Type-C for mainline kernels. My patches at least explain what is missing in the present drivers and why this magic dr_mode = "host" is specified everywhere in the mainline dtbs
-
Hello, nanopc t4 folks,
Some, not so long time ago, I worked on fusb302.ko driver and device tree improvements in order to make USB Type-C port working properly in the mainline 5.* kernel. I managed to get DisplayPort over type-C + some general type-c handling improved before my board simply died. Unfortunately, I was not able to finish all the planned work and cannot continue further
However, I guess, working DP is already fairly good achievement that might be interesting for many of us. Hereby, I want to publish some patches to the mainline!!! driver and device tree that add missing functionality, so one can get DP+type-C working on NanoPC T4 (and all RK3399 based boards with Fairchild FUSB302 chip for PD with relatively small DT adjustments). I would be very happy if results of my work can be helpful to others and extremely happy if there any volunteers, who are willing to continue work on this subject. My primary goal was to contribute to Armbian, first of all, with a potential mainline repo contribution. What was added:
-
Extcon notifications support (type-c related cables) in the stock fusb302 driver (developed by Google folks, but also used by Intel if I understand correctly)
- DisplayPort altmode is registered automatically, if device tree has proper modelling for that
- DisplayPort altmode is entered as soon as DP cable connection is detected (both DP+USB3.0 and DP only pin assignments are supported)
- DisplayPort altmode is handled by the unified DP altmode driver rather than custom out-of-tree PD chip driver
- "connector" node modelling in the device tree according to the mainline kernel docs and modern requirements
- fusb node phandle is still specified as extcon source for Rockchip's proprietary drivers, however, last can be easily adjusted to resolve extcon directly from connector node link (as soon as extcon property is declared as deprecated for all new development).
- fusb302 driver is now correctly linked to dwc3 driver which provides role_switch functionality (+1 step to correct "Dual Role" mode handling based on the cable detection). This also eliminates annoying error message in the boot log: "OF: graph: no port node found in /i2c@ff3d0000/typec-portc@22"
Please, also notice that type-c mode is forced to Host as in the most of rk3399 based SBC dtbs presently. This is rather a workaround for such boards, than a permanent solution, until all necessary bits are developed for correct role switching in the drivers. I kindly ask some NanoPC T4 owners to build mainline kernel with my patches and test whether expected functionality also works for you. Those patches apply to linux kernel since 5.6 when I started to work, but should also apply to way earlier versions according to my brief analysis of kernel commits history.
fusb302-add-extcon.patch rk3399-nanopc-t4-type-c-modeling.patch
-
Extcon notifications support (type-c related cables) in the stock fusb302 driver (developed by Google folks, but also used by Intel
-
5 hours ago, RussianNeuroMancer said:
If they stop answering at this point, start conversation with sales again from different e-mail, and after few e-mail mention order with faulty board again. When I did so, they gave up, and agreed to put replacement into new order.
Yeah, it's hard to make them replace faulty board, but I assure you that it's possible - I did this. (But, yeah, maybe I was just lucky, but it didn't hurt to try, right?)
Thanks for advise! However, even this process will eat my time which I can more productively spend to make money for another SBC and preferably not FriendlyArm product this time
I'm really disappointed and do not want to deal with a company like this anymore 
I gave them enough time and information to resolve the issue in a "Friendly" manner. I also spent my spare time trying to contribute to the mainline linux in order to make their boards more "Friendly". And now, it seems to me, I should look for another friends
-
12 hours ago, guidol said:
Just my perosonal cents:
I got some NanoPis from FriendlyARM with Allwinner-Chips like H2+, H3 , H5 and A64 and they do work alll very well and since years 24/7 - but I got some Rockchip devices from other companys and they are the "black sheeps" of my SBCs - so Iam do not buy Rockchip-devices anymore.
So when try to buy Allwinner devices from FriendlyARM - but isnt that easy anymore without new H5-devices and no real successor in the near future
From what I read: "You own some RK based devices and they do work! But you stopped treating them seriously". In my situation all 100% of my RK-based SBCs are faulty "black sheeps"
-
14 hours ago, RussianNeuroMancer said:
FriendlyARM send replacement for this board, but making them doing so certainly wasn't easy - when all troubleshooting steps doesn't help, they decided to stop answering until I tried to place a new order via sales e-mail and asked them to put replacement board into this order.
I wrote the e-mail to their tech support. No answer, indeed. Then posted my question to them via "Contact Us" form on website. No feedback ... I saw some other people complaining about boards dying with the same symptoms (one can even find some posts in the FriendlyARMs dedicated forum). I worked on mainline fusb302 controller driver extension in order to gain some missing functionality crucially needed for Rockchip's DisplayPort and Type-C drivers. I managed to get DisplayPort working properly on T4 in mainline 5.6+ kernels. My SBC simply died right in the middle of kernel sources compilation
I haven't finished all the planned work and essentially wasted two weeks of my own spare time. I also described this situation to the FARM, and it looks like, they simply do not give a shit about community contribution. Neither them, nor Rockchip as a company in general I tried to complete the work in progress making use of my another M4 (also has the same Fairchild FUSB302 controller for PD), however it is useless, because USB3.0 and DP related pins are not wired at all Btw., this M4 of mine is also kind of faulty: HDMI port stopped working in the very beginning of its life, now it is completely headless Seems, I have very bad luck with this company and I don't see any reasons to buy their products anymore or even invest my time into Rockchip's based stuff.
-
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
-
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 ....
-
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.
-
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 ...
-
My NanoPC T4 seems also died today with same symptoms
Yesterday it stopped booting from MMC with only red power-on light and no other attempts to boot... Then I inserted sd-card and managed to boot from it in MASKROM mode. So I decided that main image is corrupted and planned to play with recovery today. This morning, it couldn't boot at all, neither MMC nor even SD - still the same red light only and that's it. Then I connected the board to PC via type-c port. It was detected as MASKROM device, but attempt to clear internal flash simply failed. I tried different proven to work PSU (works fine with M4), another SD card, detached SSD, HDMI etc. Now I see picture which is even worse: led slightly blinks one time and no power .... damn it
-
10 hours ago, RussianNeuroMancer said:
Ok, I get why you won't to submit this change. Just want to notice that it looks like Type-C port is in host mode in case legacy 4.4 kernel and in FriendlyDesktop (I don't remember kernel version, probably 4.4 too). So it looks like Type-C is intended to run in host mode after all.
It is not so obvious
I only consider the state in the mainline kernel as a reference (because I decided for myself to track changes since 5.* only). And I see that USB Type-C controller changes its state from "host" to "gadget" and almost immediately powers off during the boot. It should be correctly handled automatically by the driver on this board according to my understanding. And forcing to host mode is imho just a workaround for some issue in the current driver (or some other problems in device tree).
-
2 hours ago, RussianNeuroMancer said:
I could, but this solution does not scale (specifically "things that don’t scale ... fix a problem for myself" and "things that scale ... fix the problem in way that will just work for most people, most of the time"). I there reason why you can't submit patch for type-c port to Armbian? You have better understanding of Armbian internals than I do, for sure.
1. I still have quite shallow understanding of Armbian's internals
2. I use most up-to-date kernel revisions all the time in experimental mode and those are always several month ahead of Armbian's I suppose
3. I'm not sure that forcing controller to host mode purposely is a right fix - I miss experience and knowledge for such decisions. I did it for my personal sake and my own risk and clearly admitted this in the message above
4. Submitting the code to community project - is about 100% confidence and responsibility for me
5. Just have a look on the DT overlays capabilities - this was designed to provide some decent scalability potential and could be good compromise for you
-
2 hours ago, RussianNeuroMancer said:
I briefly tested 5.6.10 kernel and found that Samsung 970 EVO doesn't work again, same PCIe link training gen1 timeout. Rollback to 5.4.32, and it works again.
Manually compiled dtb will be overwritten during linux-dtb-current-rockchip64 package updates, I guess?
Yep, most probably file names will collide
I use custom 5.* kernels all the time with optimized configuration + some DT tweaks, so I don't usually care about linux-dtb-current-rockchip64 updates.
And if you want to overcome this, you may simply give your customized *.dtb a new name (make sure it is also correctly specified in the armbianEnv.txt). As another option, TD overlay might be handy too.
However, I would admit with every mainline kernel version increment I keep less and less of my custom patches
For the moment, I have only one important that fixes Type-C on NanoPC T4 (and still, no 100% confidence it is right way to fix) and one small patch to enable ES400 mode on emmc for NanoPi M4.
-
-
16 hours ago, pkfox said:
Hi all, I have a Friendlyarm nanopi M4 running armbian, I have tried to install dotnet core without success - anyone here managed it ? I followed a tutorial but when I get to the apt-get install part I see this error
Couldn't find any package by glob 'dotnet-sdk-2.2'
Hi @pkfox,
First of all, here comes official support matrix:
https://github.com/dotnet/core/blob/master/release-notes/2.2/2.2-supported-os.md
Seems, debian package source is not maintained for linux arm64, so we should install .net core manually from here:
https://dotnet.microsoft.com/download/dotnet-core/2.2
As you can see, only .net core 2.2 runtime has relevant arm64 distribution and aspnet core 2.2 only present for 32-bit.
However, according to this info
https://docs.microsoft.com/en-us/dotnet/core/linux-prerequisites?tabs=netcore30
both will be supported starting from netcore3.0!
Personally, I installed latest officially announced netcore 3.0 preview2 sdk from here
https://dotnet.microsoft.com/download/dotnet-core/3.0
and use it for development on daily basis.
Nightly builds for all "released" major versions can be found here -
https://github.com/dotnet/core-setup/blob/master/README.md#daily-builds
Best regards, Oleksii
-
On 11/26/2018 at 4:44 AM, morfane said:
I have the same problem, just connected a 2 pin 5V from the casual pins instead of using the fan controller designed for the board. I Also mentioned in one of my emails to FriendlyElec with another bunch of questions, yet that question remained unanswered. If you find a fan with a connector that fits, please publish it so others like me can also use the solution.
Frankly, I wouldn't even bother myself with active cooling, because I like silent PCs more
I simply underestimated this RK3399's temperament. I also purchased metal case for this model which can hardly fit standard dimensions fan and provide really efficient air-flow. Thus, I will try to improve passive cooling first of all (put some copper shim + thermal grease instead of magic blue chewing gum e.g.). Then, maybe, I will look for a decent (slim and silent) PWM-capable 12V fan and connect wires by myself as shaun27 suggested before. I've searched online shops quite a lot, and now I'm almost desperate to see thing exactly needed unless friendlyarm design it and start production soon.
-
4 hours ago, shaun27 said:
I think you would have to wire it yourself tbh.
Well, I anticipated such answer
just a little bit of hope there might be some ready-to-go solutions already...
Thank you!
-
I'm about to install active cooling fan on my recently delivered nanoPI T4. However, I cannot get what is a type of the soldered 3-pin fan connector on this board? What I see there is visually too small as for standard connector size. Is it something special I have no clue about yet, or it is for future proprietary Friendlyarm's fan designed specially for the board?
Any suggestions are welcome!
Thanks
NanoPC T4: how to make DisplayPort & Type-C working in 5.* kernels
in Rockchip
Posted
1. My work is based on mainline fusb302 driver sources, Armbian replaces it with some proprietary one. Patches shouldn't apply on top of armbian's version.
2. DTB patch makes absolutely no sense unless driver has proper support for altmode negotiation and extcon notifications. There is no magic in DTB itself, it is just a configuration parameters "provider"!
3. extcon-cables and typec-altmodes - where did you get those from? I can only guess, however, those "unofficial" bindings have no relation to the current driver in mainline.