I am using this page as my reference: https://wiki.radxa.com/Gpiod
If I manually install Gpiod, it returns: gpiod is already the newest version (1.6.2-1).
When I apply sudo gpioinfo no pin names are listed for my Rock4 SE board (Linux rock-4se 5.10.110-1-rockchip #0a544b8c7 SMP Sun Mar 12 14:04:06 UTC 2023 aarch64 GNU/Linux)
All pins are listed “unnamed”.
Oops I forgot to add this to the QA test cases. For now please check the pinout to get the underlying GPIO line for the pin (ex. GPIO4_D5). Then you can using this formula to convert it into gpiod chips and lines. GPIO4 is the chip part, and D5 (8 * 3 + 5) is the line part.
You can also use sysfs to manage GPIO like before. We included both interfaces. We also upstreamed ROCK 4 support on wiringX sometimes ago, so that’s another option to use annotated physical pin number.
Using ROCK 4C+: 20230312-1521 Build 55, I don’t have working GPU acceleration on my 4C+. The KDE session is using LLVMpipe (which should be software rendering). Is this normal?
On our system we use ARM Mali driver, which supports OpenGL-ES only. KDE on the other hand requires OpenGL, which is why it detects LLVMpipe. However, the X.Org shipped in our system is a custom version patched by Rockchip, which supports glamor GPU rendering. We set the KWin compositor backend to XRender to take advantage of that. You can try change that value to OpenGL to see how software rendered desktop truly behaves,
This is awesome! It makes me excited for the future of Radxa. I also love that this software wasn’t artificially limited to the newest boards.
Radxa bosses, please keep your software team happy! Better software sells hardware!
Have the device tree overlays been fully tested?
I am having problems with the Rock 4 SE board settings when using rsetup.
For example, it’s listing i2c8, which according to schematic is not connected as an i2c bus. Also it looks like the device overlay parameter for SPI = 0 works but it is pointing to the Ethernet connection and not SPI1 so you cannot SSH into the board if that parameter is set. That only leaves the parameter SPI=1 working - I have not tested to see which bus this is but I know that if you set the SPI parameter to 2 it says there is a SPI setup problem.
I am using ssh on a 4c plus. Enabling wifi and setting the password with rsetup does not survive the reboot. What am I doing wrong?
I recently discovered a bug in rsetup that affects detection of compatible overlays, which in turn affects the list of overlays that present to the user. That probably is why some incompatible overlays slipped past the test.
You are welcomed to create issues or PRs in our overlays repo.
You can run sudo nmtui-Edit a connection-Your Wi-Fi and check if Automatically connect is selected at the bottom. You can also delete the connection and readd it to make sure.
Just tried image for debian/cli on rock 4b+ on emmc, here are my thoats on this:
[ 840.765891] ieee80211 phy0: brcmf_netdev_set_mac_address: Setting cur_etheraddr failed, -52
service fails on each reboot because of lack of ip address (which comes bit later), this will make it unusable so far as headless service
5. default hostname is:
radxa@rock-pi-4b-plus:~$
Wasn’t “pi” already removed from board name some time ago?
6. Time to check what is inside dmesg, and it’s full of red messages about audio, hdmi and some about wifi. For cli image I need none of them
My conclusion is that it still require work. for now basic things are not working and without ssh it’s hard to get into system. Rsetup may be some approach and maybe in future will be ok, but now does not contain right information, is not intuitive and even misleading (I checked many times if this is right image, and not for rock5)
If it’s designed to be base image for rock4 family I expect to it that it’s focused on those, working out of box and without many dmesg errors. It should be simpler for cli which You expect to run headless, mainly without audio/display. It’s not well for now.
hmm. just noticed information about turned off sshd by default, for cli image it’s not that expected, same thing on star five vision five 2, where on latest image there is same issue. I think that probably everyone who want’s cli will change passwords. Armbian runs startup script to generate keys and asks for basic data, while it may be not best way it’s still better than no ssh for cli at start.
fix:
sudo systemctl enable --now ssh
still You need to do that with uart or compatible keyboard/monitor connected
With this release the documentation at https://wiki.radxa.com/Rockpi4/dev/how-to-use-debian is horribly outdated. Default user account is incorrect and there is no mention of the fact that SSH access is disabled on first boot unless you find the information regarding editing before.txt. Overlay instructions for using SPI Flash are no longer valid. Because I wish to boot from SPI with system installed on NVME I used the image available from Armbian as it contained the necessary support.
I tried today to use rsetup and for me is not working as designed:
No compatible bootloader is available., still don’t know what this suppose to do and what tries to update, what version I have, no compatible… sounds like my image is for wrong board.?./extlinux/extlinux.conf
dpkg-query: package 'keyboard-configuration' is not installed and no information is available
Use dpkg --info (= dpkg-deb --info) to examine archive files.
/usr/sbin/dpkg-reconfigure: keyboard-configuration is not installed
The only things that may be useful for now are overlays and maybe that thermal settings. Still I would like to get overlays for this particular board as well as temperature. Everything else is not working or just duplicating system commands.
I choose debian cli to use board headless I expect that there will be:
I understand that some things have been changed to allow kernel/system updates but for now it’s just hard to get useful information and update needed things.
We are in the process of updating documentations. I gave that page a quick notice about being out-of-date, and some key takeaways for the new image.
We will fix SPI boot support in a later version.
@dominik you have a lot of valid criticism, but it’s hard for me to address in this format. Maybe create a GitHub issue?
Many of your concerns are about wrapping system commands. Unfortunately this is also what raspi-config and armbian-config is doing, so we add those placeholder functions to indicate this is a tool for the same targeted audiences. Our own development focus for this initial version is on the overlay management though.
How do the overlays, as found in your overlays repo, get incorporated into a release?
Is there instruction on how to patch these corrections/improvements into this current release or will you be planning to issue another release update next month with these fixes?
I’m happy to wait a bit.
This would be great, but so far github lacks basic functionalities - first of all it’s unclear where to report particular board or/and whole build. There is also no particular issues list to check if anybody already reported that. Then no changelog to see if reported thing was already fixed and You can expect it in some build (or update). Also basic flow is just broken and unclear, as example - You replied on rbuild to someone about possibility that latest ubuntu may be already fixed (info passed as comment from Naoki…). No code referenced, no build, no changelog to confirm that, automatically created build where You don’t know what to expect.
I understand this is complex process and require some time to stabilize, but github has already many good practises described, bots, that reference issues, builds things, compile changelogs etc. For now You can’t even contribute code, send pull requests, track issues and its statuses. Of course good quality require good process and I know that it takes time for devops to do that.
I know that there are some of them on such utils. I just don’t expect that someone who choose cli will don’t know most of system commands or will be unable to find them. The most important part is of such util is to provide things that are absent on system. This may be updating firmware (spi, bootloader, maybe some soc firmware as well as some components on board), overlays, some device information (board version, firmwares, performance etc.). maybe additional packages prepared by radxa (let’s say specific board testing tool).
For desktop users probably most stuff is already somewhere in gui.
Overlays are currently built with kernel. If you have a custom overlay you could use rsetup-Overlay-Install overlay from source to build it into dtbo.
I think it is most natural to report issues under radxa-build for image related stuff, where each product has their own repo representing them. We are already decided to post future issues we discover during board bring up in GitHub. If you know which exact part is wrong and create an issue to the right repo, great! But we are not expecting our users to be professional developers. The important thing is we get those reports, then we can use GitHub Project to track them, and discover duplicated issues.
radxa build meaning: https://github.com/radxa-build or https://github.com/radxa/build ?
Even if You don’t expect users to be programmers or even advanced in this, whole thing just require clean up, and placing suitable information on all of them. Info about deprecation, reporting etc.
Let’s say I want to test and report something about ROCK 4B+.
Should that be: https://github.com/radxa-build/rock-4b-plus ?
This one redirects to incorrect old name https://github.com/radxa-build/rock-pi-4b-plus
Then You will see:
Last change 4 month ago? This is first information that confuses users. Is this even active repo and anybody maintains it? seems that its plain 
BTW, that last change was about board rename according to new scheme (without pi), so is this right repo? This always confuse me.
Then:
This is unclear, testing images?
As I said Armbian part is just misleading:
why to build unsupported image that is not recommended, and links to this: https://www.armbian.com/rockpi4/
which is this:
supported, built 4 month ago and it’s not for ROCK 4B+ !!
On bottom You will find more links for more variants, none is for 4B+ which maybe is not supported.
Even If You know that You have 4B+ You may be redirected to other version and maybe You will end up with image for 4B.
Let’s go back to github and forget about unsupported by radxa armbian and unsupported by armbian unofficial builds:
This is yet again unclear, probably most users would like to get stable release and nothing is yet marked as that. Also it’s still not clear should You try or not published/latest release.
Here You can maybe go to releases and see same generic information, no changelog, no referenced issues, fixes, known bugs, anything. No trace that one image is different from another. 
Now let’s try to find good place to report an issue…
Wiki is not good place (it’s knowledge center), our forum - yep - we are here, discord don’t work for me and radxa channel (discussed many times). No trace about any github issues so why anybody should bother reporting anything there? As I mention this information is misleading.
Also I think that You already have few components to get reports on their own.
Just like I said - all those auto-generated pages, images, etc. are not intuitive. No changelog, no code, no reference, incorrect links, incorrect name, old naming scheme. This will not encourage users to report. Seriously You have to be very determined to go to release page and miss armbian builds there, choosing right one provided by radxa, knowing it’s something that is made of actual code. Really!
And now please just take a look at any project that is well maintained on github, let’s say https://github.com/rancher/rancher (pick anything else if You want),
It’s clear at every aspect. What it is, what is purpose, what is actual release on what channel, there are many generated page, each accurate, containing useful information, changelogs, compiled list of changes, code that is referenced. This is just example what You can expect, how You can navigate, how to submit issues, what information provide etc.
I still sure that whole thing require refactoring and maybe rethinking.
That is a bug and when producing software, bugs are happening … all other images for Rock 4 are dated & made at latest 23.02 release … but anyway that is not that big problem as after running an update, one gets to the latest state anyway. 4b+ is missing? Added this way, maintained that way (those links are for anyone)
Both projects are hosted on GitHub, while they have little in common. Rancher is backed with magnitude more resources and supported by professional software oriented company (SUSE). Also dealing with a fraction of complexity that is present in this world.
