RSS Bot

Description Add pwm fan support to NanoPi R4S. Document from FriendlyElec: https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R4S#How_to_Control_Fan_Speed_for_Cooling And reference code: https://github.com/friendlyarm/kernel-rockchip/commit/f74ac319f02e2d22cdd33227e7f167e4232809f9 How Has This Been Tested? build and run on R4SE hardware. [x] fan works [x] /sys/devices/virtual/thermal/thermal_zone0/trip_point_[3/4]_temp controls two speed of the fan Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Description This PR enabled USB port present on the expansion board for the OrangePi Zero 2 sbc. This change applies to the current current variant of the OS for this board (Kernel 6.1.y). (Similar PR for 6.2.y kernel here: #5344) How Has This Been Tested? Requirements: Any USB stick with basic file system present (eg. exFAT) and some files / folders on it Logged in as root or as a user with sudo priviledges [x] Test A: make sure the change does not break the board when used WITHOUT the expansion board Boot up the board Check whether the base USB port still works correctly lsusb shows the USB stick when plugged into the port mount /dev/sda1 /media/<mountpoint> is able to mount the USB stick plugged into the port [x] Test B: check whether the ports work when expansion board is plugged in Plug a USB stick into one of the additional ports Check whether the tested port works correctly lsusb shows the USB stick when plugged into the port mount /dev/sda1 /media/<mountpoint> is able to mount the USB stick plugged into the port ls /media/<mountpoint> properly enumerates files / folders on the stick umount /media/<mountpoint> is able to unmount the USB stick Repeat for the other port on the expansion board Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description This PR enabled USB port present on the expansion board for the OrangePi Zero 2 sbc. This change applies to the current edge variant of the OS for this board (Kernel 6.2.y). How Has This Been Tested? Requirements: Any USB stick with basic file system present (eg. exFAT) and some files / folders on it Logged in as root or as a user with sudo priviledges [x] Test A: make sure the change does not break the board when used WITHOUT the expansion board Boot up the board Check whether the base USB port still works correctly lsusb shows the USB stick when plugged into the port mount /dev/sda1 /media/<mountpoint> is able to mount the USB stick plugged into the port [x] Test B: check whether the ports work when expansion board is plugged in Plug a USB stick into one of the additional ports Check whether the tested port works correctly lsusb shows the USB stick when plugged into the port mount /dev/sda1 /media/<mountpoint> is able to mount the USB stick plugged into the port ls /media/<mountpoint> properly enumerates files / folders on the stick umount /media/<mountpoint> is able to unmount the USB stick Repeat for the other port on the expansion board Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

@adeepn @rpardini As discussed here: https://github.com/armbian/build/pull/5315 In order to update to the latest rtl8822cs BT firmware for the G12/SM1 family of boards and still provide the downstream firmware for the AXG/GXL family, I created an apt hook to ensure the proper firmware stays in place. I unfortunately can’t test this beyond creating an IMG as I don’t own the unit and the firmware isn’t currently committed. In order to test, someone would need to boot an IMG built from this commit, add the latest firmware to the booted unit and install a package to see if the apt hook works. Firmware commit: https://github.com/pyavitz/armbian-firmware/commit/a7bf7c7cc8a85dbbc28c1c409e09b11917ebc2b6 Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [X] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Looks like this got missed when removing KERNEL_ONLY. Having it here in the first example causes that example to fail, Remove it. [x] Test build with KERNEL_ONLY fails [x] Test build without KERNEL_ONLY passes Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have made corresponding changes to the documentation [x] My changes generate no new warnings View the full article

Description Since of historical reasons script armbian-install is still creating a log file with name /var/log/nand-sata-install.log as well as using other artifacts from folder /usr/lib/nand-sata-install. I would like to align those names to comply with the original script name having been run: If run as nand-sata-install => create /var/log/nand-sata-install.log, lookup artifacts in /usr/lib/nand-sata-install If run as armbian-install => create /var/log/armbian-install.log, lookup artifacts in /usr/lib/armbian-install To achieve 2. I did: rename folder packages/bsp/common/usr/lib/nand-sata-install -> packages/bsp/common/usr/lib/armbian-install - since this is now the most likely current one. create a symbolic link packages/bsp/common/usr/lib/nand-sata-install linking to packages/bsp/common/usr/lib/armbian-install for backward compatibility. How Has This Been Tested? Tested on a board (Cubietruck) installed. Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings View the full article

Description Hello all, This PR adds support for the Texas Instruments SK-AM64B. Features, schematics, and purchase links can be found on the board page[0]. We work to ensure our silicon/boards have "Upstream First" Linux support, so this board makes use of stock upstream U-Boot and Linux, no patching needed to utilize the full set of feature. The only odd part here is our first-stage bootloader, which is built from fetched sources separately (see compile_k3_bootgen() in k3.conf). If a pre-built binary for this is preferred just let me know. Thanks! [0] https://www.ti.com/tool/SK-AM64B How Has This Been Tested? [x] Build/Boot tested Bookworm CLI/Minimal on Current(v6.1) and Edge(v6.3) kernels [x] Build/Boot tested Jammy CLI/Minimal on Current(v6.1) and Edge(v6.3) kernels [x] Dual Gbit Ethernet works [x] Dual-band Wi-Fi works [x] USB 3.1 Gen 1 works [x] OSPI and SD card works Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Description As per tittle. How Has This Been Tested? [x] Build test Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings View the full article

Event Dispatcher, part of the upcoming WirePlumber 0.5 configuration system refactoring, is a custom PipeWire event scheduling mechanism designed to address many of the fundamental issues in WirePlumber. View the full article

