schwar3kat

This topic may be of interest. It sounds similar to your issue. Perhaps ask how what they solved it and if it fixes the HDMI and WiFi. Perhaps you can get the DTB from them and try it on your board. Seems that there might be other boards with the same issue... if this is the same issue. It seems that there are different variants of the boards, and that AXP805 regulator control is different. I see a solution for the above problem for a different board here. It's a device tree change to use i2c instead of RSB. https://github.com/armbian/build/pull/3964

You could perhaps use armbian-config System Nightly switch to the nightly build to see if the issues have been fixed.

Hi Gabriel, I just checked the config for your legacy kernel. CAN is not available, nor is the driver. I suspect that you will need to use current kernel for this driver. You can search these forums to see if there are issues with the current kernel and if there are perhaps ways to get it working. It may be that issues with the new kernel have not been resolved for your board, or you may find that someone has got it working. If you want to learn and get involved then the Armbian build system is an ideal platform for you to develop solutions, providing an easy way to apply patches and stream improvements into the build via Github pull requests. I don't have your board, so won't be of much help.

You appear to be using a legacy kernel and a custom build. Where did you get it? It is unlikely that legacy kernels support gs_usb otb. I don't know of a way to add this after compile. I suggest that you try https://www.armbian.com/orange-pi-zero-2/ Armbian 22.05 Jammy Kernel 5.15.y

Hi Gabriel, You haven't given much information.... I don't own the same board as you and I know nothing about your CAN module. The current Armbian builds include the kernel gs_usb driver module which is apparently required for your CAN module. If you are using a current build then it is probable that you can activate the kernel driver module with "sudo modprobe gs_usb". This should enable the module, unless it needs some options configured (Google it). To confirm that the driver is loaded "sudo modprobe gs_usb --first-time" should return "modprobe: ERROR: could not insert 'gs_usb': Module already in kernel" After this you should be able to use the driver. Not required.... but using the Armbian build system, it is possible to include the driver module permanently into the kernel if you compile it after modifying CONFIG_CAN_GS_USB=m to CONFIG_CAN_GS_USB=y in your board's kernel config file. If you did this then it wouldn't need modprobe to activate it. Good luck Kat

Now that you have mentioned it, I have also noticed the order change. Do you recall which service made the changes?

That might be interesting. Perhaps the calling process will leave some errors in the logs. A sort of audit mechanism. I'm not running this image anymore, so I can't check, but others may like to try.

Is there any reason that you need that particular version? Armbian_5.59_Orangepipcplus_Ubuntu_xenial_default_3.4.113_desktop.7z seems pretty close with apparently the same kernel. Regards K

Does this have some connection to Armbian?

