All Activity

BTW I found also another weird behavior. I have more of the RockPi E boards. All are 1.21 version and bought in one batch. I have SD card with the trunk 316 Pluck Armbian, and on one board the ethernet doesn't work, but on another 2 yes... Also even more weird thing, on the working board when I install 24.8.3 and the do full-upgrade, it also doesn't work... So maybe it's also some time race of the reset?

It is. I have workaround it, but updating process needs some improvements. Once mirrors get in sync, it should be operational.

Thanks for the reply. I noticed, that in u-boot the ethernet is not detected. So the solution to this problem should be updating the u-boot.

orange pi 4 lts 4gb ram, 16gb emmc. TV - 4k LG - there is terminal for 5.18-rk3399 (bsp) - there is edid-decode -

OK so after I've connected successfully and ran the upgrade for kernel, what do you know, the OS booted :)) Anyway, managed to log it and here's a diff of boot from before and after the upgrade https://www.diffchecker.com/ER6op67Q/ What I can tell is that some addresses for memory I think, seem to have changed Anyway, thanks a lot guys for helping and eventually fixing the issue, even if I don't know what changed Hopefully will continue to work fine for the foreseeable future

@Gwolf2u Hate to disappoint, but if your YP-01 serial converter is based on PL2303 chip, it will not work with Rockchip CPUs based boards as pl2303 doesn't support baud rate of 1 500 000 required for Rockchip CPUs (table 6-2 in the attached datasheet). DOC001036118.pdf

The repository hasn't changed the inventory of zfsutils-linux and zfs-dkms for several days. I guess there is some kind of problem? https://repo.jing.rocks/armbian-apt/dists/jammy/jammy-utils/binary-arm64/Packages

Hi to everyone. I've installed community build Armbian on a Nanopi R1S-H5 and all ok but i see two differents Wlan (Wlan0 and Wlan1). If the board has only one wifi nic, how is this possible? Is there an error in any configuration file or in other place? Thanks in advance.

Great! See https://wiki.radxa.com/Rockpi4/dev/serial-console for a guide on how to connect the serial lines to the board and setting up a terminal program. The wire colours are different, but take a look at the picture on that link: Do not connect the +5V or 3V3 pins GND cable needs to be connected to the 3rd GPIO-pin (GND) on the top/outer side of the connector (the black wire in the picture) RX cable needs to be connected to TX, that's the 4th GPIO-pin, just below the GND wire (it's white in the picture) TX cable needs to be connected to RX, that's the 5th GPIO-pin, just below the RX wire (it's green in the picture) (If you can't connect, then RX and TX needs to be swapped. Don't worry, having these lines swapped won't break anything, it just doesn't allow a connection when wrong.) Then start the terminal program (e.g. putty on Windows or minicom on Linux, both described in that link). When booting the RockPi, you should see the boot messages in the terminal window (otherwise try swapping RX/TX). Keeping the spacebar pressed (in the terminal program, make sure it is selected) should then interrupt the bootloop and you should be able to copy&paste the output. If interrupting still does not work: Putty has the opption to copy the whole content to clipboard: Right-click the title bar and select "Copy All to Clipboard". Then paste it into an editor. Once you have pasted that log into an editor, you can try to clean it up a little bit, it may contain several boot attempts. It would be sufficient to include just one complete boot attempt and the start of the next. But if in doubt, use the complete log. Finally post that log here.

Whoops forgot to add that, there are no pwm related overlays on armbian install.

Check if there are pwm overlays available in /boot/dtb/allwinner/overlay. If so try enable via armbian-config or manually with overlays= in /boot/armbianEnv.txt

I thought it was Arm7, and remember it can only run 32 bit stuff.

Hello! PWM seems to work without any configuration on the factory images with the gpio command, but I cant seem to get it to work on armbian. There doesn't seem to be any dtbs related to pwm, and /sys/class/pwm is empty on armbian. Anyone got this to work? EDIT: Forgot to add, doesnt seem to be any pwm overlays present on armbian install

