All Activity

I don't even have an HDMI device connected. Running it headless. And when you say Debian 13, are you describing a way to convert Armbian to Debian in-place? Because honestly, with its inability to set time and missing i2c buss, I've lost confidence in Armbian. But I don't understand the effect of your commands. Is this converting Armbian to Debian 13? Is there any way to just build Debian 13 on the SD card or internal EMMC?

Ok, will try wiFi by doing that. I posted more testing in the thread of my device.

Hi, I've tried to setup the latest Debian 13 (Trixie) for the Renegade board. I can flash the image with no issue. The problem comes it boots up, prompts for root password. I can type in then press enter, and then it goes to login. This only happens on the Debian 13 (Trixie). I am using the Debian 12 XFCE imange no issue. I am not sure if this is a bug or what, but I loved to use Debian 13, I am trying to setup Docker with the latest OS.

thanks~

I Installed radxa os (debian) again which works fine and tried to scan SPI flash via terminal but It was sequences of all zeros and then all ones, so no I presume no information stored in SPI, just to be safe I also erased it. After some experimentation I found that I cannot control armbian terminal through UART and that's why I thought it hanged but I managed to connect via SSH (ty @eselarm) with ethernet to my laptop and custom DHCP and everything worked okay. The only problem is that HDMI still does not work. HDMI shows connected but I get this error from dmesg:

I guess this should do:

As the wifi device is the same please see my last post in this thread : Viz : Also to fix BT : sudo crontab -e then add the line : @reboot sudo hciattach -s 1500000 /dev/ttyS1 any 1500000 flow nosleep It could also be your dtb though. You could decompile my dtb from this thread and use the Bluetooth related section.

Usually people switch off the HDMI monitor of the computer and and walk away. Or they put a mirror against the monitor and ask the person they see why they bought a computer that does not have Debian installed?. Why am I here? Do I need a CD-ROM drive to install from ISO myself? How do I enter the BIOS? Does it have BIOS? But there is hope. Aarch64 Debian13: root@odroidn2:/boot# apt install linux-image-arm64 root@odroidn2:/boot# ln -sf vmlinuz-6.12.57+deb13-arm64 Image reboot root@odroidn2:/boot# apt install u-boot-amlogic-binaries root@odroidn2:/boot# dpkg -L u-boot-amlogic-binaries | grep odroid-n2 /usr/lib/u-boot/odroid-n2 /usr/lib/u-boot/odroid-n2/u-boot.bin /usr/lib/u-boot/odroid-n2/uboot.elf /usr/share/doc/u-boot-amlogic-binaries/configs/config.odroid-n2.gz

Hi @robertoj and @WDR_s I am having a similar screen ILI9486 from waveshare that i am trying to make it work with Milk-v duo S board. https://www.waveshare.com/wiki/3.5inch_RPi_LCD_(B) I was able to drive ST7789v and see content on screen with below code dts file &spi3 { status = "okay"; /delete-node/ spidev@0; st7789v: st7789v@0 { compatible = "sitronix,st7789v"; reg = <0>; spi-max-frequency = <48000000>; spi-cpol; spi-cpha; rotate = <0>; fps = <60>; rgb; buswidth = <8>; dc = <&porta 18 GPIO_ACTIVE_HIGH>; reset = <&porta 28 GPIO_ACTIVE_HIGH>; debug = <0x0>; status = "okay"; }; }; But trying to make ILi9486 work is next to impossible for me. I tried the dts file modification that worked for @WDR_s before he implemented touch. But this also does not work for me. And just for information dc-gpios and reset-gpios does not work for me and i have to name it dc and reset or else device /dev/fb0 is not created. &spi3 { status = "okay"; #address-cells = <1>; #size-cells = <0>; /delete-node/ spidev@0; ili9486: ili9486@0 { /* IMPORTANT: fb_tft binds MUCH more reliably to this */ compatible = "ilitek,ili9341"; reg = <0>; status = "okay"; /* SPI MODE 0 (correct for Waveshare ILI9486) */ spi-max-frequency = <24000000>; /* Use SAME pins that worked for ST7789V */ dc = <&porta 18 GPIO_ACTIVE_HIGH>; reset = <&porta 28 GPIO_ACTIVE_HIGH>; rotate = <0>; bgr = <0>; fps = <30>; regwidth = <16>; buswidth = <8>; txbuflen = <65536>; debug = <3>; /* Long, safe init sequence */ init = <0x10000b0 0x00 0x1000011 0x20000ff 0x10000C0 0x0D 0x0D 0x10000C1 0x43 0x10000C5 0x00 0x48 0x80 0x10000C7 0x00 0x1000036 0x28 0x100003A 0x55 0x10000B1 0xB0 0x11 0x10000F0 0x01 0x10000F6 0x00 0x01 0x32 0x1000026 0x01 0x10000E0 0x0F 0x31 0x2B 0x0C 0x0E 0x08 0x4E 0xF1 0x37 0x07 0x10 0x03 0x0E 0x09 0x00 0x10000E1 0x00 0x0E 0x14 0x03 0x11 0x07 0x31 0xC1 0x48 0x08 0x0F 0x0C 0x31 0x36 0x0F 0x10000B6 0x02 0x02 0x3B 0x1000011 0x20000ff 0x1000029>; }; }; This is very critical for me and i would really appreciate if you could make things work for me. Is the kernel 5.10 a issue here? as my SPI pins work for other display but not just for this display.