Hi Brentr, In the Armbian build system the Rockchip64 overlay dts files can be found in build/cache/sources/linux-mainline/linux-x.xx/arch/arm64/boot/dts/rockchip/overlay/ There are examples of overclocking in the mix. rockchip-rk3399-opp-2ghz.dts/dtbo is possibly similar. Note: to populate the cache you will need to build a Rockchip64 board. These files are compiled by the build system to produce dtbo files in the boot dtb overlay folder in the image, however they are refreshed every build. You will need to generate a patch to build the image. If you want to contribute by PR into Armbian, you will need a Git hub branch. Instructions in the documentation. Or if you just want to test it you could just build locally with the create patch option, and after adding your dts into the folder and setting the Makefile and updating the readme at the second pause in the build, continue the build. The dtbo will be included in the image and the patch created can be included in future builds (and/or submitted in a PR). Oh and you might need to remove the existing dtb overclock patch. I'm happy to help you with Armbian build if you're interested. (I don't have experience with dtbo's but they shouldn't be too difficult) https://docs.armbian.com/Developer-Guide_Build-Preparation/ Regards K

Is this perhaps restricted to Debian or is it affecting Ubuntu builds as well?

@littlecxm Tagging the maintainer. Which images did you use (full file name)?

Hi Brentr, There is a patch in Armbian build that appears to enable 1300mhz for rockpis. build/patch/kernel/rockchip64-edge/board-rockpis-0028-arm64-dts-rk3308-add-opp-1300mhz.patch adds the following lines to the DTS. Are these your changes? +&cpu0_opp_table { + opp-1200000000 { + status = "okay"; + }; + opp-1296000000 { + status = "okay"; + }; +}; You may want to disable that patch and build to see if it fixes your issue, then perhaps submit a PR. https://docs.armbian.com/Developer-Guide_Build-Preparation/

Thanks. I have tagged the maintainer and let the team know. Besides the warning, do you have any other issues?

I was able to replicate your issue or a similar issue. @LucasM I suspect that this might be a build package list issue, rather than a cause for concern. I will alert the maintainer. I downloaded Armbian_22.05.3_Orangepipc_jammy_current_5.15.48_xfce_desktop.img, installed it on a 16GB Kioxia SD card and booted on a borrowed OrangePi PC. You haven't indicated which image you are using. There are 6 variant's available from the download page, and any number can be built on the build framework. Regards K ------------------------------------------------------------------------------------------------------------------ root@orangepipc:~# armbianmonitor -v Starting package integrity check. This might take some time. Be patient please... It appears you may have corrupt packages. This is usually a symptom of filesystem corruption caused by SD cards or eMMC dying or burning the OS image to the installation media went wrong. The following changes from packaged state files were detected: /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf /usr/share/applications/vim.desktop /usr/share/applications/libreoffice-startcenter.desktop /usr/lib/chromium-browser/master_preferences.dpkg-dist

I'm not aware of this being a common problem for your device but if you Google, you will find that this is a fairly common issue with a myriad of different causes. If you search the forum for "pink" you will find a very small number on various different boards. Is it just that monitor, or all TV's and monitors? Often it is one particular monitor that the board doesn't like. Do the vendors supported OS images have the same issue? If so then it might be a hardware issue. Is it just the one Armbian image kernel version or branch (legacy/current/edge) or all? Is it just the one Armbian image release (Jammy/Bullseye etc) or all? Pink apparently is common for poor connections bad cables or too low signal strength (maybe power supply). https://www.gadgetreview.com/why-is-tv-screen-pink good luck.

Hi Brent, We don't have a maintainer for this board and we have no budget for development. If you want to get involved and maintain the Rockpi S, then Armbian is the ideal platform and it would be great if you could to join the team. https://docs.armbian.com/User-Guide_Board-Support-Rules/ https://www.armbian.com/newsflash/armbian-needs-your-help/ The board is community supported, so you could build an image using the Armbian Build system: https://docs.armbian.com/Developer-Guide_Build-Preparation/ sbeaugrand's post above says that armbian 22.08 with bullseye and kernel 5.18 (edge) worked. That's a current build. Or you could try some images from the archives: https://www.armbian.com/rockpi-s/#kernels-archive-all

If you downloaded an Armbian image, did you do an integrity check? https://docs.armbian.com/User-Guide_Getting-Started/#how-to-check-download-integrity Did you verify the image when you flashed it to the SD? https://docs.armbian.com/User-Guide_Basic-Troubleshooting/#writing-images-to-the-sd-card

/usr/lib/armbian/armbian-hardware-optimization has two sed statements that work on these files: They look fairly innocuous,. I wonder if there is a new version of sed that is messing this up? Or perhaps the contents of one of the files is confusing sed? Alphabetically the first file corrupted (after alternatives, which is not corrupt) is apache2. I was running apache2 web server. How many of you are also running apache2?

I forgot that I had made a copy of the fs of the corrupted Pine64 SD. This is what's in armbianEnv.txt: /var/log.hdd/alternatives.log { monthly rotate 12 compress delaycompress missingok notifempt: create 644 root root } \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u ------------------------------------------------------------------------------------------------- The first part of this content matches the content in the file /etc/logrotate.d/alternatives Most of the files in /etc/logrotate.d are also corrupted with only 'alternatives' seemingly intact. Many have streams of \00\00\00\00\00\ ... appended and many are truncated. There is an empty file named 'sedd3SIEh'. 'apport' has been overwritten with the missing part of armbianEnv.txt as follows: verbosity=1 bootlogo=false console=both disp_mode=1920x1080p60 overlay_prefix=sun50i-a64 rootdev=UUID=3e9afe94-8407-4434-9be6-9528 It's as if the sed command went haywire. /etc/logrotate.conf is also corupted, truncated and a string of \00\00\00.. appended.

If you don't want to use an SD card and you are booting from a USB drive, then yes, otherwise not really. I did it on a couple of old boards that boot off a partition on USB 3TB hard drives and serve as backup storage, but SD cards are now so cheap, so it's not really necessary. Disadvantage is that boot loader upgrade is slightly more difficult.

Ditto on a Pine64 running Buster or Bullseye (can't remember which). I thought it must have got corrupted somehow, but it's just a spare that I have so It didn't bother me. I noticed that it looked like /var/log/ stuff and thought that it was peculiar. I took the opportunity to try the new Jammy instead and forgot about it until I saw this post.

orangepi-r1plus-lts - all images are good Iperf speeds are as expected for both Ethernet interfaces. Tested: Armbian_22.05.3_Orangepi-r1plus-lts_bullseye_current_5.15.48.img.xz Armbian_22.05.3_Orangepi-r1plus-lts_jammy_current_5.15.48.img.xz Armbian_22.05.3_Orangepi-r1plus-lts_jammy_edge_5.18.0.img.xz Some of the Asia mirrors were 404. Guess the images are not there yet.

Have you tried the new images 23-Jun? There is a description of the boot processes on the pine site https://wiki.pine64.org/wiki/RK3399_boot_sequence I noted this statement: "The BROM does not support using the standard option for eMMC boot partitions" I also note that rockchip64 has 128Mb SPI boot Flash. So perhaps it is possible to place your bootloader in spi, and the rest in eMMC

Hi Axel, I don't own one, and I don't have a board that uses eMMC, so I'm neither familiar with it nor can I can't test, but Googling the issue, Rockpro64 seems well known for a eMMC bug with random cards that report command queue (CMDQ) support but don't work correctly when CMDQ is enabled and if you searched these forums, you possibly came across this. https://forum.armbian.com/topic/19917-rockpro64-emmc-armbian-2108-kernel-51060-buster/ The post indicates that it only affects some boards, so it's likely a hardware tolerance issue that is triggered by something in the newer kernels. According to some Googled solutions it apparently requires a Kernel boot argument work around to get such cards to work with Kernels > 5. Kernel boot arguments can be added into the Armbian boot armbianEnv.txt file. It's certainly worth a try. You can try this: Add a line into into /boot/armbianEnv.txt extraargs="mmc_cmdqueue=off" Let us know if it works