Active threads

@Benedito Portela thanks for reply I have another gigabit router that works, but It doesnt have Fiber optics and tnelefone. Idk If this is useful. I contacted my provider because they don't offer access to the router. They said all ports are on automatic and it only works at 100/1000 Mbps. I've tried everything, even changing the TV Box's speed negotiation, but it doesn't support it. The only way that works is to put a device between it and the main router.

Some more info, maybe : When I run get-edid | parse-edid, I get this : ~# get-edid | parse-edid This is read-edid version 3.0.2. Prepare for some fun. Attempting to use i2c interface 1 potential busses found: 0 256-byte EDID successfully retrieved from i2c bus 0 Looks like i2c was successful. Have a good day. WARNING: Checksum failed Trying to continue... Section "Monitor" Identifier "ASUS VS228" ModelName "ASUS VS228" VendorName "ACI" # Monitor Manufactured week 43 of 2011 # EDID version 1.3 # Digital Display DisplaySize 480 270 Gamma 2.20 Option "DPMS" "true" Horizsync 24-83 VertRefresh 50-75 # Maximum pixel clock is 170MHz #Not giving standard mode: 1920x1080, 60Hz #Not giving standard mode: 1280x960, 60Hz #Not giving standard mode: 1280x1024, 60Hz #Not giving standard mode: 1440x900, 60Hz #Not giving standard mode: 1680x1050, 60Hz #Not giving standard mode: 1152x864, 75Hz #Not giving standard mode: 1280x720, 60Hz #Not giving standard mode: 1280x800, 60Hz #Extension block found. Parsing... Modeline "Mode 16" -hsync -vsync Modeline "Mode 0" +hsync +vsync Modeline "Mode 1" 25.200 640 656 752 800 480 490 492 525 -hsync -vsync Modeline "Mode 2" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 3" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 4" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 5" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 6" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync Modeline "Mode 7" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync Modeline "Mode 8" 74.250 1920 2448 2492 2640 1080 1082 1089 1125 +hsync +vsync interlace Modeline "Mode 9" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace Modeline "Mode 10" 54.054 1440 1472 1596 1716 480 489 495 525 -hsync -vsync Modeline "Mode 11" 54.054 1440 1472 1596 1716 480 489 495 525 -hsync -vsync Modeline "Mode 12" 54.000 1440 1464 1592 1728 576 581 586 625 -hsync -vsync Modeline "Mode 13" 54.000 1440 1464 1592 1728 576 581 586 625 -hsync -vsync Modeline "Mode 14" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 15" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 17" +hsync +vsync Modeline "Mode 18" +hsync +vsync Modeline "Mode 19" -hsync -vsync Option "PreferredMode" "Mode 16" EndSection So, it looks like my monitor/cable/kernel is able to read the EDID from my actual monitor correctly. However, I am still unable to get a 1920x1080 resolution, and I find it strange that I would get this result after forcing a edid.bin file on the kernel arguments. Shouldn't I get back the EDID from the forced EDID bin file instead of my actual monitor?

thanks, pulled it.

Hello Павел NetAid, put sd card in windows and resize the small partition with disk format tool.

I'll try those ag123, thanks!

I've followed your suggestion and used the configure sw. I've solved. Thank you.

Hi all, I managed to install Armbian on a X96 Linux TVBox with 4Gb RAM and 32Gb ROM. I've build the image following the Armbian Build Framework. - v25.08 rolling for aml-s9xx-box running Armbian Linux 6.12.37-current-meson64 I reused the DTB that originally comes with the BOX and almost everything seems to work. I tested the system using glmark2 with a score of 197. I suppose GPU is working. Anyway I've some problems with Electron. I have installed the "hello world" app. The application starts but I receive this error: [4150:0714/130924.545719:ERROR:ui/gfx/linux/gbm_wrapper.cc:79] Failed to get fd for plane.: No such file or directory (2) [4150:0714/130924.547711:ERROR:ui/gfx/linux/gbm_wrapper.cc:261] Failed to export buffer to dma_buf: No such file or directory (2) Any suggestion? Davide

I encountered the same issue using a custom v25.08 "RPi4b" image with kernel 6.12.37-current-bcm2711. I found out, that adding the following line to /boot/firmware/config.txt brings back the missing i2c device: However, this used to happen automatically with the old "RPi5" images.

https://paste.armbian.com/evuxesilum

For Linux CP2102 doesn't work at 1.5 megabaud or 1500000 baud. for linux I discovered the CH341A I2C programmer. I just set it to TTL by a jumper and use it as 1.5 megabaud TTL UART 1500000 baud

@ER Samson To help figure out why your unit is stopping you could connect to it via an ssh session and as root run "journalctl -f". this might catch any error messages just prior to failure. When running with logs in zram, as Armbian does, the last messages in the logs are quite often lost when the system abruptly stops.

ADVANTECH EPC-R4680?

I bring the board up to use it on metal and Low level development, I use pci-e for jtag but I never considered the possibility of using an nvme there In my opinion, if you have a board that is running with internal emmc and sdcard you can provide an adjustment for pci-e NVME, It is a small adjustment, related to just one functionality of the board. I hope I'm not the only one with this board in my hands

I'll try

Apparently I'm an idiot and did not fully read the instructions linked. I had not previously copied the files as per the instructions. Doing so allowed box64 to compile most of the way, and I then ran into the issue described here. I tried deleting the file as described and that did not help. I am unsure if my rpi zero 2w will work to compile it, but I shall post an update once I test that, then try copying the file over.

