All Activity

If I understood a bit better what the script is doing, i.e. this part: Then maybe I could help with updating it to work with the Radxa products.

Raised up a PR with a patch. 🤞

I think i've managed to work around this, and set HS200 mode. I did this by decompiling /boot/dtb/rockchip/rk3588-nanopc-t6.dtb, modifying the mmc@fe2e0000 section to remove the mmc-hs400-1_8v; and mmc-hs400-enhanced-strobe; lines, adding a new mmc-hs200-1_8v; line and then recompiling it again. dtc -I dtb -O dts -f /boot/dtb/rockchip/rk3588-nanopc-t6.dtb -o rk3588-nanopc-t6.dts # Modify rk3588-nanopc-t6.dts here dtc -I dts -O dtb rk3588-nanopc-t6.dts -o /boot/dtb/rockchip/rk3588-nanopc-t6.dtb After rebooting, I confirmed that it was now running in HS200 mode: [ +0.010753] mmc0: SDHCI controller on fe2e0000.mmc [fe2e0000.mmc] using ADMA [ +0.034734] mmc0: new HS200 MMC card at address 0001 [ +0.000571] mmcblk0: mmc0:0001 A3A444 230 GiB I ran a heavy random read/write test, and observed no errors. However, I think this will be lost during a future update - so i'll see if I can figure out how to submit a patch!

Correct. Many Radxa SBC’s work this way. RockPi-S, RockPi-S0, RockPi-E, E20c, e25c, e52c, rock-pi-zero, etc.

Is this your SD card? This is your eMMC just 3.6G in size. This is the first time I have met this variant. We need to think about whether it is possible to add an exception for this case.

df -h Filesystem Size Used Avail Use% Mounted on udev 159M 0 159M 0% /dev tmpfs 47M 4.8M 42M 11% /run /dev/mmcblk1p1 58G 3.4G 53G 7% / tmpfs 234M 76K 233M 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 234M 4.0K 234M 1% /tmp /dev/zram1 47M 2.4M 42M 6% /var/log /dev/mmcblk0p1 3.4G 2.0G 1.3G 62% /media/emmc tmpfs 47M 0 47M 0% /run/user/0 lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mmcblk1 179:0 0 59.6G 0 disk └─mmcblk1p1 179:1 0 59G 0 part /var/log.hdd / mmcblk0 179:32 0 3.6G 0 disk └─mmcblk0p1 179:33 0 3.5G 0 part /media/emmc zram0 252:0 0 233.1M 0 disk [SWAP] zram1 252:1 0 50M 0 disk /var/log zram2 252:2 0 0B 0 disk lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Armbian 25.8.1 bookworm Release: 12 Codename: bookworm uname -r 6.12.44-current-rockchip64 I don't have an easy way to do the serial terminal thing to check U-Boot. I have updated it to the "latest" using armbian-install, however...

Was the auditd disabled ? Without it is difficult to see where the sysrq comes from. Re. monitoring ttyS1: you could try use screen: sudo screen /dev/ttyS1 9600 Replace 9500 if needed with the baud rate configured in the UPS

Hi, that's me again after a recent very bad sysrq incident on my system (I was away for a couple of days and the system went down for this time). I count > 5000 "sysrq: HELP" messages this time, 77 requests for loglevel changes (to 0, 4 or 8), 9 "show regs" requests, 1 "show state" and 4 "dump ftrace buffer" request. All this during 30 mins. The UART / USB converter was connected to ttyS0, but the PC on the other end was off. But I shall add that I also have connected the status output line of my UPS to ttyS1 (this is an "UPSPACK_V3" board that watches the 5V input and has a Li polymer battery connected). Could it also be that this system sends spurious BREAK commands that issue a SysRq event? And if yes: Is there a simple way to watch this interface? Maybe by temporarily logging the UPS board's UART Tx? Greetings.

@oscylator678 I used this PPA https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco Mesa 23.0, PanVk has already Vulkan 1.4.

Impressive! How did you get DXVK-stripped v2.7.1 to work? Full DXVK v2.7.1 requieres Vulkan 1.3, which is not yet available PanVK (I got Device does not support required feature 'fillModeNonSolid' when tried)

Please post the output of the df -h and lsblk commands here. Which image are you using and which version of u-boot is running on your board? (this can be seen in the UART console)

@Fredrik thank you for testing.

It seems like there is a mix-up between specs for the framework and for the OS. A lightweight desktop can run on 512MB, yes but probably not much fun, depending on applications. Won't recommend running a web browser. I'd probably get some existing cheap sbcs with similar specs and play with them to elaborate if the performance is sufficient.

Oh! I guess I reported this same issue a while ago - never got an answer. Is there a github repo to report issues with this program?

