Image | ROCK 3C #7058
Replies: 7 comments 1 reply
-
Hi, Not everything is perfect. I am getting random freeze when using the GUI and the wifi card is not recognized but after searching for an alternative os of my board I am very happy. |
Beta Was this translation helpful? Give feedback.
-
Thank you @MichaIng . |
Beta Was this translation helpful? Give feedback.
-
I did some basic initial testing of Armbian_community_24.5.0-trunk.532_Rock-3c_bookworm_current_6.6.30_minimal.img.xz. Initially no HDMI console. Suspect after reboot and/or post to manual
inxi shows:
Correct SBC name, but unlike the DietPi Quartz64B no serial number is shown. Is this related the Device Tree? Only one I2C bus with Armbian Rock 3C , Bus 0 gpioinfo which I forgot to run with the DietPi Quartz64B image shows some GPIO pins assigned No WiFi available I made no attempt to test BT 5.4 on my Rock 3C with WiFi 6/BT 5.4. I did not mention in my initial request, but will now. I did try the Armbian Pine Quartz64B image, but not able to boot from. There were many .dtb files for various RK3566 SBCs, but no Rock3c .dtb existed. I assume, possibly incorrectly, that the current Armbian Pine Quartz64B image I tried Armbian_community_24.5.0-trunk.532_Quartz64b_bookworm_current_6.1.90_minimal.img.xz yesterday before trying a DietPi version did not boot as the boot looked for a Rock3c .dtb file which did not exist rather than load the Quartz64B .dtb. Lost all my prior DietPi console took bit from for initial request and lost some key parts of console of Armbian Rock 3C image testing due to initially annoying manner that first Armbian root logon does I cannot control and annoying .bash_logout for non-root user! Really really annoying and makes it near impossible to actually ensure have what need to report issues. Armbian has some bugs due to Armbian specific OS configuration that causes serious errors in I did not report these issues that are clearly not Rock 3C image specific (seen such issues with different SBC Armbian images) as the whole report an issue to Armbian has so many checkpoints and such that in essence impossible to report Armbian issues, ergo why such basic Armbian bugs exist and exist for long time. I like the Diet Pi process to report issues or even request new image as has template when open as well as allowing one to explain and provide the needed details. With all the ins/outs/checkpoints and inability to actually report an issue to Armbian I do not despite my deep technical skills and background to figure out how to do so with Armbian assuming I do not have to make many many attempts before I find a successful way to do so with the Armbian bug reporting process. I am looking forward to when DietPi has a Rock 3C image. I find the DietPi images are more suitable for my use case. As FYI, I do feel there is one very annoying aspect of recent DietPi design, not a bug, I do not like at all. That is for different issue when I decide to open such an issue. |
Beta Was this translation helpful? Give feedback.
-
I did a test yesterday of a Radxa 20240109 B41 release I discovered way down in list of releases after releases earlier, that had many issues despite no issues listed in release notes to point of never actually booting for CLI. Today I tried the B42 XFCE release that provided some interesting information, but I will need to repeat the tests as post update items that worked, did not post update. A question I have is would it be better for me to post results of image tests, or results of Device Tree, GPIO, Wireless, et al for each image as a single post or post results of the image test? BTW I have learned some things along way in commands need to run to document or better document results. |
Beta Was this translation helpful? Give feedback.
-
So far I have the following commands to obtain information from testing related images: `uname -a lscpu sudo ifconfig ls -lsR --full-time /boot/* ls -ls --full-time /dev/i2c* sudo gpioinfo` Are there any other commands I need to run to obtain information useful to understand the common and differences of the related images? I would suggest the related images be Quartz64B from DietPi, Rock 3C images from Armbian and Radxa. I do not think there is a need to test the Armbian Quartz64B, but if there is a different opinion let me know. |
Beta Was this translation helpful? Give feedback.
-
Here the output for Armbian_community_24.5.0-trunk.532_Rock-3c_bookworm_current_6.6.30_minimal: |
Beta Was this translation helpful? Give feedback.
-
Radxa ROCK 3C support is now in the mainline kernel: |
Beta Was this translation helpful? Give feedback.
-
Creating an image request
Formal device information
The Rock 3C variant I am using has WiFi 6/BT5.4 using a RK3566 like all other Rock 3C designs. The other variation of the Rock 3C uses WiFi5/BT5.
Is the SBC officially supported by the Debian installer?
If not, is a reliable 3rd party Debian image available for this SBC?
If not, are there install instructions for Debian available?
There is big hope as an existing DietPi CLI only image is very close to a working Rock 3C image. My interest is for CLI only.
Today I used a DietPi V9.2 Pine Quartz64B CLI only image that was near perfect to use. I used the DietPi V9.2 image as what I saw today when check was not many bug changes for V9.3. Despite imaging the V9.2 image to SD card the V9.2.1 image updated to V9.3.0. Near perfect to use means other than inxi showing as "ARM System: Pine64 RK3566 Quartz64-B Board details: N/A serial: 427ed4ab84d91732 CPU:", no HDMI CL:I console, and only one (fine there is only one). dtb file "rk3566-quartz64-b.dtb". i2cdetect detected a number of I2C channels which is great. ssh worked just fine as as expected.
I do not know if the boot/uboot is such that will only load the "rk3566-quartz64-b.dtb" file by name or not. If so could one try using a Rock 3C .dtb as test using the "rk3566-quartz64-b.dtb" file name just as test? I do not know if the Data/Downloads/DietPi/0902-20240318/DietPi_Quartz64B-ARMv8-Bookworm.img.xz image on an actual Pine Quartx64B HDMI the CLI would work but my hope is would. Ideally the HDMI needs to work for CLI as very important to ebable one to see and/or correct any boot issues created by one (like me) than sometimes makes changes to files that can cause the boot to halt part way though or wants a ctrl-d to continue so one can check and/or correct the error or typo made that caused the boot to be incomplete including when systemd is not "happy'.
I installed a number of packages, such as lftp, inxi, lm-sensors, screen, sysbench, et al that all installed just fine and worked just great. I just installed CLI based packages. I have no intent to use GUI.
I did not try to use WiFi 6 nor BT 5.4 with the Data/Downloads/DietPi/0902-20240318/DietPi_Quartz64B-ARMv8-Bookworm.img.xz. For my use case I will not need BT. I will likely will use USB based WiFi adapter for distance need to connect between. I do not think the on board PCB antenna will be sufficient for the WiFi6. I will try the WiFi 6 at some point just to see as WiFi 6 has certain advantages. I did not have the Rock 3C located the typical distance. My routers are only WiFi5 at best. I have found WiFi4 to far more stable and longer distance than WiF5. Hence, I run my routers in WiFi4. I only use WiFi when I cannot run Ethernet cable to the networking device. I try to use Ethernet connection rather than WiFi for any network connection and have for years.
Please note the Radxa Rock 3C CLI images is not suitable as base in my opinion let alone for months. Radxa has not addressed the known issue Radxa has stated with current B39 Rock 3C release. The stated issue ongoing since 10 January 2024 B39 release is
Currently there is an issue preventing the Debian CLI image from booting
Supporting information in attached file Rock3C-Via-Quartz64BCLI-Image-20240503.console.txt
Beta Was this translation helpful? Give feedback.
All reactions