All Activity

I'd also check that the RDP service is actually running and listening on the expected port. If SSH still works, you can verify the service status and firewall rules from there. That usually helps narrow down whether it's an RDP configuration issue or a network problem.

How do you write U-Boot to SPI NOR flash? Without a working driver upstream, the best I can think of now is just using the shipped U-Boot/Linux (Petitboot from the manufactor). If you want to make it from source, use the shipped cross-compiler on 64 bit PC, perhaps on an archived OS, or rewrite Makefiles. But that leaves the (for some tiny) 16 MB just for the bootloader, which doesn't even knows it's own bootdev. It seems the beforehand bootloader-loader doesn't look after SATA H DDs, only SPI NOR and/or MMC SD card.

So.... This is what I've came to with Gemini: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; /* Target the SPI0 controller */ fragment@0 { target = <&spi0>; __overlay__ { status = "okay"; #address-cells = <1>; #size-cells = <0>; /* Disable default spidev to free the bus for the framebuffer */ spidev@0 { status = "disabled"; }; /* PCD8544 LCD Node */ pcd8544@0 { compatible = "philips,pcd8544"; reg = <0>; /* Use SPI Chip Select 0 (PC3) */ spi-max-frequency = <4000000>; /* Max SPI frequency for PCD8544 */ buswidth = <8>; /* Data/Command (DC) Pin Mapping */ /* PA6 -> Port A (0), Pin 6, Active High (0) */ dc-gpios = <&pio 0 6 0>; /* Reset (RST) Pin Mapping */ /* PA9 -> Port A (0), Pin 9, Active High (0) */ reset-gpios = <&pio 0 9 0>; /* Rotate display if needed (e.g., 0, 90, 180, 270) */ rotate = <0>; }; }; }; }; I've got /dev/fb0 to show up this way. Except... It's not usable at all. Can't even print out the console. So there was no point to begin with. What DOES work though, is a Python script using CircuitPython and Blinka: # SPDX-FileCopyrightText: 2021 ladyada for Adafruit Industries # SPDX-License-Identifier: MIT """ This demo will fill the screen with white, draw a black box on top and then print Hello World! in the center of the display This example is for use on (Linux) computers that are using CPython with Adafruit Blinka to support CircuitPython libraries. CircuitPython does not support PIL/pillow (python imaging library)! """ import board import busio import digitalio from PIL import Image, ImageDraw, ImageFont import adafruit_pcd8544 # Parameters to Change BORDER = 5 FONTSIZE = 10 spi = busio.SPI(board.SCK, MOSI=board.MOSI) dc = digitalio.DigitalInOut(board.PA6) # data/command cs = digitalio.DigitalInOut(board.PC3) # Chip select reset = digitalio.DigitalInOut(board.PA9) # reset display = adafruit_pcd8544.PCD8544(spi, dc, cs, reset) # Contrast and Brightness Settings display.bias = 4 display.contrast = 60 # Turn on the Backlight LED #backlight = digitalio.DigitalInOut(board.D13) # backlight #backlight.switch_to_output() #backlight.value = True # Clear display. display.fill(0) display.show() # Create blank image for drawing. # Make sure to create image with mode '1' for 1-bit color. image = Image.new("1", (display.width, display.height)) # Get drawing object to draw on image. draw = ImageDraw.Draw(image) # Draw a black background draw.rectangle((0, 0, display.width, display.height), outline=255, fill=255) # Draw a smaller inner rectangle draw.rectangle( (BORDER, BORDER, display.width - BORDER - 1, display.height - BORDER - 1), outline=0, fill=0, ) # Load a TTF font. font = ImageFont.truetype("/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf", FONTSIZE) # Draw Some Text text = "It's working!" #(font_width, font_height) = font.getsize(text) left, top, right, bottom = font.getbbox(text) font_width, font_height = right - left, bottom - top draw.text( (display.width // 2 - font_width // 2, display.height // 2 - font_height // 2), text, font=font, fill=255, ) # Display image display.image(image) display.show() Using Nokia 5110 LCD library for CircuitPython Using CircuitPython on Orange Pi PC (apparently it's the same for OPi One) Unless /dev/fb0 on this things is even a little bit usable on the LCD, I guess I was running for circles because I was bored I've deleted the overlay altogether since it's probably useless in this case. But I think someone else could benefit from me posting all this here, I don't know. Either way, thank you for leading me along the way!

