Jump to content

All Activity

This stream auto-updates

  1. Past hour
  2. You could attempt to recover ur current install by adding the required DTB to the SDCARD and see if the unit boots. Once booted, mount the eMMC and again copy the dtb to the needed dir. DTB DIR: /boot/dtb/rockchip/ rk3566-nanopi-r3s-lts.dtb
  3. According to ur log. It's pulling down an older kernel. This kernel does not have the DTB required so it's failing to boot. After purging the kernel on the current IMG available and installing the kernel from apt. https://paste.armbian.com/orokufexik The result is a missing DTB. root@nanopi-r3s-lts:~# ls /boot/dtb/rockchip/rk3566-nanopi-* /boot/dtb/rockchip/rk3566-nanopi-r3s.dtb
  4. Cannot reproduce. Also R3S LTS /w 2G memory and eMMC. apt update && apt upgrade went through. Reboot just fine. https://paste.armbian.com/usakitotak
  5. Today
  6. How to debug boot issues: https://debug.armbian.de
  7. Hello there ! - nanopi R3S 2GB ram / 32 GB SD card and 32GB MMC here. - Image running: Armbian_25.5.1_Nanopi-r3s-lts_noble_current_6.12.33 An upgrade (armbian-upgrade or apt-get upgrade), both on SD card or MMC, breaks boot of the system, reboot or cold start fails, stuck in system red-light. Both SD or MMC boot at broken. Need to reflash the SD and boot + reinstall. See attached some logs. Thanks ! nan0r r3s-armbian-apt-upgrade.log r3s-armbian-armbian-upgrade.log
  8. oops, I missed reading that 100% cpu, but it is ok it is a a53 after all 😅 videos I'd guess is still 'difficult' on z3, accordingly there is some support for gpu vector graphics but I'd guess mostly just triangles. video decoding can be done with just neon (vector computation) , but i'd guess there is still limited access to video decoding hardware. using neon is likely to give that 100% cpu reading as the cpu is busy literally, using real video hardware would be 'invisible' in a sense, the cpu usage may look low but that one won't see that the video hardware itself may after all be reading 100%.
  9. Copying the file over from my rpi zero 2w didn't work. I may try compiling on a different OS on the opi tomorrow to see if that will compile fully.
  10. @laibsch It would be good to get this solved as there are a lot of boards out there and they are expensive kit, also this effects both Armbian Ubuntu as well as Debian. I was hapilly running my own Ubuntu Plucky Armbian Unofficial and had desktop functioning fine on my BananaPi-M7 for several apt-get upgrades. I use ssh mainly as I run it as a server for development purposes, but like to use desktop for dev purposes too. Then suddenly the screen went blank and looked like it was continually trying to start up. On reinstalling Armbian Ubuntu Nobel, then Plucky again I worked out that Gnome had been running as v46, but at some point Ubuntu had reverted to v44. I am not sure if this was the breaking change but it seems to at least be parallel. i.e. it was working and I can demonstrate it working and not working repeatedly. Hi @Cesar R. I will run through your repo mods tomorrow and see if I can replicate. It would be good to get this fixed for both Ubuntu and Debian on BananaPi-M7 and Radxa Rock 5B+ and the other boards for Armbian. As I say theres a lot of boards out there and they are expensive. Maybe some of the board manufacturers would pay towards the fix also ? I am just in it for the solution as I need the boards for dev work.
  11. Yesterday
  12. Been a bit but posting just in case. Doing exactly this with the same image you have downloaded (vendor kernel armbian cinnamon). OBS in bookworm is actually a bit too old (there is a segfault on opening the HDMI In), and the newest version does not run on Bookworm because of a too old ffmpeg. I got this setup working by updating the image to Trixie and compiling OBS myself. OBS (in any capacity) on the Panfrost driver can be launched by setting the GL mode manually using: PAN_MESA_DEBUG=gl3 obs
  13. I've just be trying again and have managed to get X running on my Nano. But not very well I fear. My first problem is that the Nano can't read the screen EDID. I get lots of "transfer timed out" errors for i2c-1 in the log. I believe this is the ddc connection to the HDMI port. Has anybody here seen this issue and found a solution ? The killer I hit before was that Xorg would hang when first checking the ports (e.g. /sys/class/drm/card0-HDMI-A-1). What I have found is that removing /dev/dri/* before starting X avoids this hang and I do get my desktop and all works. But it seems awfully risky to delete files such as /dev/dri/* and I'm hoping there's a better way. The hang could be an Xorg bug because the same hang happens on a Raspberry Pi 5 when running a 64-bit system but not when running a 32-bit system. As the Nano can't read the EDID it will default to 1024x768 mode. If I force an EDID using drm.edid_firmware=xxx in the kernel command line I can get 1920x1080 on a small HD screen but not on other 1920x1080 screens I've tried. What could confuse the issue here is that I'm running a custom 6.6.87 kernel and use sysvinit rather than systemd. So perhaps my problems are partially self-inflicted. But I have managed to get my 4GB Nano running X with one monitor. The video driver is only the fbdev driver so how well it works with videos etc. remains to be seen. Cheers, Steven
  14. Regarding video acceleration in H618: Can you try the latest armbian with linux edge? https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/#findComment-216587 (the announcement refers to 6.13, but I don't know if it applies to 6.14 or 6.15) ... I think armbian 25.5.1 with linux edge option, builds linux 6.13.x https://github.com/armbian/build/releases/tag/v25.5.1 (and it seems that minimal images de-activates v4l2) I see the patches in my armbian build folder, I compiled in many ways, but I didn't get video acceleration. I didn't get new kernel modules that seem to be related to the patch source code. Perhaps I needed to check that the specific patches are activated or find the linux config option=m
  15. FWIW rkvdec will be out of staging in 6.17 Be prepared to forward-port existing out-of-tree patches. cedrus has not seen much movement since a long time It can therefore be assumed that all necessary out-of-tree modifications from the past must be applied even with the latest kernel version. Since no mainline developments have taken place, no forward porting should be necessary.
  16. @psygnosis Which version of Armbian and os are you running? Yesterday I loaded current noble on a test system and I just noticed that it is running hot (45) even with a significant heat sink. Another operational system that is running current bookworm runs much cooler (32). If you are running noble, could I ask you to try bookworm to see if there is a difference. I will load up my test system with bookworm to check also.
  17. Hi, I have 2 OPi1 that I want to use for some test projects. One project consist just on PiHole, the other one on Tailscale. Since with newer kernel I have high temperature on idle (like 70°C) can you advice me an old version that maybe has a "better" thermal management? Thank you so much, if I'm saying something stupid please tell me, maybe I just need to tune something like disable hdmi, gpu etc...
  18. hi guys, Danubio from Uruguay successfully tested very nice QPC2 Sinclair QL emulator (hybrid m68k + win32 peripheral code) on armbian with hangover 🙂 https://theqlforum.com/viewtopic.php?t=5330 he is testing lot of old windows music apps on armbian this way, so I asked him also to test QPC2, this was one of my cool use cases for armbian too (busy here with other things still so ... my way to linux is very slow ...) Petr
  19. My story is definitely NOT a success story I see the media.patches in the cache folder, I compile armbian edge, but the image didn't contain the cedrus+v4l2 kernel modules I need for decoding acceleration
  20. Some progress : I noticed the warning "checksum failed" when I do get-edid | parse-edid on my asus monitor. As a test, I connected a Dell monitor instead and I don't get the checksum error with it. Also, after a reboot, I do get a full HD 1920x1080 resolution on the Dell monitor! So, the real issue appears to be that the kernel override does not work, the kernel still reads the EDID from the monitor even when fed the extraarg line extraargs=drm_kms_helper.edid_firmware=HDMI-A-1:edid/edid_asus_vs228.bin video=HDMI-A-1:1920x1080@60 drm.debug=0x4 from my defective edid asus monitor, or from the correct generic /lib/firmware/edid/1920x1080.bin file. How do I go about solving this? Who should I talk to? Who builds the armbian kernel? Is there a switch when building it that can be changed to solve this?
  21. @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.
  22. 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?
  23. It did not work. Here is the new boot log. My extraarg line looks like this now : extraargs=drm_kms_helper.edid_firmware=HDMI-A-1:edid/edid_asus_vs228.bin video=HDMI-A-1:1920x1080@60 drm.debug=0x4 boot.txt
  24. Ok, so probably the timings (frequency) for the 1920x1080 is rejected by the kernel. I took the EDID in your boot log: 00 ff ff ff ff ff ff 00 04 69 fd 22 01 37 02 00 2b 15 01 03 80 30 1b 78 2a 2a c5 a4 56 4f 9e 28 00 50 54 b7 ef 00 d1 c0 81 40 81 80 95 00 b3 00 71 4f 81 c0 81 00 02 3a 80 18 71 38 2d 40 58 2c 45 00 dc 0c 11 00 00 1e 00 00 00 ff 00 42 41 4c 4d 54 46 31 34 35 31 35 33 0a 00 00 00 fd 00 32 4b 18 53 11 00 0a 20 20 20 20 20 20 00 00 00 fc 00 41 53 55 53 20 56 53 32 32 38 0a 20 20 01 b7 and asked ChatGPT to decode it and create a .bin file. Here's the xrandr modeline (just for info): Modeline "1920x1080_60.00" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync And the .bin file is attached. I suggest you put the .bin file it in the Armbian location for edids (I don't remember, maybe /lib/firmware/edid/) and try to boot with it (armbianEnv.txt): drm.edid_firmware=HDMI-A-1:edid/asus_vs228.bin See what happens. edid_asus_vs228.bin
  25. This meeting is open to anyone currently contributing or interested in helping shape the newsletter going forward. Discussion Topics Strengthening the newsletter process and its impact Expanding our contributor base (authors, vendors, community voices) Improving the flow of raw content from developers Gathering better feedback from readers Ensuring the publishing process runs smoothly We're especially looking for: Fresh ideas to make the newsletter more useful and engaging A volunteer to take on reviewing and approving the first draft before publication 📅 Meeting Details Location: Discord –> Armbian Server -> Lounge Channel Duration: ~45 minutes Looking forward to seeing you there!
  26. Hello Павел NetAid, put sd card in windows and resize the small partition with disk format tool.
  1. Load more activity
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines