I have tried the image from the github for latest manjaro on this board but I cannot get a display.
It is booting correctly because only 1 of the usb ports is syncing my wireless keyboard, which to my knowledge, is right because in the open source community that’s as far as we have got.
I have seen people on discord share screenshots of manjaro on this with these latest builds, but I can’t get far enough to get a display.
I have tried wiping the SPI flash, and then reflashing it, but I still get no display. I left it on for hours just in case.
I also tried flashing manjaro on the emmc and an sd card, neither will output display.
An older version of manjaro used to boot, but these new ones don’t give display. Am I missing something?
Well I currently have it connected to a hdmi splitter, one to my pc capture card (1080p 60) and one to my tv (4k). the splitter can also downscale 4k to 1080p. I also tried connecting directly to tv. Maybe next I’ll try directly to the capture card.
I got it hooked directly to the capture card, still nothing
edit
and i just tried another 4k tv in the house and didn’t work. i guess ill just have to wait until display controller is fixed? is what radxa has just not compatible with mainline?
yeah i figured. no problem, im still tinkering with the rock pi 4b. you guys have done an awesome job on manjaro for arm. thanks for all yalls work. I have the original pine phone I want to get back out now because manjaro arm has come so far. keep up the great work!
Yes radxa have used a usb hub method so only 1 usb is working while the other 2 are usb3 which does not have drivers yet cause rk356x is still in early development.
Keep it empty as rk356x uboot is still not complete.
No. Display will only work with 1080p at 60Hz as advice above.
Using capture card will not work. Plug directly and set monitor to 60Hz and 1080p max else it wont display anything.
Sadly its still to early for rk356x to support 2k or 4k. Hopefully soon.
The reason I thought I was missing something is that I used to get display through the capture card, but now I don’t. I’m thinking the person who built that image wasn’t a manjaro arm developer and didn’t contribute his code to manjaro, or there was a recent change that broke it. He was on Radxas discord, and radxa should have a link to that image on their wiki. I’m not sure there should be a difference between a 1080p capture card and a 1080p monitor, but I’m close to clueless about that stuff. From what I understand, the output should be CEA, not DMT, to enable HDMI audio. Those might not be the right acronyms, I read through rpi config.txt wiki to get that info. I’m guessing only DMT output is working? Even then, the capture card should still pick it up. I just really don’t think using a 1080p monitor would make any difference. Do yall have this board to test? I don’t know who the primary developer for this board is.
I have it and it works in my test. I am not sure if it was working on my capture card.
Please don’t try any unofficial images on rock3a as a wrong kernel dts can damage the board.
I am the one who added rock3a support on manjaro arm with a dts patch.
Not sure who is he but i don’t think anyone else have worked on manjaro rock3a image unless they just did mix and match of legacy kernel with manjaro rootfs.
If you have the first image that worked then maybe you can flash it again on sd card and test if everything works and also share what is the kernel that image is using.
“Yes radxa have used a usb hub method so only 1 usb is working while the other 2 are usb3 which does not have drivers yet cause rk356x is still in early development.”
And yet the Debian 10 download has all 4 working hope it get’s worked out I like Manjaro on the Rock 64 and was hoping the Rock 3A would perform in a similar manner. Thanks for your hard work!
And it works…I see nothing “mainline” in any of these SBC’s all need recompiled code to have a workable system. The rock 3A is the latest I’ve used with a plethora of half working systems from Android, Debian, to Manjaro’s version of Arch. Not trying to kick a pile of poo here, I know you guys work hard. I do have a beef with the manufacturers of the boards who take advantage of the community’s enthusiasm to sell their products while providing little support themselves.
The reason is that the soc is very new and the drivers are still being written for mainline kernel.
Due to the frequent changes in the drivers like hdmi/vop2, usb3 and pcie stuff keeps getting broken.
I have tried the latest image from github ci release and it have worked fine for me so far, but I don’t get time to test it regular on ever release.
I suspect that you tried to update and ended up with a kernel which did not have good rock3a support.
I can only advice you to try the latest image and share output of logs if you get stuck, without logs we cannot understand what is happening.
This is true for many vendors and we face the burnout cause of so many vendor popping board back to back without any mainline driver support.
SBC are mostly for development purpose hence they’re just a piece of PCB with chips stack on top of it without a consumer case etc. If you want good support then maybe you can try RK3399 SBC like Pine64 RockPro64 or Amlogic S922x/A311D Khadas Vim3 but again do not expect everything to work on it like no video decoding driver yet even though these were releases years ago still there is not drivers and community development cannot always provide free labour to write complex drivers without any documentation of the chip itself.
So yea I agree vendors are just making half baked software for their hardware but the blame should be on the SOC vendor and not hardware vendor. As they can’t just expect community developers to provide free drivers and software.
Sorry not a rant but harsh reality of arm device drivers on mainline kernel. If a user wants everything to work out of the box then I think X86 is the only option atm.
Not much we can do about it yet.