I'm not gonna explain all that. If you know the exact additions you need in the defconfig, post them here and I'll add them when I do my next PR. Which will probs be sometime this week.

@MMGen Thank you. But if you recreate the partitions, why would it matter? The new gpt partition will overwrite/ignore the mbr stuff... I'm just trying to understand here. I actually had that problem with missing backup table, but fixed it with rewriting the tables with gdisk. But I don't recreate the partition in that situation, because when I do recreate the partition the problem with missing backup table did not happen, that's why I'm confused. But I will do some testing if not copying the first 32k will actually fix that issue (or rather, if I dd /dev/zero to clear it), even though it sounds very strange to me because the backup table on gpt is on the LAST blocks, only for mbr/hybrid are they on the first.

@bedna: Actually, my previous answer was incorrect. That area is not empty: it contains the Protective MBR, GPT partition header and GPT partition table, and we don’t want to copy those for the following reasons: a) There’s no reason to do so, since we create the partitions later; b) If we did, we’d end up with a corrupted partition table anyway unless we copied the backup header and tables too. That’s why we skip this area and begin writing at 0x8000 (32k), which is where the Armbian bootloader begins. If you’re just making backups, there’s no reason not to copy all the data, however. Different goals, different methods.

I've made some progress in debugging the mpv error... I introduced some additional debug display instructions into the mpv source code, so I could see what was actually happening. And here is the new log: [vd] Codec list: [vd] hevc - HEVC (High Efficiency Video Coding) [vd] hevc_rkmpp (hevc) - Rockchip MPP (Media Process Platform) HEVC decoder [vd] hevc_v4l2m2m (hevc) - V4L2 mem2mem HEVC decoder wrapper [vd] Opening decoder hevc [vd] Looking at hwdec hevc_rkmpp-rkmpp... ctx->hwdec_devs = 0xffff64347e20 [vo/gpu] Loading hwdec drivers for format: 'drm_prime' [vo/gpu] Loading hwdec driver 'drmprime' [vo/gpu/drmprime] Using EGL dmabuf interop via GL_EXT_EGL_image_storage [vo/gpu/drmprime] Using DRM device: /dev/dri/renderD128 [vo/gpu/drmprime] ADDING DRMPRIME DEVICE [vo/gpu/drmprime] hw->devs=0xffff64347e20 [vo/gpu/drmprime] av_device_ref=0xffff64348860 ADD: ctx=0xffff6434af60 hw_imgfmt=1057 type=8 av_device_ref=0xffff64348860 num_hwctxs=1 [vo/gpu/drmprime] DEVICE ADDED [vo/gpu] Loading hwdec driver 'drmprime-overlay' [vo/gpu/drmprime-overlay] Failed to retrieve DRM fd from native display. [vo/gpu] Loading failed. Searching: hw_imgfmt=1057 device_type=12 (rkmpp) num_hwctxs=1 ENTRY 0: ctx=0xffff6434af60 av_device_ref=0xffff64348860 hw_imgfmt=1057 type=8 (drm) hw_ctx = (nil) [vd] Could not create device. [vd] Using software decoding. [vd] Detected 8 logical cores. [vd] Requesting 9 threads for decoding. [vd] Selected decoder: hevc - HEVC (High Efficiency Video Coding) [vd] DR parameter change to 1920x1088 yuv420p align=64 [vd] Allocating new (host-cached) DR image... [vo/gpu] DR path suspected slow/uncached, disabling. [vd] ...failed.. [vd] DR failed - disabling. [vd] Using software decoding. [vd] Decoder format: 1920x1080 yuv420p bt.709/bt.709/bt.1886/limited/auto CL=mpeg2/4/h264 crop=1920x1080+0+0 A=none [vd] Using container aspect ratio. [vo/gpu] reconfig to 1920x1080 yuv420p bt.709/bt.709/bt.1886/limited/display CL=mpeg2/4/h264 crop=1920x1080+0+0 A=none [vo/gpu/wayland] Reconfiguring! [vo/gpu] max content size: 1024x600 [vo/gpu] monitor size: 1024x600 The result says exactly this: VO (drmprime): add a DRM type device Decoder (rkmpp): look for an RKMPP type device => can't find it => hw_ctx = NULL => Could not create device => decoding software More precisely: ADD: hw_imgfmt = 1057 type = DRM and immediately after: Searching: hw_imgfmt = 1057 device_type = RKMPP So the problem is not: The MPP, FFmpeg, mpv does not create hwdec_devs, drmprime driver The problem is that the two components are not talking about the same type of device. Actually, that tells me something else very important: hwdec_drmprime.c from mpv was written for decoders using: Vape, V4L2, other DRM backends It creates AVHWDeviceType = DRM, instead, FFmpeg's hevc_rkmpp is a new decoder, which expects AVHWDeviceType = RKMPP. These two pieces of code were not made for each other. That also explains why the decoder exists... I have hevc_rkmpp, but mpv knows absolutely nothing about RKMPP. mpv only knows: drmprime and drmprime creates a DRM device. My logical conclusion is that the official MPV is not suitable for the rkmpp hardware (it doesn't know about its existence). So what to do ? Where do I get a suitable MPV ?