Hello, I am planning to desgin a Computer-on-Board, but would like to know what are the minimal specs needed for it to run a graphical user interface with a desktop. Doing a simple Google Search gives me two answers: "512 MB RAM memory, at least 8 GB of storage (on a quality SD card or eMMC), a 4-core processor, and wired networking. For a more advanced Armbian build framework, you'll require a system with at least 8GB of RAM and 50GB of disk space, although specific requirements vary depending on the hardware." My main issue with this is that it doesn't explain directly if 512 MB of RAM and a 4-core processor (and what frequency?) are enough for the most lightweight GUI desktop.

Thank you very much. I will try it. Thank you very much. I will try it.

Can someone explain these lines? # find real mmcblk device numbered 0, 1, 2 for eMMC, SD for ret in $(find /dev -name 'mmcblk[0-2]' -and -type b) do if [ -b ${ret}boot0 ];then emmc_dev=$ret else sd_dev=$ret fi done On the RockPi-S, $ret would equal mmcblk0 and mmcblk1 which are the eMMC and SD card, respectively. There's no device called "mmcblk0boot0" or "mmcblk1boot0".

I can confirm that my changes have now been merged into the upstream linux_openfd repo, so I have deleted my fork. Unfortunately I am unable to edit my instructions, but hopefully it should be clear from the instructions that if my fork is unavailable, then the original repo should be used (alternatively, if a mod could edit the post to remove the reference to my fork, to make the instructions clearer, that would also be appreciated).

Small update. The hack below seems to work as well. $ sudo systemctl edit armbian-hardware-optimize.service Add the following content between comments [Unit] Before=basic.target systemd-networkd.service netplan-wpa-wlan1.service Please note that armbian-hardware-optimize was picked at random to force anything that touches wlan1 to wait until slightly later in the boot process. No tests were done to determine at what exact point in the boot process wlan is "safe" to interact with.

Thanks for the reply, Tall Man. In a way, that was the point. My experience is really only with my home network use and with nvme information displayed by linux tools which seem to insist on the xnypz suffix on the root word nvme. I continued reading up on the general topic overnight and it seems that in the dtb tree world, the focus is on structuring cohesion and delaying actuating instances, so I am guessing different (more general) descriptors are used. My query was whether the precise descriptor was correct as I could see other options possible, one of which had, I think, popped up elsewhere. Since I had seen other reports of difficulties in loading systems to devices, I thought it a remote possibility that a typo had crept in. I still havent found anything definitive in my reading re the formats of the abstractions in the dt stack. I am interested in knowing about this but I as my Armbian is up and running now, and I identified the actual issue for me was a sd card error, the pressure is off . So, I hope this ramble was not too tedious and I do appreciate that you took the time to answer, and again, thanh you cheers

I am not sure if I am using the git command correctly to get mpv-0.3.9 with PR14690.. Please help roberto@orangepizero3:~$ mkdir mpv-official roberto@orangepizero3:~$ cd mpv-official/ roberto@orangepizero3:~/mpv-official$ git clone https://github.com/mpv-player/mpv roberto@orangepizero3:~/mpv-official$ cd mpv roberto@orangepizero3:~/mpv-official/mpv$ git checkout -b release/0.39 roberto@orangepizero3:~/mpv-official/mpv$ gh pr checkout 14690 <- downloads and applies the v4l2request changes roberto@orangepizero3:~/mpv-official/mpv$ nano video/out/gpu/hwdec.c <-- I see the added changes in the hwdec.c file roberto@orangepizero3:~/mpv-official/mpv$ meson setup build <-- everything configures ok, but at the end, it shows that I got mpv-0.40 I asked in the mpv github and a contributor said they are waiting for ffmpeg first incorporate v4l2request, then they will add the feature in mpv Applying the pr14690 manually on top of mpv 0.3.9 is something that i could do, if there’s no choice

i've updated the image to include info on screen like IP / cpu usage / ram usage (in %) any software can write to /tmp/screen to change content you can download here

mpv official github repo. v4l2request commits are in a pull request.

This MainsailOS pull request contains a cb1 trixie image that is working. It does forces NetworkManager instead of netplan. After flashing look for a wifi txt file on the BOOT partition to pass wifi credentials.

I thought that v4l2request was exclusively in this github project and branch: https://github.com/philipl/mpv/tree/v4l2request Which github project and branch/release are you trying? I successfully compiled and installed the mpv from https://github.com/philipl/mpv/tree/v4l2request I made the /etc/mpv.conf as per the original post Result: 50% cpu in 4 cores, about half dropped frames: I don't see any mention of hwdec=drm in the mpv log I used the libplacebo from Trixie, not compiled on my own... I can try that next. <- final update for this post: libplacebo downloaded and built by myself did not help... but now I will try mpv 0.3.9