rpardini

Hey @Timo12357 this was identified before. Check https://github.com/armbian/build/pull/5766 Please check against beta/testing repo? Thanks

Thanks for reporting this, should be fixed in https://github.com/armbian/build/pull/5914

Some progress has been made, 6.6-rc5, new alsa-ucm-conf and firmware. Try the "Armbian Trixie - Gnome Desktop" image available at https://www.armbian.com/lenovo-x13s/ under "Other supported variants", that might work: filename is Armbian_23.8.6_Thinkpad-x13s_trixie_sc8280xp_6.6.0-rc5_gnome_desktop

@c0rnelius graciously submitted GitHub PR to upgrade u-boot that effectively removed the patch in question from the equation for the Radxa Zero. While it was nice to "boot USB first", since it enabled a few interesting scenarios (boot non-Armbian EFI OSes in USB disk), it's not worth having it if normal Armbian operation is impacted. I've advocated for this usb-first style to be default around u-boot 2022, but we're now moving to board-specific support (and removing completely in the case of the Zero) for 2023+.

Yeah that. Well, cpufrequtils and big.little clusters don't mix well as you probably noticed. cpufrequtils itself has been deprecated for well over a decade. Since cpufrequtils was being inflicted on otherwise perfectly working, DT-controlled boards, we've disabled it by default. Boards that are proven to require it can re-enable it directly on the board as you've already found out or in the Armbian board file via 'CPUFREQUTILS_ENABLE=true' All that said, the real, kernel-supported alternative, cpupower, requires kernel-tools build which is currently not provided by Armbian (nor is usbipd, perf, nor any other kernel userspace tool, due to the complexities of release-dependent building of parts of kernel which is normally userspace-agnostic).

Sorry what are you talking about? Which board? Why you mention me here? 😉

Please build with `SHARE_LOG=yes` and send us the URL so we can check. That's due to the pd-mapper and qrtr in userspace working. (Only for lunar, coming from ubuntu x13s ppa) Yep it has a hid bind loop that is work-arounded via some udev rules... it's strange. Mostly, yes. I'd say send your patches to steev, or add them to Armbian. Copy the x13s board file and change the DTB. If this works we can refactor/unify more later... Yeah take a look at the x13s board file, you'll find something really similar. I have not kept up to the rapid amount of changes after 6.3.y. I might try to update to 6.6, since that's gonna be LTS.

Definitely pick the PR and build whatever userspace you need, there's not much that is userspace dependent (maybe mesa, but I've not tested desktop usage). I've tested on Bookworm, Jammy and Lunar, all work great. Also: UMS mode works absolutely great. Use an SD + recovery button to deinfest, after that you can stop u-boot with the serial console and for example run "pci enum; nvme scan; ums 0 nvme 0" and be able to flash to NVMe via UMS (usb otg) without any SD or eMMC. Also2: you can fix the MAC address stored in the u-boot env in SPI to match the board sticker if you want. Otherwise, MAC address is generated based on CPU serial number, which is stable, but does not match what's on the sticker. Dunno where HK stores the sticker value (maybe some fuse/OTP?)