Hi I installed https://dl.armbian.com/rock-5c/Bookworm_current_minimal-homeassistant, configured it to my liking (OS on a mirrored ZFS pool) to discover there is no WiFi, no Bluetooth. It's now kernel 6.12.17-current-rockchip64. Anybody managed to get WiFi and BT working with this kernel? Thanks, Chris

So am trying here to provide more info. Friend of mine borrowed me a usb to serial adapter, but clueless on what to do. On Windows I know about Putty, but would like to do it on Ubuntu. Below is my hardware, so please let me know how I can provide more info (what wire goes where) !?

Honestly, the way it works right now is good enough, it just seemed weird for me since I couldn't find much info about this topic online (both the armbian-config thing, and the btrfs thing) I'll just post the issue on github after writing up some proper documentation behind it! Thanks again!

moved

I've been running ARMbian on my "H96 Max" for 36 hrs now, ha in VLC, i have noticed that if i play the 720 in the native default window, and don't maximize it, it plays perfect with no dropped frames, but it still tears now and then !!. it's because the video does not have to be rescaled. So obviously, the problem is that Hardware Decoding will not work with VLC, and that VLC and ARMbian are just not optimized and not up to the job !!. I have heard that with my "H96 Max"ARM and almost any other SoCs, that they can just not handle the task in ARMbian and in general, , , i was suprized to see the 4 CPU's run a 50% !!, i expected it to be no more than 10 If you can get it to work 4K on crappy ARM based Android LINUX, then it's not the SBC hardware, , its ARMbian !! So the main problem is that HVA is not fully supported in my Armbian, and SVA is not working as it should, so a problem with ARMbian again, , , I have been a Computer Technician since 1997 and have seen SVA work perfect on a a lot lesser system, , , , ,Hmmmm, , my 4 Core ARM based "4K fire tv stick max" is a joy to use !!, , , will have to look at the look at its ARM SoCs, especially its GPU

Use of the RTL8211F phy-id in a compatible will stop it from properly being detected as a RTL8211E, so not a good idea. Mainline Linux will not always handle a reset of the RTL8211F Ethernet PHY, at least on Rockchip boards when reset- properties is defined in the PHY-node, so you will end up with a "Could not get PHY" error unless the RTL8211F PHY has been reset by the bootloader prior to Linux. Newer versions of U-Boot does this correctly, older versions like the U-Boot 2022.07-armbian-2022.07 version as seen in your logs does not even try to reset the Ethernet PHY. Upgrading to a newer (and safer) version of U-Boot should solve your issue (and similar issues when Rockchip and RTL8211F is involved for other boards). Using vanilla mainline U-Boot 2025.01 and vanilla mainline Linux 6.12 on a ROCK Pi E v1.21 does not have any issues to identify the Ethernet PHY: U-Boot 2025.01 (Apr 03 2025 - 06:04:07 +0000) Model: Radxa ROCK Pi E DRAM: 1 GiB (effective 1022 MiB) PMIC: RK805 (on=0x40, off=0x00) Core: 247 devices, 30 uclasses, devicetree: separate MMC: mmc@ff500000: 1, mmc@ff520000: 0 Loading Environment from MMC... Reading from MMC(1)... *** Warning - bad CRC, using default environment In: serial@ff130000 Out: serial@ff130000 Err: serial@ff130000 Model: Radxa ROCK Pi E Net: eth0: ethernet@ff540000 Hit any key to stop autoboot: 0 ~ # ip link set eth0 up [ 27.617316] rk_gmac-dwmac ff550000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 27.679150] rk_gmac-dwmac ff550000.ethernet eth0: PHY [stmmac-1:00] driver [Rockchip integrated EPHY] (irq=POLL) [ 27.690181] rk_gmac-dwmac ff550000.ethernet eth0: No Safety Features support found [ 27.690902] rk_gmac-dwmac ff550000.ethernet eth0: PTP not supported by HW [ 27.692259] rk_gmac-dwmac ff550000.ethernet eth0: configuring for phy/rmii link mode ~ # ip link set eth1 up [ 32.070210] rk_gmac-dwmac ff540000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 32.153078] rk_gmac-dwmac ff540000.ethernet eth1: PHY [stmmac-0:01] driver [RTL8211F Gigabit Ethernet] (irq=53) [ 32.165523] rk_gmac-dwmac ff540000.ethernet eth1: No Safety Features support found [ 32.166268] rk_gmac-dwmac ff540000.ethernet eth1: PTP not supported by HW [ 32.167621] rk_gmac-dwmac ff540000.ethernet eth1: configuring for phy/rgmii link mode

