Thank you very much for your information, and your effort. 
For my application Iāll need LVDS or DPI output, but Iām guessing this is not the final word from Manjaro devs.
Pardon a stupid question, but where can I get the image youāre talking about? Clearly not from manjaro.org, I guess?
These are still not available in the mainline dts.
Currently only available for quartz64.
here
I hope there is rk3568-rock3a.dtb present in the latest image.
No worries, itās going to take a while before I develop my carrier board anyway, but I hope these video outputs are on a roadmap.
If not, Iād be happy to help, if testing or figuring out non-programming stuff counts as help.
On whose roadmap?
Linux distributions like Manjaro grabs www.kernel.org sources and ships with their brand and modified Arch userland.
Does that mean rock3a dtb already on kernel.org source? 
I worked on it myself. Good to know you assume a lot lately.
Nevermind. Continue bragging about what Armbian does but donāt talk bad about other projects if you donāt know whatās going on in the background. I have respect for armbian project but looks like youāre here to spoil it.
Oh btw. Iāve not seen your name in credits of kernel.org source either just a reminder to push changes upstream too after you have patched it for armbian.
Good luck.
Idk if the kernel developers are working on it.
I will check if anyone is working on LVDS and DPI for rk356x
What you do I donāt know for sure since I donāt pay attention very well, that you are correct. āBut what Manjaro do, we can see from Git. Did I misinterpret it? I donāt think so. All Linux distros contribute to Linux kernel in some way. Some more, some less.
We also work on it, unofficially, and we donāt brag about. When you are happy when a few people asks you about something its cool but dealing with a river of questions?
My general answer went to mctom, which might look on this too naive - like getting free software support for (advanced) functions on request on mainline based kernel.
We have to stay on the ground - HW functioning and our life is first, mainline fanaticism that brings little to nothing, second. R&D and support that is unpaid would just become a lot more expensive if we would follow this advice. I always said - if you want something, provide something in return. Stop with your demands, especially in open source.
Most people that contribute to Linux kernel are companies, its paid work, professionals that live from that. I assume you donāt. Again I dare to 
I am reading what Igorp is saying and wondering is something is amiss as the above would seem to be true.
There is no such thing as mainline fanaticism to have an opensource documented and published linux for all.
The mainline opensource effort is to stop the entrapment of closed source cul-de-sacs that isnāt opensource and enforces $ due to non normal entrapment code(s).
Igorp go take a break or something as you really are not doing your Armbian project any good at all.
In the terms of Linux I have come to the conclusion you are having some problems at the moment and WTF the above is supposed to mean in a whole operating system based on opensource, free and support is optionalā¦
If you are not going to share and contribute and retain purely as your own for $ then its not opensource.
It is. Look around. People wrongly assumes all problems will stop when things arrives to mainline and support becomes our common problem ā¦ Even you can afford to rework tons of patch junk which is an everyday add in diverse architecture as ARM? A lot done quickly by amateurs? Capacity for proper review is already extremely low. Everywhere. If code is reviewed badly and not maintained well (or at all), you didnāt achieve anything.
We have full time positions for both of you so people that does useful work can take a break But not working on things you see as most important.
When maintaining stops, things starts to break apart ā¦ regardless of code phy location.
Everything we work on is accessible on git. Perhaps you have a problem in understanding what open source is? But you are welcome to have any opinion on that.
Right.
I dunno what to say, I am honesty wondering if you are having a meltdown.
Best wishes is all I can think of saying.
When my friends and family will notice something like that, I will start to worry about. Until then, this is forum ā¦ and I donāt expect agreement on all topics. Our experiences and know-how differs. And there is nothing wrong with that.
I know many contributors of linux kernel donāt get paid while still supporting many of the device drivers and dts upstream.
I know this very well. But if you read carefully mctom didnāt demand instead he said he hope and even if someone request for it then itās all good. I understand we do have many users who demands for it and if they do then they have to pay. If someone request or hopes then we shouldnāt preach them about how open source works and they should pay for it.
Yes coz you donāt see whatās going at the background. Coz not everything is made public until the device is publically released. Rk356x have been in work for months and Manjaro team along with other kernel developers have been working closely to bring up the device support.
So I request you to only talk about Armbian project and try to promote it instead of talking about or as you say āinterpretingā other projects from their git source.
And guys letās not spam another thread on Radxa Forum. Youāve done the same on Rock5 thread already.
I donāt want to reply to this topic anymore.
Cheers. Good luck with all your contribution to all the open source project.
Oh my, I thought heās like that only on Odroid forum. I do wish him to get better though.
Thanks for checking that out for me. In the meantime I scanned rk356x datasheet and found no evidence of DPI output support. I was wrong to assume itās there for any reason. So if you could just peek for possible LVDS development on kernel side, Iād love to learn what weāre standing on.
Just wanted to reiterate Iād be happy to help, but unfortunately Iām just a humble electronics engineer, so I can do datasheets, schematics, and skillfully follow instructions for testing. And of course, I understand all this free stuff comes from somewhere and Iām super grateful for all that.
I agree that there is a lot of unpaid work, but that mean you canāt ask people that already supports community heavily to do more on their expense. There are reports out there, who contribute most to Linux kernel code, so you will get some better understanding. Personal opinions can be wrong. Also mine ā¦
You mean Pine64 paying some kernel hackers to bring their devices up (via Manjaro) while marketing they have nothing to do with software support?
Git is not the only source of information, but that is what people can easily check.
Manjaro (or their close biz partners) is not sharing all the code ?! and @stuartiannaylor from as Manjaro user perspective is mourning that Armbian should share the code, while Armbian donāt hide anything. Not even in early development phases.
Public work will always be questioned, just most of people will not have difficult questions. Get used to.
Again wrong assumption. Let me correct it for you MAYBE MAYBE it is the RK paying those devs? just a maybe ok ?
(via Manjaro) ??? lol no Manjaro is not a kernel. Kernel developers working on kernel.
I though you just assumed but looks like you have problem in reading and understanding my broken english. Oh wait this is what people do to bring bad PR to a project. Read it half or āMisinterpretā wrongly, which you just did once again in just 2 of your response, makes me wonder how many assumptions and āmisintepretationā you must be doing on your forum replies.
READ CAREFULLY.
I know that and have been responding to it with positive approach. I didnāt see any questions from you. The forum user mctom asked a question and he received the answer to the question, while all you did is āASSUMEā & āMISINTERPRETā. Which I have been asking you not do it, instead just promote Armbian and talk good about what you do. If you have any question regarding Manjaro ARM Project then feel free to ask.
Once again let make it clear, I have respect for Armbian project and your just making me lose it.
This looks pretty close to the Rockpi 4 format wise. Will this work with the Penta SATA hat?
I notice that this newer model uses pcie 3.0 and that the Jmicron chip used on the hat supports pcie 3.0 as well. Would the rockpi 3a give faster disk access than the rockpi 4?
Would the rockpi 3a give faster disk access than the rockpi 4?
The answer is yes. PCIe 3.0 x2 on 3A is faster than PCIe 2.0x2 on ROCK Pi 4 using JMS585, but similar as PCIe 2.0 x4.
Iocrest do a great PCIe 3.0 x2 M.2 which dunno if anyone has tested (JM535).
Just wondering if there are any alternative format boards that will mount direct or carrier with a high speed ethernet in the pipeline?
If your using it as a client which is prob not the reason your using a penta sata hat or just a plain 5x sata board.
Its sort of strange as the answer is really no as the RK3588 has 2x killer features of PCIe 3.0 x2 & a Quad serial gigabit media-independent interface (QSGMII) but in the current format as network attached its bottlenecked via a 1Gbe just like the Rock4.
Never did get the format of the Rock3a as in end use really its no better than a Rock4.
For me it should of had 3x sata with 1gbe just as a plain low cost board and that would of been a really attractive SBC.
I feel the QSGMII should of had 2.5/5Gbe daughter boards that where optional addons so you could configure 7x sata with 2.5Gbe and 6 with 5Gbe as 6 lends itself better to certain RAID formats and at this level an extremely strong and unique selling point.
The PCIe 2.0 lane is just a bottle neck to what the PCIe 3 or QSGMII can provide and just steals that 3rd sata for little benefit over what is likely a much better network router already in home and office or even a USB dongle.
The end result of what you can achieve with the Rock3a is the same as the Rockpi4 as they share the same bottlenecks if to be used as a network attached server.
Thats the reason I skipped this one as been there and done that with the RockPi4.