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!
[230315] System Release Notice for ROCK 4 family
1 Like
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:
- Wiki page for flashing eMMC is still hard, I’ve done that several times and still has few issues, basically latest 2.96 rkdevtools is not working at all, it just failed on uploading image to eMMC, tried few other and then I was able to complete that using v2.86 (same cable, port, computer, etc) - this would be not intuitive for many users where rkdevtools are just problematic.
- When I flashed image first problem was to log in - I expected to find device in network, seems to be there but could not log in to it. So I needed keyboard/monitor or UART. Connected to it via gpio
- finding password was not easy, we already had many option, eventually radxa/radxa worked, but this is rather important information and makes some frustrations
- checked why I could not log in via ssh, and the answer was simple - sshd was dead, resurecting it with service command makes possible to login with ssh, on logs there was repeating:
[ 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
7. apt update, upgrade - ok, found few new packages including rsetup
8. time to check what is freq and nvme access, both tests were ok and it seems that it’s already running at 2Ghz and with pcie gen2 full speed, I wanted to be sure about overlays and found out that they should be managed by rsetup. I decided to give it a try and:
8.1 system maintenance, system update, this seems to be apt, why do I need this wrapped here?
8.2 system maintenance, update bootloader - this warned me about possibility to not boot, I have no clue should I updated or not, do I have old version? decided to skip it
8.3 overlays, I wanted to be sure about op1 and pcie gen, and managing that gives:
maybe first few are ok - I don’t tested them, but most of them are for rk3588 or rock5? Why they are on rk3399 board? Also no confirmation about those two which I was searching
8.4 view overlay info - I selected first one and got:
9. checked others option like manage connectivity with single option “network” later some connections - nothing interesting - just duplicating others systems commands
10 kernel seems to be ok, I will try several things to see if it’s stable,
11. I noticed that rsetup created /config with one file config.txt, and just comment that there will be important stuff there… this is bit messy, I expected /etc/something or maybe /boot/config if that is on that level
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
1 Like
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.
1 Like
I tried today to use rsetup and for me is not working as designed:
- System maintenance -> System update - complete failure, first option - system update is basically apt, this is not needed for me at all, maybe someone could use it if there will be any information how much should be updated
- System maintenance -> Update Bootloader - this warned me yesterday that may be not safe, I decided to try, and it just said:
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.? - Hardware - only thermal governor seems to work here, but still is maybe something wrong about fan here, for 4b+ I have passive heatsink
- Overlays - like I said overlay info give error, managing works, but still old way with editing /boot/uEnv.txt was just better, now it’s adding same thing to
./extlinux/extlinux.conf - Connectivity with one option network and things that usually are configured somewhere else, i.e: I don’t need option to set hostname, but tried that - it invoke set-hostname but forget to change /etc/hosts so it gives few extra error messages
- Navigation system is awful, sometimes it’s “exit” (like nmtui), on rest there is “cancel”.
- User settings has two options - yet again hostname (same as earlier) and password (passwd), still don’t need that
- system settings, keyboard - yet again errors:
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:
- stable kernel - so far it’s not that good, board dies sometimes - trying that now what could cause it
- dmesg without errors - right now there are tons of them
- something to tweak overlays - turn on what is needed, this is changed and not documented well, overlays list seems to be wrong, I cannot find now info about pcie-gen2 and its speed, also about cpu clock
- most cli ships with some set of utils, here most of them are missing, not a problem to add few things, but would be nice to get basic set
- system utils (like rsetup) should be tight with particular board, show some information about cpu, freq, temp, what firmeware has what version, should it be updated etc.
- maybe some security/performace information? for now sbc-bench is very useful script to get some of insights, check performance
- system board optimisation - for particular rock4 board I expect that dtb will fit that and board will not kill sd card or eMMC by default by massive write operations, starting with errorless dmesg is good idea
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.
1 Like
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.
1 Like
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.
Sorry Igor for triggering You again, I didn’t wanted to point out any armbian bugs or inconsistencies, we talked here about unclear armbian part, not armbian itself.
I don’t blame You for this and don’t demand anything to be fixed as You always wish. But, nevermind, the whole point of that sentence is that armbian links here are just misleading and whole that stuff is confusing, maybe even incorrect for ROCK 4B+ that I have.
That was not a point, but example of project maintained clearly with accurate information on every single line. I’m sure that even single developer can use best practices with releases.
For now there are just tons of images and automatically created texts that are misleading, broken&untested images and all that will not help both users to understand what they are downloading and radxa to receive good feedback, bug reports etc.
Let me clarify that once again - the whole point of that reply is that this release system lack important information, builds too much with no good indication what it is, what is fixed/changed, what to expect. Hopefully will be improved
CSI camera (raspberry pi cameras) still not working for me. With gstreamer I get a blurred image. Can’t get it to work with ffmpeg …
Is it possible to have a simple how to on how to record using ffmpeg?
I have been waiting for 2 years for this to work …
I am using rock poi 4b+
- no dpkg reconfigure keyboard
- no wifi connection because of error setting hardware address
- rsetup is the worst setup-tool i’ve ever used (compared to raspi-config or armbian-config)
- and everything dominik said 8d ago
Those images are unusable for me.
When armbian is developing images for rock-pi, why does radxa not colaborate with the devs there to get “best out of both”?
So what are my options using the 4b+ as server for home automation (no gui needed)?
- armbian from the official armbian site https://www.armbian.com/rockpi4/
- debian or ubuntu from here https://wiki.radxa.com/Rock4/downloads
Is there anyone listening who is using 4b+ not only for “fiddling around with linux and SBC”, but for real usage as a reliable linux system e.g. home assistant, fhem, iobroker, grafana, influxdb, node-red or else?
Regards
And who does not allow you to use the ext2 system for the boot partition?
Tested a little. No hdmi sound. Chromium in YouTube 480 max. Can’t bring up the onboard keyboard at startup … and in general KDE is shit 