I tried installing it to the internal eMMC memory, and now it won't boot. It looks like it'll have to stay on the SD card—or is there a way to install it?

Hi all, After a recent update bumped the current kernel to the 6.18 series, the rear 3.5mm jack on my NanoPC-T6 LTS stopped playing any sound. I'm connecting it to an external amplifier that worked fine before the update. What I see on 6.18 (6.18.35-current-rockchip64): The audio card (rt5616) still shows up in aplay -l and playback commands run without errors, but no sound comes out. Volume levels and mute aren't the issue — I checked those. What fixed it: downgrading via armbian-config to linux-image-current-rockchip64=25.11.2 (kernel 6.12.58). With 6.12 the audio works perfectly again. So 6.12 works and 6.18 doesn't, at least on my board. Is anyone else seeing this on a T6 / T6 LTS with the 6.18 current kernel? Happy to share any logs or run commands if it helps to narrow it down. Thanks!

Thank you for moving my post to the appropriate section. I apologize for posting in the wrong area initially. To reiterate my question for this General forum: I have a Skyworth TV box with a Realtek RTD1325. I am looking for any guidance on whether it is possible to run Armbian on this hardware, even experimentally. Has anyone here worked with similar Realtek-based devices, or could someone point me toward resources for building a custom image for the RTD13xx family? I understand this is outside the usual supported hardware, but any advice would be greatly appreciated. Thank you.

Hi SymbiosisSystems, Same problem like you with kernel 6.18.35 and 6.18.37, all it's Okok with 6.18.10 like I said in this post:

moved

moved

Hello everyone, I am hoping to get some advice on the possibility of running Armbian on a TV box I have. I understand this is a niche device, and I am new to this process, so any guidance would be greatly appreciated. Device Information: Device Type: TV Box Manufacturer: SkyworthDigital Model: SK Hailstrom Ref 1325 Board: HPR3E1325_4k Hardware/Platform: rtd1325 Product: HPR10X Hardware Details (from system info): Core Architecture: 4x ARM Cortex-A55 @ 1700MHz Instruction Set: 64-bit ARMv8-A (32-bit Mode) Supported ABIs: armeabi-v7a, armeabi Scaling Governor: schedutil I have done some preliminary research and learned that official Armbian support for Realtek SoCs is not available. However, I noticed that there is some ongoing community development for the RTD13xx family. My questions are: Has anyone had any success with a similar Realtek RTD1325 device? Would it be possible to adapt an existing build (perhaps one intended for the RTD1319) to work with this hardware? If so, what would be the main challenges (e.g., DTB files, drivers)? Could someone point me toward the best resources or forum threads for building a custom Armbian image for this kind of Realtek platform? I have experience with the command line and following technical guides, but I am not a developer. I am prepared for the possibility that this might not be feasible, but I am eager to learn and experiment. I will, of course, proceed with caution regarding the risks (e.g., bricking the device). Thank you in advance for your time and expertise. Additional Context: I have the device rooted and can access ADB.

Hi Taz! I am trying to replicate your success with booting Debian Trixie on the Teclast T60AI tablet using the Radxa OS vendor kernel (6.6.98-vendor-sun60iw2 from the Radxa-cubie-a7z-v0.6.4 build). I am very close, but I've hit a dead end with a kernel panic on the very last stage of the boot process. I would really appreciate your advice on how you bypassed this. [ 10.852267] EXT4-fs (sda28): mounted filesystem ... [ 10.866540] VFS: Mounted root (ext4 filesystem) readonly on device 259:12. [ 10.875759] devtmpfs: mounted [ 10.881784] Freeing unused kernel memory: 1920K [ 10.887909] Run /sbin/init as init process [ 16.097167] request_module: modprobe binfmt-0000 cannot be processed, kmod busy with 50 threads for more than 5 seconds now [ 16.102268] Kernel panic - not syncing: Requested init /sbin/init failed (error -8).