Hello Jock, thank you for all the work bringing this video acceleration to our boards. Can you give an updated comment about what to download or how to build Armbian OS, and get the needed requirements, before we apply the ffmpeg repository? I haven't been able to get video acceleration for many months. Can you tell us what new kernel modules are needed also?

vendor branch is based on latest rockchip bsp which is 6.1.115 atm. You can use code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } armbian-config to switch.

Hello Mark, Sorry, I think I solved the problem by creating a readme file. Now you can create a fork of the github projet: https://github.com/GuillaumeLopere/Armbian-TX95Max-AllwinnerH618/fork - Then you can add documents with "+" and "Upload files" - "Choose your files" and Check the box "Create a new branch for this commit and start a pull request" I think this is the easiest way to do it. Best regards, Guillaume

https://bugs.launchpad.net/ubuntu/+source/postgresql/+bug/2116789

OK I've actually found the crux of the issue, though I haven't tried to figure out specifically what causes it yet. I ordered another Dumb TypeC->DP adapter cuz I figured there might be a bridge in my last one that was messing things up. It did the same thing with the messed up colors and shifted image. Then I remembered I have a typeC dock that's smart and has a DP port and it works fine. Checking Dmesg I noticed the dock sets up link training for 2 lanes @ 8.1Ghz. The dumb adapters with the bad color train 4 lanes at 2.7Ghz because that's what my display advertises. The Orange Pi5 Plus manual states: 1 x Type-C (DP 1.4A) output, up to 4K@60FPS To meet that bandwidth it needs to supply either 4 DP lanes @ HBR2 or 2 DP lanes @ HBR3. I reprogrammed My display's bridge (it's custom) to advertise only 2 DP lanes at 2.7Ghz. Now that's what the Opi does and the image is perfectly fine. So I think what happens here is the Orange Pi 5 may not actually have 4 lanes to supply over type C but it's configured so that it will try if requested. The 2 lanes of DP it can supply are incomplete as they are expecting to be merged with the other 2. When using a smart typeC dock, it intercepts the display's DPCD report and says "I only have 2 lanes at HBR3 so that's what I want". On a Type C dock with USB ports it's not possible to pull 4 lanes out of the host connection because the other 2 lanes have to be used for USB3.x. So basically the Opi has to be told the sink only has 2 lanes or it will screw up when it delivers 4 lanes and can't. I assume that's the correct assessment cuz I can plug this thing into any other PC with a real DP or type C alt and the color is fine, reporting 4 lanes over DPCD. I assume this is probably a device tree thing, I'll update the git issue on Opi's kernel repo, just figured it'd be good to let anyone trying to use it what might be going on.

Hello, I have a MXQ Pro 5G 4K TV Box with Allwinner H616 and the motherboard IK316-EMCP_V4.1. I am looking for a server (CLI only) version of the Armbian image for this device. The previously shared Google Drive links in this topic are no longer working. Could someone please provide a new download link (Google Drive, MEGA, etc.) for the latest server image compatible with my device? If there are any specific instructions for booting or the correct DTB file, please let me know. Thank you very much! Best regards, Luska1331 BTW: I generated this message with the help of Copilot because I don't speak English very well.

Difficult to say how to fix without further logs. What I am looking into and what it could possibly be related to is the simpledrm module loading alongside sun4i-drm. I wonder if you remove simpledrm then does the cursor become less erratic? Without diverging to far off topic, I suspect this related to sun4i-gpadc and how the temperature sensor is polled is carried out. The 6.12 Hdmi patches are a backport of the changes found in 6.15.

Thanks for the hint Sirmalinton. Today, I could solve the problem. Here is a short summary that might be of use for people running into similar issues. Running lspci -k shows the "Non-Volatile memory controller" but it does not show the line "Kernel driver in use: nvme". Hence, I ran echo nvme > /sys/bus/pci/devices/0002\:01\:00.0/driver_override echo 0002:01:00.0 > /sys/bus/pci/drivers_probe where 0002:01:00.0 is from the output of lspci -k. That worked and made the disk appear as files /dev/nvme0*. To have a solution that works after reboot, I created a udev rule /etc/udev/rules.d/99-nvme-override.rules with the content: ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x144d", ATTR{device}=="0xa80d", ATTR{driver_override}="nvme" The vendor and device IDs are from lspci -nn. To trigger the probe, I created a systemd service /etc/systemd/system/nvme-rebind.service with the content: [Unit] Description=Rebind NVME controller to driver after override After=udev.service [Service] Type=oneshot ExecStart=/bin/sh -c "echo 0002:01:00.0 > /sys/bus/pci/drivers_probe" [Install] WantedBy=multi-user.target The service can be enabled via systemctl enable nvme-rebind.service. Maybe one reason it does not work in the first place is because /lib/systemd/system/nvmefc-boot-connections.service is not started. The reason is that the condition ConditionPathExists=/sys/class/fc/fc_udev_device/nvme_discovery is not met. Another reason, I can imagine is that the vendor/device ID combination is not registered to the nvme driver in the current kernel. As I mentioned before, it did work out of the box when I installed Armbian at first.

@Igor thank you for fixing overlay-prefix problem in current armbin-config now on OZPI V1 and V3 overlays in armbianEnv.txt are without prefix