`idbloader.img` is device-specific code that is created from firmware build artifacts with U-Boot as payload using proprietary tools available only in binary form. SBC providers rarely offer ready-to-use code. I therefore prefer to load my firmware from microSD cards. Since it has apparently become increasingly common lately to provide only the MASKROM mode as the sole reliable recovery method, I have started building my firmware for Rockchip devices as RAM images as well. I can then simply upload them using MASKROM mode and start my work from there without having to rely on proprietary, binary-only tools.

Agree. @Igor

Thank you Werner, I propose to put this statement red boxed on top of this rpi landing page. Too many rpi5 help seekers get puzzled, they should be informed, to find more stuff in forum discussions. Greetings

While having this sent to mainline would be overall best, the faster approach in the mean time would be to send a patch via PR to this location to have it included into Armbian kernel packages: https://github.com/armbian/build/tree/main/patch/kernel/archive/rockchip64-6.18

At this time we do not have plans to support it. However anyone is free to step up and provide support with a pull request. We'll happily review. Perhaps chainxs will do this since they're an active volunteer contributor already

When support for Raspberry Pis has been added there was no model 5 yet. With the intention to only support the flagship the board configuration was added as rpi4b.conf. Since then support was extended across all models from 3 and up. However renaming a board config file is an issue. I already had the idea to address that but gave up on it: https://github.com/armbian/build/pull/7881 tl;dr: rpi4b image will work on all models from 3 to 5. https://www.armbian.com/rpi4b/

Hi All, Just coming across this now, and struggling with EMMC boot on 5B seems to be a theme on various forums.. May I ask where to retrieve `idbloader.img`? Thanks! Mark

I have verified that Wi-Fi is working, and I have also figured out how to install to eMMC. However, after running armbian-install, the system only boots if I put MiniLoaderAll.bin into the firmware field of the “Upgrade Firmware” session in Rockchip-AndroidTool while the device is in Maskrom mode, and then press the Upgrade button. MiniLoaderAll.bin It appears to be an SPI-related issue, but at the moment I don’t see any way to resolve it. I am also having difficulty getting Bluetooth to work. If you have any information on this, your assistance would be appreciated.

I see. Ok so Armbian sees only one IRL i2c buss, and stuffs any 'inconvenient' other devices into a useless buss. IOW Armbian is busted, at least for the ODroid N2+. Why use it then?

Probably more experienced users will not have similar issues, but I'll provide my solution just for for the record: Power off devide. Insert SD card into the slot. Hold 'boot' button on the mainboard. Plug in device. Release 'boot' after 5 seconds. Power off and power on. in my case it took up to 60 seconds before my device boot from SD card. I checked the same with USB and it also work (*it ust be plugged into one of USB2.0 ports). Thank you for your suggestion. I'll close the thread.

Some updates... After rebooting (power off and power on) the device.... this appears and Armbian won't boot anymore...

Someone was able to run Armbian on the Arduino Uno Q. So, maybe Armbian will support the board in some future, hopefully. But due to no available test image or further information beside this tweet, I don't expect that currently, at least in a near future.