Description adjust broken patches on CURRENT disable packaging patch on legacy Jira reference number AR-1780 How Has This Been Tested? [x] Build test only Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description Including fixes for: Nanopi Neo, Pine64so, Helios64 (removing legacy branch), Opi 2e, Sunvel r69 Jira reference number AR-1780 How Has This Been Tested? [x] Build test only View the full article

https://armbian.atlassian.net/browse/AR-1001 added function to unmount and format MTD flash added menu entry for said function. added form mtd Jira reference number AR-1001 How Has This Been Tested? added nandsim and virtulied the MTD. https://gist.github.com/Tearran/e704f04a6fbc457a56dc5f5f87f8899d created a virtual MTD mounted /temp/boot created a file to erace Unmounted then remounted to confirm file still exist ran mtd-tools format confirmed no data remained created function and ran with same results Checklist: [?] My code follows the style guidelines of this project [*] I have performed a self-review of my own code [?] I have commented my code, particularly in hard-to-understand areas [NO ] I have made corresponding changes to the documentation [?] My changes generate no new warnings [?] Any dependent changes have been merged and published in downstream modules View the full article

Description Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. Jira reference number AR-1690 How Has This Been Tested? Testing is WIP right now. [X] Booted on Nanopiduo2. U-boot reports starting of crust and also shows crust version Checklist: [X] My code follows the style guidelines of this project [X] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [X] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

drivers_network rtl8812au: skip removal for odroidxu4/current so it patches OK again drivers_network rtl8812au: skip removal for odroidxu4/current so it patches OK again# Brief detour. Turns out that HardKernel's vendor odroidxu4 kernel already has this driver # "slipstreamed" into it, complete with a bunch of PDF files and other junk. # See https://github.com/hardkernel/linux/tree/odroid-5.4.y/drivers/net/wireless/rtl8812au # If we remove them here, the resulting patch will contain binary diffs which are unsupported by patch(1). # So if building for the odroidxu4/current, we'll leave the original files in place, and just overwrite # the possibly-updated source files (not PDFs and such). Thanks, HardKernel. View the full article

Description After merging #4958 many patches are breaking the build. We need to adjust them. Jira reference number AR-1780 How Has This Been Tested? [x] Boot test Nanopi Neo Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Complete Desktop updates for bookworm. This update follows the debian approach of desktops following the task-(desktopname)-desktop install . I also had to split the skel for each desktop to keep installs cleaner as only the files for that desktop get installed and not files for other desktops not in use on the build. skel.all skel.(desktopname). I have done a complete update to the appsgroups and we moved printing and filesharing support to the appgroups to make things cleaaner in the long run. a few new appgroupds added and apps added and removed. everything done . was done with feedback from users. Note : At this point desktops imgs will be bigger then the 8g sd card and shold be moved to 16 gig sd cards by default. I ran multi builds to confirm everything builds and works as it should out of the box. View the full article

Description Bumped current kernel to 6.1.33. Also disabled some Rockchip patches thats gets applied on the sunxi kernel. How Has This Been Tested? [X] Compiled an image and booted it on Nanopiduo2 Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [X] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

rockchip64 legacy: fix, rebase, archeology, update .config kernel: wifi driver_uwe5622_allwinner: only ever apply for kernels >= 6.0 case in point, rockchip64-legacy, which is 4.4-something and can't handle this rockchip64 legacy: drop duplicated patch rockchip64 legacy: rebase+archeology all patches against ayufan's refs/tags/4.4.202-1237-rockchip-ayufan rockchip64 legacy: update .config, no changes View the full article

kernel: drop dead code & patches from long-disabled kernel-drivers.sh/drivers_network.sh stuff kernel: drop dead code & patches from long-disabled kernel-drivers.sh/drivers_network.sh stuff this has been dead code (never called) for some 6 months now having it there makes it hard to find the actual/real callpoints of non-dead code View the full article

Description Bump u-boot version to v2022.10 and refreshed the u-boot-sunxi patches wherever needed. I had to remove the add-zeropi.patch as the support already seemed to be there in upstream u-boot. I was not able to check all the supported functionality of zeropi though as I don't have the board myself How Has This Been Tested? [X] Checked that all patches gets applied successfully [X] Tested by booting on nanopiduo2 Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [X] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description CSC target, not tested on hardware View the full article

u-boot espressobin v23.01: fix defconfig patch so it applies u-boot espressobin v23.01: fix defconfig patch so it applies View the full article

docker: use ${SRC} as DOCKER_ARMBIAN_TARGET_PATH instead of hardcoded /armbian docker: use ${SRC} as DOCKER_ARMBIAN_TARGET_PATH instead of hardcoded /armbian this way host-side and Docker-side SRC are now the same path messages containing the path to a file will now match across Docker and actual host View the full article

Patch set includes a complete backport of RTW88 as it currently stands, along with extras. Extra: Patch: RTL8723DS (SDIO) Patch: _rtw_download_firmware() warn: missing unwind goto? Patch: Hack: SDIO RX Aggregation Limiting I only have two units available to me with an 8822CS module and in my testing this is only required on the BPI-CM4IO. With out LIMITING the unit will either kernel panic or not be able to send or receive. This is currently being looked into: https://lore.kernel.org/linux-wireless/CAFBinCBaXtebixKbjkWKW_WXc5k=NdGNaGUjVE8NCPNxOhsb2g@mail.gmail.com/T/#u It may be possible to just set LIMITING across all builds, but that to me seems like a poor choice. This requires TESTING. Jira reference number [AR-9999] Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [X] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description Couple small fixes I found when starting to add support for TI SK boards. Wanted to test the waters with these patches before working to add board support. How Has This Been Tested? Built a couple platforms without issue due to this change. Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article