I have a T9 rk3328 tv box with rtl8723bs wifi. This chip got burned out a hot day and the box powers off when is on. There is a way to kill the sdio?

latest build Armbian-unofficial 25.05.0-trunk noble, 6.12.11-edge-sunxi64, cinnamon 6.04 tanix-tx6s-axp313.csc working: 3 USB, Wifi, IR remote not working: Bluetooth, sound jack, LED Clock, Video Acceleration (LED Clock worked on previous builds 250329) rebuild image and install again is same. vontar-h618.csc, working: 2 USB, Wifi (needed to rename brcmfmac4334-sdio.rockchip,rk3318-box.txt > brcmfmac4334-sdio.txt), IR remote, LED Clock, sound jack not working: Bluetooth, Video Acceleration.txt

Hi @ketzercat I have 4 different images.. Try them see if they work for you. https://github.com/NickAlilovic/build/releases/tag/20250306

I didn't express myself clearly: I meant that I am "the advocate of more serious and supported solutions", I meant precisely ARMbian, as opposed to Arch where BananaPI and OrangePI are not officially supported. Sorry for the confusion. For OrangePI, I can see that nothing changed since their beginning, where they were starting their business by simply cloning LeMaker website and all the efforts the community did for the original BananaPI board 🤐

Without maintaining, those boards (upgrades) simply stop working. This is one of the ways how it manifests. Features starts to break apart and we have to spent insane amount of time trying to keep this herd operational. Every board has its own caveats. And here we also have OS release upgrade - deprecated OS. There are enough of troubles without that. Start with a new image and see if it works. Upgrade from Bullseye to Bookworm is problematic and I advise you to not deal with that if you are not experienced.

What is wrong with Armbian in production? Where you anyway have to work with kernel / firmware under your control. We have several cases. But yeah, hardware support wise, one needs to be careful what to choose. Here OS is irrelevant anyway. You are welcome (to join). If you go that route, remember that it is usually a lonely one and sharing here gives some companionship. Forum can provide some tech but mainly moral support, share some tips and ideas, but expect that nobody have much time to do the homework instead of you - answering "why this doesn't work", "how to fix this and that feature", ... Most of those questions require research - some are already answered but not integrated, so forum search is probably best 1st step. AI is also getting better every day and can help in some cases ... If you convert some popular unsupported board into supported (within Armbian), we can help more. Working with them made us bigger financial loss and worse software support. Most of what they provide SW wise is what they get from Allwinner (SDK) + board level adjustment or they steal (our framework) or push their buyers to milk open source projects. We suffered biggest loss and some had to close their projects down to this negative impact. They also re-brand-port our work into "Orangepi OS Debian / Ubuntu" and "Orangepi Arch OS" with help of Manjaro, which is yet another dirty FOSS player. They also produce fake Kali, fake Armbian and other fake images by themselves. To make sales and leverage support costs to others, mainly to us. We will keep supporting some old boards for end users, but we won't be touching any new HW from them. Association between brands and articles from years ago exists and still makes us damages. They will keep sucking from Armbian without contributing a single cent. They are directly stealing from our work and this is their business model and there is little we can do about except informing you. They always could make a donation, like everyone else, but they never found that button. tl;dr; Fake.