So I made a second test with your image. I changed to a 32GB SD card because the other one's capacity was an old 4gb one and run out of space when installing some stuff. I run your image as is in my device. I don't change the DTB to the extracted one from Android partition, because if I do so, I get black screen. I managed to install kodi and xfce4 desktop (xinit and lightdm are required to make it work, as I understand) sudo apt update && sudo apt upgrade sudo apt install xfce4 xinit lightdm I realized I could run Kodi without xfce desktop... just typiing "kodi" command. Before doing so I plugged my pendrive in the USB3.0 port and checked it was mounted. I did some file exploration with ls commands, mount, lsblk etc... but at the end when opened Kodi it was detected as "New_volume" which is the drive's name. For my surprise: When moving through Kodi's menu, the "tic" sound came out from my TV. So: HDMI sound was working Added the movie's folder to the Kodi library and it searched all the stuff that Kodi does (movie posters, tittle, information, etc.) Hit play on one of them and movie played fluid ! movie spec: 1080p and H264 codec I looked for another movie encoded with H265 (HEVC) file... and it played but with some "stuttering". I don't know the cause, if USB is not working at 3.0 speed, or GPU is running slower than expected (or other reason) --> The same file in the same pendrive in the same port, when running the device's Android and Kodi, plays perfectly smooth. Also: In ANdroid Kodi es v21 and the one in Armbian is v20.5 ; maybe some HW acceleration issue there? In conclusion, at the moment, with the original @johlnx image (v0.3, the latest at the moment of testing), for this board (pics in first post of this thread) I have: USB2.0 port: Working: used for wireless keyboard+mouse receiver USB3.0 port: Working, used for a 64G Pendrive (I don't know if it was recognized as USB 3.0 or 2.0, I don't know hoy to check that, yet) HDMI-Video: Working HDMI-Audio: Working (played few movies with 2ch audio content) HDMI-CEC: Not tested, don't know how to do it, yet. SD card reader: Working, as device boots from SD card. LAN: Working WiFi: Not fully tested, (I could only "See" networks , but did'nt connect to them as I was using the device wired.) So it is supposed to be working. Will fully test it in another moment. IR and LCD: Not tested, I don't know where to start with those (will appreciate some help) Analog A/V output: Not tested yet. I can do more tests if some of you consider it, just ask me. The more specific information (and how-to's...) the better. Thanks

I recently got a Raspberry Pi 5 and installed Armbian on it. Most things work fine, aside for some weird output issues in htop and nano. I noticed, when I go to the Raspberry Pi page on Armbian, the url refers to the Pi 4b, not the 5. I also found some articles online linking to a specific Pi 5b page (which I thought was weird since that model doesn't exist), but it just redirects to the 4b page. Then, I went searching in the archive and found that, at some point, there were specific 5b images available (https://armbian.hosthatch.com/archive/rpi5b/archive). Which of these should I use? Is the 4b image okay to use on a Pi 5? Or do you not support the Pi 5 at all? Sorry if this has been answered before, it is kind of impossible to search this forum for similar questions with the super aggressive rate limiting.

I have a Radxa Zero 3E and was facing the same issue. Since RK3566 is a stripped down version of RK3588. I figured the quirks on RK3588 might be able to apply to RK3566 as well. The issue seems to be fixed now after I implemented these quirks taken from rk3588-base.dtsi on top of rk356x-base.dtsi. tested on Linux 6.17.9 and 6.18.0-rc7(Armbian linux-edge-rockchip64) usb_host1_xhci: usb@fd000000 { compatible = "rockchip,rk3568-dwc3", "snps,dwc3"; reg = <0x0 0xfd000000 0x0 0x400000>; interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cru CLK_USB3OTG1_REF>, <&cru CLK_USB3OTG1_SUSPEND>, <&cru ACLK_USB3OTG1>; clock-names = "ref_clk", "suspend_clk", "bus_clk"; dr_mode = "host"; phys = <&usb2phy0_host>, <&combphy1 PHY_TYPE_USB3>; phy-names = "usb2-phy", "usb3-phy"; phy_type = "utmi_wide"; power-domains = <&power RK3568_PD_PIPE>; resets = <&cru SRST_USB3OTG1>; snps,dis_u2_susphy_quirk; + snps,dis_enblslpm_quirk; + snps,dis-u2-freeclk-exists-quirk; + snps,dis-del-phy-power-chg-quirk; + snps,dis-tx-ipgap-linecheck-quirk; status = "disabled"; }; If anyone else has other RK356x devices please try it out and I think it would be nice if someone could submit a patch to mainline kernel dts.

@Gavin Munday Did you compile a desktop or server image? Did you write the image onto a reliable sdcard? Remember there’s no framebuffer support. Server images need a usb to serial device attached to the UART. Having a usb serial device attached to the UART helps with these types of problems. https://docs.radxa.com/en/cubie/a7a/system-config/uart_debug Also, first boot might take awhile to boot. For desktop images wait at least 5 minutes for a display manager login screen.