My fix for what I was trying accomplish, which was to run Armbian Debian with vendor kernel with nvme boot, was to install the mainline kernel change the kernel with Armbian-config and then reinstall with option 2 'Boot from MTD; system on nvme'. Installing with this option to begin with instead of trying to flash the boot loader on MTD after the fact may have been the better choice.

for that price and feature set the odroid c4/c5 and the orange pi 5 (or 5b with onboard emmc) are the usual sweet spot. if you want zigbee i'd lean toward a board with proper usb (not just the otg ports some of the cheaper ones have) so your zigbee stick gets a clean port and a decent antenna position. one thing worth saying upfront from experience: skip the sd card for anything thats writing 24/7 like home assistant's database or pihole logs, you already know this but emmc or a small ssd over usb3 will save you a ton of corruption headaches down the line. and budget a few euro for a heatsink, the rk3588 boards in particular will thermal throttle in a closed case without one. for the support angle werner's spot on, sticking to standard/platinum boards on the download page means kernel updates keep coming and you're not chasing a dead community image in a year. raspberry pi 4/5 is the boring-but-safe option if you can stretch the budget, just because the software ecosystem assumes it exists. on the software side, since youre running pihole + HA + zigbee you'll basically be living in docker, which armbian-config can set up for you. if you ever want the rest of the self-host stack (nextcloud, file sync, vpn back in) without hand-rolling reverse proxy and certs, full disclosure im involved in an open source project called syncloud thats basically a thin layer that does one-click app installs and handles https/auth/updates for you on arm boards. its not for everyone, if you enjoy wiring up nginx and docker-compose yourself you'll probably find it too hands-off, but for a set-and-forget home box it takes the fiddly parts off your plate. either way the boards above will serve you well.

Hi, thank, I forget this method. new result... same with 6.18.37: With 6.18.10-current-rockchip64 and rk3399-kobol-helios64.dtb-6.18.18-opp dtb file, Ok With 6.18.37-current-rockchip64 and overlay helios64 patch with armbian-config, Ko With 6.18.37-current-rockchip64 and k3399-kobol-helios64.dtb-6.18.18-opp dtb file, Ko more information: On "Cold Boot": System blink red After "Reset": Same crash like without DTB file patch on previous Kernel like 6.18.10... I try edge with 7.1 kernel but not compile, finish with error during process. Back to 6.18.10 with dtb file patch and freeze with this stable config and kernel for this time, I don't have time to investigate more at this time. Have a nice day

To clarify my device currently boots but only off the micro sd card. I want to boot off the nvme.

Searching for testpoint for the MX10-L TVstick

I've ran into two issues. The first my board won't boot off the Armbian Debian vendor image. Second it boots off the mainline Debian image, but when I try installing the boot onto the MTD via option 7 in Armbian-install it completes, but I get a solid blue LED and a UART output that hangs on BL31: Preparing for EL3 exit to normal world -> Entry point address = 0x200000 -> SPSR = 0x3c9 then it hangs. Before this I tried manually erasing the SPI and loader and reinstalling them with rkdeveloptool, but this didn't help. I would provide the UART logs, but the server is failing at uploading images. I'm looking to boot off the nvme, but I'm not sure how to resolve this.

Thank you very much. Thanks to your detailed guide—as well as the one by "Chiều Nhạt Nắng"—I successfully installed Armbian on my TV box. I had struggled for a long time previously, following outdated instructions without fully understanding them; I kept unplugging and replugging the power cable, which ended up damaging the power IC (so now I have to use the USB port for power). However, thanks to your specific guidance (user 0757), I followed the steps and finally succeeded. Thank you!

Honestly, I've already forgotten what the problem was there. Most likely, I used the Armbian installer and specified where to install the distribution in the automatic image download mode. Before that, I had tried writing it manually. Besides that, I found an important nuance — if you install software through armbian-config, for example GNOME and Chromium, the Plymouth splash screen will be automatically configured at boot, and hardware video decoding will be enabled in the browser, which for some reason does not get enabled when installing manually.

Can I ask how did you fix it? I have the same problem but cannot get it to make it work.

moved to off-topic neither a supported device nor about Armbian.