All Activity

Thank you! Well, it is not obvious who actually made this, in the box there is a reference to "Shenzhen Chensen Technology Co., Ltd" but that seems a led lamp manufacturer, and a phone and mail that look like the importer. I asked an aliexpress seller that is selling these but don't have much hope. In a thread here someone came with a different box having exactly the same chips and said that multiboot worked. To me it is starting to look like a hardware problem, maybe some bad solder ball on the BGA chips, as a last resort I may try a reflow.

Some questions here: Isn't cpurequtils deprecated? So any other edit to other file is just ignored on reboot? Could you suggest the appropriate values to apply for min/max? Just as a test I set it to false again, so not using cpurequtils and armbian-config says I'm between 2000 and 2000 Mhz. So, I suppose I'm using the values I applied before.

On boot the system will apply the values from /etc/default/cpufrequtils to the running system (it is done by the armbian hardware optimization service)

Thank you! Was looking there just now. I already did: echo 1400000 | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq echo 200000 | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq that resulted in steakhutzeee@dk:/sys/devices/system/cpu$ grep . /sys/devices/system/cpu/cpu0/cpufreq/* /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0 1 2 3 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:200000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:155000 /sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0 1 2 3 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:200000 300000 400000 500000 600000 700000 800000 900000 1000000 1100000 1200000 1300000 1400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:userspace powersave conservative ondemand performance schedutil /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:cpufreq-dt /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:200000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported> grep: /sys/devices/system/cpu/cpu0/cpufreq/stats: Is a directory But I see a different value in: steakhutzeee@dk:/sys/devices/system/cpu$ cat /etc/default/cpufrequtils ENABLE=true GOVERNOR=ondemand MAX_SPEED=2000000 MIN_SPEED=2000000 So which values should I set here? And how can I manage the edits I made before? Maybe this is true only when using DBT instead of using CPU under armbian-config? Thank you!

You can manually set this info in /etc/default/cpufrequtils

Hi @jock. Main branch with new uboot 2024.1 is not ready to boot yet, right? (It seems new uboot doesn't even look for /boot/boot.scr) Nice HDMI output in uboot, btw, thanks!

I sent them a message, even sent an email and a whatsapp to the manufacture ( junuo ? hehe) , will see if I get a reply, google sadly doesn't help as seems it's the latest version of the board (v3.0), I really want to make this wifi work 😂 The thing about SBC is that I already have one, the thing is that I spent some good time searching for a chip that would have multiple usb hosts instead of just one, and that's not easy to find, specially not below 50 euros, I came across the rk3228, that somehow is available at those tv boxes :(.

Updating some bluetooth fix K610 V12, doesn't work, but it was there on HCi Line talking.... sudo systemctl status ap6335-bluetooth gpioinfo rfkill Full dmesg journalctl -b | grep Bluetooth

Hi, I'm running OMV on Odroid HC2. I updated to OMV 7.7.1. Armbian to 24.5.1 with Linux kernel 6.6.31-current-odroid-xu4. After reboot the server started to act very slow. I tried to reapply the DBT for HC1/2 via armbian-config but this did not help. armbian-config says I'm on ondemand governor between 200-200 MHz. What could be the issue? Actually my system says I should run dpkg --configure -a but this command hang here and the system reboots after few seconds... steakhutzeee@dk:~$ sudo dpkg --configure -a [sudo] password for steakhutzeee: Setting up containerd.io (1.6.33-1) ... EDIT: From armbian-config -> CPU (deprecated) I applied the max I could find. Now armbian-config states I'm running 1800-1800 MHz. I was able to successfully run the dpkg command and update my system. steakhutzeee@dk:~$ grep . /sys/devices/system/cpu/cpu0/cpufreq/* /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0 1 2 3 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:200000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:155000 /sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0 1 2 3 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:200000 300000 400000 500000 600000 700000 800000 900000 1000000 1100000 1200000 1300000 1400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:userspace powersave conservative ondemand performance schedutil /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:cpufreq-dt /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported> grep: /sys/devices/system/cpu/cpu0/cpufreq/stats: Is a directory I did: echo 1400000 | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq echo 200000 | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq If this issue with frequencies has to be fixed with an update, how can I set a correct frequency manually now? I'm afraid this high freq could cause damage actually. Thank you!

The default /. bashrc over rides any title or name setting set on the command line for all xterm and urxvt terms. This is very ugly and irresponsible behavior. I'm not sure where the source is kept but those lines of code need to be removed. Setting the prompt is one thing, smashing the title and name is something else.

@Blyato this is the other coin side of cheap tvboxes : devilish behaviour is just around the corner. If someone wants reasonable functions one must buy sbc well supported. That said unfortunately without original stock firmware, device tree or better the whole board in hands is quite impossible to guess what is going on Try to search on google or ask vendor for the stock firmware

I guess it's not really possible for me to get this device tree? I tried to backup the stock image but couldn't get multitool to read and I totally forgot to try doing with the rk tool...

@Blyato From dmesg I see the wifi chip is just turned off: [ 1.716294] mmc1: Failed to initialize a non-removable card I'm pretty confident that the issue is related to the GPIO power pin of the wifi chip being incorrectly set. You mentioned you are using led-conf7, which is the right device tree for R29 boards, but it seems that your board is a different version/revision and requires some adjustment. To do such adjustment, I definitely need the device tree or the backup of the stock android. A possibility is to try other led-conf options and see if the wifi chip is at least recognized, but I don't suggest to do so because led-conf7 is vital for the stability of the R29 boards: without it, your board will probably be unable to boot at all.

Here it is, when it comes to linux, I only know how to use it, those things are too advanced for me, I only noticed in red that "/cpus/cpu@f03 missing clock-frequency property" , a part from that haven't seen anything related to network, thanks for checking it out ❤️ I bought this from the aliexpress most sold listing for MXQ 5G Pro 4k, so maybe will help others as well.

This is incredible news, so glad to hear this! I won't be able to test this out for a while but will give any useful feedback once I do, hope to hear reports from others as well. Thanks to all who keep working on improving support for this board.

Description Per Igor comment helios64 required work to sync with upstream changes. I took the liberty to keep more of upstream than in Armbian 6.8, namely: I kept nodes at their upstream location to remove unnecessary work when syncing to the upstream keep "ethernet0 = &gmac;" in aliases, to let the ethernet MAC retrieved from OTP in u-boot apply. This will restore this feature (the u-boot was still functional). U-boot retried ethernet MACs are in u-boot printenv output "ethaddr" and "eth1addr". Seems for a few years I had the Linux kernel autogenerated one but my config still had the correct one commented (I did not find why it broke back then). I removed the overclock disabling code as the overclock is not included in the dts so no need to disable it (will lower the sync to upstream burden) kept upstream fix 93b36e1d3748c352a70c69aa378715e6572e51d1 "arm64: dts: rockchip: Fix USB interface compatible string on kobol-helios64" from upstream in vcc3v0_sd node I kept "enable-active-high;" and "gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;" sync to upstream from helios64::status to helios64:green:status for system_leds : status_led kept startup-delay-us = <2000000> on hdd nodes from upstream (I believe they should not be the same value for rail a and b of the HDD, one should do as in the helios64 u-boot code where one is started after the other to lower the current load) I also did not sync with upstream the differences of gpio pull config for "power > sdmmc0_pwr_h" and "pinctrl > pmic > pmic_int_l" I kept the upstream DTS model "Kobol Helios64" instead of the armbian "Helios64". Ethernet rename from armbian-hardware-optimization works. Documentation summary for feature / change [ ] short restore ethernet MACs for eth0 read from OTP via u-boot [ ] This will restore the original intent which is to have the eth0 mAC be defined from the mainboard. This might affect MAC-based DHCP definitions [ ] ip l to get the Linux-defined eth0/end0 MAC, printenv in u-boot to see ethaddr and eth1addr for eth0/end0 and eth1 How Has This Been Tested? [ ] Compile, installed, and reboot, checked assigned IP was from the dnsmasq dhcp-host definition for this ethernet MAC. Did a few other reboots. Checklist: [ x ] My code follows the style guidelines of this project [ x ] I have performed a self-review of my own code [ x ] My changes generate no new warnings View the full article

Ok, I did not erase spi. I do have the old krescue. I will try again after erasing spi. It's good to know it's working. Thank you, Erica

Updating here some bluetooth fix K610 V11, doesn't work, but it was there.... gpioinfo Full dmesg rfkill journalctl -b | grep Bluetooth sudo systemctl status ap6335-bluetooth Found some answer in other forums: Could be Pull down or Pull Up pins on UART

Hi, I developed this app just while having a look at django + angular -> https://github.com/vijaygill/wg-ui-plus I thought of sharing it with open-source communiity which has given me a lot! It allows me to have finer control over what a given VPN client can access (using IP Tables rules - managed by the code itself) I hope somebody finds it useful. It is comes as docker image (published on every push to dev / master) so updates are quite frequent for now due to tweaks / fixes. I developed it on an Orange Pi 5+ running on Armbian . The LIVE instance is running on a Raspberry Pi. Thanks V

Description On every PR, a workflow is started to check if artifacts should be built. This happens not only once, but many times, e.g. for every selected reviewer. Since the workflow has cancel-in-progress enabled, workflows are started and immediately cancelled by the next one, resulting in many notifications (see https://github.com/armbian/build/actions/workflows/build-artifacts-pr.yml how many of the workflows were duplicates which were cancelled). Move the cancel-in-progress concurrency policy to the second job which starts only after a check is done if the 'Build' label is even active on the PR. This should greatly reduce "Workflow cancelled" notifications via GitHub and email (if enabled by the user). Documentation that concurrency can also be used on jobs: https://docs.github.com/en/actions/using-jobs/using-concurrency#example-using-concurrency-and-the-default-behavior Also don't start the workflow on PR 'reviewer_requested' trigger. It does not need to be started every time a single reviewer is added, since requesting a review does not change the build. If the 'Build' label was already added earlier, the build workflow will have been started already. In addition, don't run shellcheck if a PR message ot title was edited since it does not change the code at all. See doc: https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=edited#pull_request How it has been tested [x] Check started workflow this PR: https://github.com/armbian/build/actions/workflows/build-artifacts-pr.yml Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code View the full article

I'm using the latest kernel from the official armbian release: Kernel version: Linux 6.1.53-current-sunxi armv7l I must say that stability and temperatures are now normal.I disabled kernel updates from armbian config Honestly, I don't want to experiment with the current release kernel, i.e. CSC 6.6.x, again. I don't want to find random crashes and loose plastic cases due to the CPU having temperatures out of control. For now the 6.1 kernel lets me run everything and is still modern.

@Erica I did a fresh install of Armbian 24.5.1 Minimal on my Khadas VIM3 Pro last night, and everything worked smoothly: https://dl.armbian.com/khadas-vim3/archive/Armbian_24.5.1_Khadas-vim3_bookworm_current_6.6.31_minimal.oowow.img.xz Did you actually erase the SPI, as Igor suggested? I was not able to do that with oowow. That gave an error about the SPI not being found. However, with krescue, the SPI was cleared out successfully. Someone else provided a link to krescue for you in the other thread, if you do not have it anymore: https://web.archive.org/web/20240426161033/https://dl.khadas.com/firmware/Krescue/system/versions/VIM3.krescue.sd.220110_266.img.gz Another thing you can try is to connect a different monitor. I think that krescue uses a text mode, while most other images around initialize a graphics mode early in the boot process. Older versions of Armbian did not send HDMI signal to my monitor once it went to graphics mode in the past. But that has been resolved now.

Yes, but there are several bcm433x variants. You have to post dmesg log.

@Khadas what are you running on your Zero now, and how is it working? I've left mine on the legacy kernel (frozen) because it was working fine, but I just ran apt upgrade and I can't ssh into it, ping mostly fails, none of the audio server stuff on it is working. Hoping that connecting it by ethernet rather than wifi will allow me in; if not I'm really hosed.

Started work on syncing the helios64 dts to upstream for 6.9: https://github.com/prahal/build/tree/helios64-6.9 . I removed the overclock disabling patch as the overclock as it disables an overclock that is at least nowadays not in the included rk3399-opp.dtsi (ie cluster0 has no opp6 and cluster no opp8). It was not a high priority beforehand but as the helios64 dts starts to change, thus carries unnecessary work. The pachtset applies. The helios64 dts compile fine to dtb. Kernel built and booted. (see below for network connection, ie ethernet MAC fixup) There are not many functional changes on my side (there are in upstream dts). There are a few differences with upstream dts I did not bring as I don't know if they are leftover from the initial patch set or new fixups. But this could already have been an issue before 3.9 for most of these changes (there is at least a new upstream change 93b36e1d3748c352a70c69aa378715e6572e51d1 "arm64: dts: rockchip: Fix USB interface compatible string on kobol-helios64") I brought forward. I also brought in vcc3v0_sd node "enable-active-high;" and "gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;". Beware. ethernet MAC change (now working as designed). The fact I kept the aliases from upstream fixes the ability for the eth0 (then renamed to end0 by armbian-hardware-optimization) ethernet mac - grabbed from OTP via SPI in u-boot to be applied. Thus if you bound the MAC address that was generated by the kernel instead of from the hardware to a host and IP, you will have to find the new IP assigned by the DHCP server to connect to the helios64. I believe this is fine for edge even if not for current (so should be good for 6.9?).