All Activity

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.

sadly my a7a doesnt doesnt boot with the image that outputs from the build

I don't understand then, what is the problem?

You don’t actually need a static route on PC1. Since PC1 already has a default gateway (192.168.100.254), anything outside 192.168.100.0/24 is automatically sent there. So PC1 isn’t the source of the routing problem. The real issue is on the 10.10.10.x side: Device1 has no gateway. Without a gateway, it can receive packets coming from the Linux box, but it has no way to send replies back to a different subnet. That’s why the communication fails. The fix is simply to give Device1 a valid gateway pointing to the Linux box. Device1: IP: 10.10.10.2 Mask: 255.255.255.0 Gateway: 10.10.10.1 On the Linux box: sudo sysctl -w net.ipv4.ip_forward=1 This is enough to route between NIC1 and NIC2. If Device1 cannot be configured manually, the Linux box can offer a small DHCP service on NIC2. A minimal dnsmasq example: interface=enp4s0 dhcp-range=10.10.10.50,10.10.10.150,255.255.255.0,12h dhcp-option=3,10.10.10.1 This simply ensures Device1 learns “send everything through 10.10.10.1”. Once Device1 has a gateway, the Linux box will forward traffic correctly and PC1 will reach it without needing any static route at all. Useful resources: https://wiki.archlinux.org/title/Router https://askubuntu.com/questions/205017/how-to-define-the-range-of-ips-using-dhcp https://pingmynetwork.com/network/ccna-200-301/dhcp-dynamic-host-configuration-protocol

I don't think so, then my Virtual Machine run would fail the same way as you describe, but it doesn't, it works fine. Of course it is the meson64 kernel running on top of KVM/virt machine, the RTC for example is emulated, while for your real N2+ is a specific Amlogic SoC kernel driver I assume, so there something could be wrong. Or what about clocking tree, there are many failures possible. I know for rockchip64 there were 2 RTC modules, at some point in time 1 was chosen over the other, so a change, could also introduce issues. You could browse kernel changes/patches And also what about an unknown bad/corrupted diskblock or so. I normally use Btrfs for rootfs, so easy to check for and detect corruption. So maybe re-image again. I am still not sure if I used the same image as you, but up to you to track that. You can do the same thing as I did to see if it is maybe a specific Amlogic driver issue; Run that image as VM on the same N2+, you need a network bridge with main eth port or else use NAT. Or you make it first efi bootable, then it can run easier in virt-manager GUI. N2+ is fast enough to run VMs, I even do that on ROCK3A (2GB RAM, 4x Cortex-A55). Or use standard Debian Trixie kernel on real N2+, not sure if that works good enough. Or remove/disable RTC kernel module. Or also remove fake-hwclock stuff if you haven't already done that. I did not do it for this VM run, but when real RTC+battery, I would remove or disable it.

@Gavin Mundayhttps://github.com/NickAlilovic/build/blob/Radxa-A7A/config/boards/radxa-cubie-a7z.csc

found it wasnt using correct tree..;p

i have, board not there unless it using some other name?