https://github.com/armbian/build/pull/5606 Testing image: https://github.com/rpardini/armbian-release/releases/download/23.08.18-rpardini-434/Armbian_23.08.18-rpardini-434_Odroidm1_bookworm_edge_6.5.0-rc6.img.xz #### `odroidm1`: de-infest Petitboot 🔥 use Kwiboo's 2023.10 u-boot; UMS works; bump kernel to 6.5-rcX - `odroidm1`/`edge` (`rk3568-odroid`): bump to 6.4.y, update config, rebase patches to 6.4.10 - `odroidm1`/`edge` (`rk3568-odroid`): bump to 6.5-rc6; manually fix RK808 breakage in .config; externalize overlays; use Makefile autopatcher; rebase patches - `odroidm1`/`edge` (`rk3568-odroid`): drop 6.3 and 6.4 patches - `odroidm1`: de-infest Petitboot 🔥 use Kwiboo's 2023.10 u-boot; UMS works - using Kwiboo's `rk3568-2023.10` branch with BINMAN-handled blobs - patches (defconfig unless indicated): - boot usb first (rockchip-common) - blink leds & keep red one one on preboot; reset SPI env once after deinfesting from Petitboot - change usb_host0_xhci to otg (u-boot dtsi) - enable DM_GADGET, UMS 🔥 and RockUSB - **usage instructions**: - build & burn image to SD card - insert SD card into board - **hold the recovery (RCY) button** and power on the board - watch board boot - **de-infest Petitboot**: use `armbian-install` to install bootloader to MTD - if you don't, you'll need to hold the recovery button every boot - optionally: use `armbian-install` to install OS to eMMC/NVMe/USB - power-off board - remove SD card (new u-boot always boots SD first!) - boot into your newly de-infested machine - boot order: USB, SD, MMC, NVME, SCSI - de-infested machine can now boot (directly) from USB/SATA/NVMe, possibly via EFI: - Armbian UEFI-arm64 - Fedora 38 aarch64 - HASSOS for ODROID-M1 - Talos arm64 - others... - extra: new u-boot by Kwiboo (with GMAC patches) gives us stable MAC address - although it is based on cpuid#, doesn't match the HK sticker on the board - run `fw_setenv ethaddr XX:XX:XX:XX:XX:XX` to change eth addr in SPI flash environment if needed - `odroidm1`: update DDR/BL31 blobs (this depends on https://github.com/armbian/rkbin/pull/20)

Hey @Erica please try this experimental image: https://github.com/rpardini/armbian-release/releases/download/latest-images/Armbian_20230600_Khadas-vim3_bookworm_edge_6.4.0-rc5.img.xz Instructions, for any VIM3, in any state (middle button 3 times in 1 second tells the MCU to force the SoC to boot from SD/eMMC). -> Write oowow (https://dl.khadas.com/products/vim3/firmware/oowow/vim3-oowow-latest-sd.img.gz) to SD card. Insert SD card with oowow. -> Power on board, press the middle button 3 times + reset until it reboots into oowow. -> Use oowow to clear the SPI ("fast" method is enough) *and* the eMMC ("fast" method is enough). -> Use oowow to set "bootmode" to SPI. (This way it will try SPI, which is empty, then eMMC, which is also empty, then SD). -> Power off the board (important. MCU changes don't take effect unless you power it off completely). -> Write Armbian to SD card, insert the SD card with Armbian. -> Power on the board. Boot Armbian from SD. Use `armbian-install` after preparing the partitions on the target device (eMMC/NVMe/USB). Good luck.

User on Discord reported problems using the -rt patches with the main branch on Amlogic edge. 1) RT patches are specific to certain linux versions, and the fact most of our families use say 6.2.y branch (and we can't easily override KERNELBRANCH= due to the tangle between board/boardfamily/family_common source order conundra). Would need to either hack at the meson64_common file to change it to to "tag:6.2" to use the 6.2.0 release, or use a hook in a config file to to the sam. Suggestion: add a FORCE_KERNELBRANCH param to work around this more easily for users without requiring a config file change. 2) RT patches add in a ./localversion-rt file, which is picked up by Kconfig and included in CONFIG_LOCALVERSION, which changes the paths of _everything_ from what Armbian expects. Say from "6.2.14-meson64" to "6.2.14-rt3-meson64". The kernel builds, but packaging gags. It's possible to remove the patch that adds that file so the version matches, but Armbian definitely should be able to handle this more gracefully, either by automatically removing "localversion-*" files, or by actually honoring them.

Ahn, ok, that literally only affect the filename of the produced images, not the versions of packages or anything that is published to repo, which is what I was worried about.

Sorry Igor I missed this during the call. This might... lead to problems, since we lose numerical sort comparison if we do this. Say "230501" and "230602" and "231000" and "240200" all sort correctly. But "23501" and "23602" and "231000" and "24200" are... broken.