baryon

With the most recent minimal Debian image, Armbian_26.2.1_Bananapim2s_trixie_current_6.18.15_minimal.img on my A311D, I hit a problem with Xorg. Instead of starting up into dwm via lightdm's autologin, all I got was the blank blinking cursor screen. Working through it with an LLM, the resolution worked out to be adding a stanza to Xorg.conf. Section "ServerFlags" Option "AutoAddGPU" "false" EndSection Is this the correct solution? Is this known or understood? I know nothing about any of this. I presume it's related to how the devices look to Xorg via the kernel, but I have no understanding beyond that level, if that's even correct.

Hah. I switched to using the cheapest one I had and that worked. But thank you for the validation. This was indeed the correct strategem.

I mean, I've verified that the image is correctly written to the SD card on my PC. So it's not that, unless the M2S itself is not reading reliably. The frustrating part is that U-Boot appears to read the image correctly enough to get going but the kernel that boots does not. Ah well. I was hoping that there was some documented problem but this forum is a ghost town, and even finding old images to try is a struggle. I'm using an old, legit Lexar 16GB SD card, so I really don't think it's a legitimacy-of-SD-card issue. Two PCs and an Android phone both tell me there's no problem with the written data here. When I set this computer up three years ago, there was no hint of any of this. It was just plug and play and all was golden.

Hello! I recently ran updates on the old M2S I won from here, and that appeared to break my OS, so I went back to try reinstall. And that's where I hit a snag. For some reason, after booting, the kernels refuse to see the partitions on the SD card. /dev/mmcblk0 exists, but none of the subpartitions, and so the boot process cannot find the partition it's supposed to boot from. Neither Armbian_25.5.1_Bananapim2s_trixie_current_6.12.32_minimal.img.xz nor Armbian_26.2.1_Bananapim2s_trixie_current_6.18.15_minimal.img.xz get me past this issue. I've tried changing the power supply, debug with LLMs, but nothing appears to be working. Any suggestions?

The problems you're facing are consistent with failing storage. Whether that's the SD or the onboard MMC remains to be seen. Of course, it might not be, either, but this would be where I start the diagnostic: try swap that SD.

Ahahaha! Nice! You beat me to it. This morning, I forked the debian-ffmpeg repo to my github and was just dropping by to see what the fella on the other thread was running so I could make a patchset branch for him and make it very simple for him. I just got the 6.0.1 ffmpeg patchset working this weekend. This is even better.

I have reproduced jock's build. He described how to do it adequately, but I'll detail my experience, as I filled in a few blanks myself. I am on the 6.1.50-current-rk322x kernel. Build ilmich's LibreELEC branch ( https://github.com/ilmich/LibreELEC.tv ) on my PC After it completes, copy the ffmpeg-4.4.1 build folder to my rk3229 Reconfigure the ffmpeg build (see below) make then make install ffmpeg Checkout c5b258b490f55c19a1cf6060bc7cf796d64f71e9 from the main MPV git meson and ninja mpv into existence The configure invocation I used differs from the LibreELEC build, but nothing big. ./configure --cpu=cortex-a7 --arch=arm --enable-static --enable-shared --enable-gpl --enable-version3 --enable-logging --disable-doc --disable-debug --enable-stripping --enable-pic --enable-optimizations --disable-extra-warnings --enable-avdevice --enable-avcodec --enable-avformat --enable-swscale --enable-postproc --enable-avfilter --disable-gnutls --enable-openssl --disable-gray --enable-swscale-alpha --disable-small --enable-dct --enable-fft --enable-mdct --enable-rdft --disable-crystalhd --enable-v4l2_m2m --enable-libdrm --enable-libudev --enable-v4l2-request --enable-libdrm --disable-vdpau --enable-runtime-cpudetect --disable-hardcoded-tables --enable-hwaccels --enable-demuxers --enable-parsers --enable-bsfs --enable-filters --disable-avisynth --enable-bzlib --disable-lzma --enable-libdav1d --enable-libspeex --enable-zlib --enable-asm --disable-altivec --enable-neon --disable-symver I tried the master branch of mpv. It did not work, but the checkout Jock used (and I documented) did. Thanks again for your work, jock. Lowest hanging fruit here is to get rid of the LibreELEC stage and just have a nice ffmpeg git repo someone can clone to save the awkward steps 1 and 2. I hope to report back with a link to such!

Oh no, @robertoj I made an error. I did not mean to mislead. I meant to say that it works on my rk322x-box, with that version. I neglected that datum. I don't use windowing environments on my box, so it was the mpv-armhf --vo=gpu --hwdec=drm --gpu-hwdec-interop=drmprime-drm --drm-draw-plane=overlay --drm-drmprime-video-plane=primary <video.mp4> command. Actually, it needs to be modified because that command gives the warning [vo/gpu] gpu-hwdec-interop was selected with the legacy name 'drmprime-drm'. Please change it to 'drmprime-overlay' in your config file or command line. Fortunately, it tells you exactly what to do, and I can affirm that drmprime-overlay works without the warning. H264 1080p60 over HDMI works fine, even coupled to streamlink. H265 did not work fine. I am not equipped to test more highly. Thank you for the detail, @jock. Trying to get things working naively, I managed to get the FFMPEG build with rkmpp support from https://github.com/hbiyik/FFmpeg linked against librga and libmpp, but that requires the old kernel, apparently. It is very difficult to find any exposition as to how these various iterations of the various subsystems work!

Confirmed working in Bookworm (Armbian 23.8.1) with the right dependencies plucked from Jammy. libdav1d5_0.9.2-1_armhf.deb libjpeg-turbo8_2.1.2-0ubuntu1_armhf.deb libx264-163_0.163.3060+git5db6aa6-2build1_armhf.deb What does it take to build this, @jock? I am very unclear on your build process. I have the notion to try adapt it to the Debian side of things as I'm not a fan of this kind of nonce package addition.

Just wanted to thank the maintainers. I'm heading out to stay at a friend's. I wanted to bring a little computer with me. My 3229 box fits the bill. Tried my Raspberry Pi 4 first, but it did not suit: I couldn't charge my phone off of it. Not only will my box charge my phone, it will also connect via USB tether to the internet through my phone. That's 2 points up on the competition!