RSS Bot
Bot-
Posts
4252 -
Joined
-
Last visited
Never
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Everything posted by RSS Bot
-
Description I was checking this Actions workflow https://github.com/armbian/build/actions/runs/8309150018/job/22740183634 and noticed [!] ERROR: failed to detect microarchitecture Reason: RISC-V is not yet supported by kernel-hardening-checker. See https://github.com/a13xp0p0v/kernel-hardening-checker/issues/56 In their README: Supported microarchitectures X86_64 X86_32 ARM64 ARM TODO: RISC-V (issue https://github.com/a13xp0p0v/kernel-hardening-checker/issues/56) How Has This Been Tested? Ran manual in CLI: file=config/kernel/linux-uefi-risc64-edge.config and then if [[ "${file}" = config/kernel/*.config && ! "${file}" =~ riscv ]]; then echo yes; fi Don't know how to run the whole workflow manually quickly, and on a specific file. 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 View the full article
-
Description This PR tries to improve the GitHub bug report template for the build framework: Don't have pre-placed text in text boxes which have to be deleted each time (placeholder/light grey background text is still there) Add latest host systems Add optional checkbox if building on WSL2 Small wording improvements/changes How Has This Been Tested? [x] View the result (preview) in my forked repo Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] My changes generate no new warnings View the full article
-
Description Bump mainline from 6.8-rc7 to 6.8 stable This currently affects only rk3588-edge Bump UEFI-edge from 6.7 to 6.8 [DOES NOT COMPILE YET!!!] Kernel configs updated via ./compile.sh rewrite-kernel-config Kernel patches updated via ./compile.sh rewrite-kernel-patches The uefi-edge kernel does not compile without errors yet, because of drivers/net/wireless/rtl8192eu and the likes. Some patches need to be added or adapted for 6.8 in patch/misc, but I honestly don't know where to get these patches from. I could not find folders like /drivers/net/wireless/rtl8192eu/os_dep/ in the mainline kernel. Help is appreciated! ❤️ Build log for BOARD=uefi-arm64 BRANCH=edge: https://paste.armbian.com/ejevafisid How Has This Been Tested? [x] 1) Tested with ./compile.sh build BOARD=nanopi-r6s BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=no BUILD_ONLY="kernel" KERNEL_CONFIGURE=no RELEASE=bookworm --> build success [ ] 2) Build ./compile.sh build BOARD=uefi-arm64 BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=no BUILD_ONLY="kernel" KERNEL_CONFIGURE=no RELEASE=bookworm FAILED Checklist: [x] My code follows the style guidelines of this project [ ] My changes generate no new warnings View the full article
-
desktop: jammy: kde-neon: more basic packages needed desktop: jammy: kde-neon: more basic packages needed add network-manager & pulseaudio settings add discover, otherwise there is a broken icon on the dock add vault/scdaemon for gpg wallet enable debugs in create_desktop_package.sh; disable old postinst pa hack View the full article
-
Description Converted to markdown and bash simulating nasting array.Proof of consept Jira reference number [AR-9999] Documentation summary for feature / change Please delete this section if entry to main documentation is not needed. If documentation entry is predicted, please provide key elements for further implementation into main documentation and set label to "Needs Documentation". You are welcome to open a PR to documentation or you can leave following information for technical writer: [x] A simple converter complexly [x] Will Turn your Json to a Bash simulated array and provide a table of features. [x] ./build/doc/doc.sh How Has This Been Tested? [x] (https://github.com/armbian/build/pull/5734 [x] (https://github.com/armbian/build/pull/5894 Checklist: Please delete options that are not relevant. [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 View the full article
-
Description As discussed here on the forums this overlay adds support for the RTL8211f chip found on Rockpi E Hardware revision 1.21 Documentation summary for feature / change Documentation updated, hope that's enough and appropriate. How Has This Been Tested? Running that overlay currently on four Rockpi S instances connected to the 1 Gbit/s port Checklist: [X] I have performed a self-review of my own code [X] My changes generate no new warnings View the full article
-
Description This is a follow-up on this PR https://github.com/armbian/build/pull/6376 and this comment https://github.com/armbian/build/pull/6376#issuecomment-1987147291 It's more of an idea, since I tried rewrite-uboot-patches and noticed the following: Board NanoPi-R6S has 5 U-Boot patches in total (legacy/u-boot-raxda-rk3588). Using ./compile.sh BOARD=nanopi-r6s BRANCH=edge rewrite-uboot-patches has the following patch summary: Summary: u-boot patching: 5 total patches; 5 applied; 2 with problems; 2 needs_rebase However, instead of only rewriting/rebasing the 2 patches, it modifies all 5 patches slightly (see example below). This means your git working tree quickly gets cluttered with these modified-without-any-real-changes patch files. And you'll have to either figure out which patches were changed/rebased if you only want to commit those, or commit all and make it harder to see the actual changes (I think?). Example of a patch file getting modified even if the patch stays the same: (Notice the lines/hunks did not get changed, only the metadata) git diff patch/u-boot/legacy/u-boot-radxa-rk3588/0001-Add-defconfig-and-dtb-of-nanopi6.patch | cat diff --git a/patch/u-boot/legacy/u-boot-radxa-rk3588/0001-Add-defconfig-and-dtb-of-nanopi6.patch b/patch/u-boot/legacy/u-boot-radxa-rk3588/0001-Add-defconfig-and-dtb-of-nanopi6.patch index 38f1a5a..b8e16cd 100644 --- a/patch/u-boot/legacy/u-boot-radxa-rk3588/0001-Add-defconfig-and-dtb-of-nanopi6.patch +++ b/patch/u-boot/legacy/u-boot-radxa-rk3588/0001-Add-defconfig-and-dtb-of-nanopi6.patch @@ -1,18 +1,16 @@ -From 70d65e65db965295ddd23d5db752aad1c035c205 Mon Sep 17 00:00:00 2001 +From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Muhammed=20Efe=20=C3=87etin?= <efectn@protonmail.com> Date: Sat, 15 Apr 2023 23:12:17 +0300 -Subject: [PATCH] Add defconfig and dtb of nanopi6 +Subject: Add defconfig and dtb of nanopi6 --- - arch/arm/dts/rk3588s-nanopi-r6s.dts | 126 ++++++++++++++++ - configs/nanopi-r6s-rk3588s_defconfig | 217 +++++++++++++++++++++++++++ + arch/arm/dts/rk3588s-nanopi-r6s.dts | 126 ++++++ + configs/nanopi-r6s-rk3588s_defconfig | 217 ++++++++++ 2 files changed, 343 insertions(+) - create mode 100644 arch/arm/dts/rk3588s-nanopi-r6s.dts - create mode 100644 configs/nanopi-r6s-rk3588s_defconfig diff --git a/arch/arm/dts/rk3588s-nanopi-r6s.dts b/arch/arm/dts/rk3588s-nanopi-r6s.dts new file mode 100644 -index 0000000000..4899e23fa3 +index 000000000000..4899e23fa3aa --- /dev/null +++ b/arch/arm/dts/rk3588s-nanopi-r6s.dts @@ -0,0 +1,126 @@ @@ -144,7 +142,7 @@ index 0000000000..4899e23fa3 +}; diff --git a/configs/nanopi-r6s-rk3588s_defconfig b/configs/nanopi-r6s-rk3588s_defconfig new file mode 100644 -index 0000000000..19bae55629 +index 000000000000..19bae5562928 --- /dev/null +++ b/configs/nanopi-r6s-rk3588s_defconfig @@ -0,0 +1,217 @@ @@ -366,5 +364,5 @@ index 0000000000..19bae55629 +CONFIG_OPTEE_V2=y +CONFIG_OPTEE_ALWAYS_USE_SECURITY_PARTITION=y -- -2.39.2 +Armbian How I tried to solve this The information if a patch needs rebasing is already there, so I tried to solve this by introducing a new option REWRITE_PATCHES_NEEDING_REBASE in addition to the existing REWRITE_PATCHES. Why an additional option? I didn't want to break anything (took me some hours already to figure out where the actual patch rewriting happes and to understand their logic, so I'm not confident to change what REWRITE_PATCHES does on its own 😅) Maybe there will be some reason when you want to actually rewrite all patches even if they don't need rebasing? If it's not an issue, I could also just remove the additional option REWRITE_PATCHES_NEEDING_REBASE and instead make this the default behaviour for REWRITE_PATCHES. How Has This Been Tested? [x] Run the same command as earlier: ./compile.sh BOARD=nanopi-r6s BRANCH=edge rewrite-uboot-patches and only the 2 patches that needed rebasing were modified [x] Compiled a board image to check if nothing got broken: ./compile.sh build BOARD=nanopi-r5c BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=no KERNEL_CONFIGURE=no RELEASE=bookworm 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
-
The latest Linux Kernel 6.8 release brings thousands of new lines of code, improving the core kernel, architecture support, networking, file systems, and more. 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-9999] Documentation summary for feature / change Please delete this section if entry to main documentation is not needed. If documentation entry is predicted, please provide key elements for further implementation into main documentation and set label to "Needs Documentation". You are welcome to open a PR to documentation or you can leave following information for technical writer: [ ] short description (copy / paste of PR title) [ ] summary (description relevant for end users) [ ] example of usage (how to see this in function) How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [ ] Test A [ ] Test B Checklist: Please delete options that are not relevant. [ ] 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 [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article
-
Description As per title. Jira reference number AR-2103 How Has This Been Tested? [x] Manual build 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 This is a sample JSON file that can be used to track features and well as their documentation. This will help bridge information between the developers and the technical writers and help maintain up-to-date documentation. View the full article
-
Description In order to fullfil the Jira task AR-1988 (Resolve Rockchip patch maintenance nightmare), remove rockpis family in favor of rockchip64 and merge the configuration bits from the family .conf file into the board rockpi-s.conf file. Also removes the legacy patches from the archive Jira reference number AR-1988 How Has This Been Tested? [x] A current kernel image has been produced [x] idbloader has been verified to be matching against the pre-cleanup image [x] /boot/armbianEnv.txt contains the overlay_prefix=rk3308 [x] /boot/boot.cmd matches config/bootscripts/boot-rockpis.cmd [ ] /boot/armbianEnv.txt contains /config/bootenv/rockpi-s.txt Please @brentr check that produced images also boots; I tried to check that all the bits are in the right place, but can't do the ultimate test, thanks! 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
-
Update maintainers and board status synced status from the database rename to .csc where we don't have anyone If you want to become a board maintainer, adjust data here. Ref: Board Maintainers Procedures and Guidelines View the full article
-
Description When trying to build an image with FIXED_IMAGE_SIZE=3000 ROOTFS_TYPE=f2fs with WSL2 as build host, I stumbled on an error pretty late in the build process when trying to mount the rootfs: [💲|🌿] Creating rootfs [ f2fs on /dev/loop2p2 ] [💲|🔨] [💲|🔨] F2FS-tools: mkfs.f2fs Ver: 1.14.0 (2020-08-24) [💲|🔨] [💲|🔨] Info: Disable heap-based policy [💲|🔨] Info: Debug level = 0 [💲|🔨] Info: Label = armbi_root [💲|🔨] Info: Trim is enabled [💲|🔨] Info: Segments per section = 1 [💲|🔨] Info: Sections per zone = 1 [💲|🔨] Info: sector size = 512 [💲|🔨] Info: total sectors = 5586911 (2727 MB) [💲|🔨] Info: zone aligned segment0 blkaddr: 512 [💲|🔨] Info: format version with [💲|🔨] "Linux version 6.1.21.2-microsoft-standard-WSL2+ (flash@DESKTOP-2VA4T55) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 SMP Wed Jan 31 20:29:07 CET 2024" [💲|🔨] Info: [/dev/loop2p2] Discarding device [💲|🔨] Info: This device doesn't support BLKSECDISCARD [💲|🔨] Info: Discarded 2727 MB [💲|🔨] Info: Overprovision ratio = 3.860% [💲|🔨] Info: Overprovision segments = 108 (GC reserved = 59) [💲|🔨] Info: format successful [💲|🌿] Mounting rootfs [ /dev/loop2p2 (UUID=02dfb13e-172d-44b1-b71c-25164f29cc0b) ] [💲|🔨] mount: /home/user/build-fork/.tmp/mount-bfedd4e1-02f1-4bac-99c1-88d420d40809: unknown filesystem type 'f2fs'. [💲|💥] Error 32 occurred in main shell [ at /home/flash/build-fork/lib/functions/logging/runners.sh:211 run_host_command_logged_raw() --> lib/functions/logging/runners.sh:211 run_host_command_logged() --> lib/functions/logging/runners.sh:193 prepare_partitions() --> lib/functions/image/partitioning.sh:275 do_with_logging() --> lib/functions/logging/section-logging.sh:81 build_rootfs_and_image() --> lib/functions/main/rootfs-image.sh:86 full_build_packages_rootfs_and_image() --> lib/functions/main/default-build.sh:36 do_with_default_build() --> lib/functions/main/default-build.sh:42 cli_standard_build_run() --> lib/functions/cli/cli-build.sh:25 armbian_cli_run_command() --> lib/functions/cli/utils-cli.sh:136 cli_entrypoint() --> lib/functions/cli/entrypoint.sh:176 main() --> compile.sh:50 ] [💲|💥] Cleaning up [ please wait for cleanups to finish ] I found out that this is because the WSL2 kernel does not have support for the F2FS filesystem. f2fs-tools could be installed normally though. To make the build script exit at the beginning instead of at a late stage and to tell the user a more exact reason why it failed, I added a check if the chosen ROOTFS_TYPE is supported by the host the build script is running on. The check checks /proc/filesystems which should be present in all Linux distros. But just in case /proc/filesystems is not present, the build won't fail and instead print a warning that the build might fail just like if it can't install python2. How Has This Been Tested? Build host: Linux version 6.1.21.2-microsoft-standard-WSL2+ (no F2FS support, but BTRFS and EXT4 support) Command: ./compile.sh build BOARD=nanopi-r5c BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=no KERNEL_CONFIGURE=no RELEASE=bookworm FIXED_IMAGE_SIZE=3000 ROOTFS_TYPE=f2fs [x] Ran build with FIXED_IMAGE_SIZE=3000 ROOTFS_TYPE=f2fs --> build exits at an early stage with [💲|💥] error! [ Filesystem type unsupported by build host: f2fs ] [x] Ran build with ROOTFS_TYPE=btrfs --> build success [x] Ran build without ROOTFS_TYPE option --> build success Might need some testing with other more exotic build hosts like Docker. 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 View the full article
-
rk35xx/rockchip-rk3588: vendor: switch to armbian/linux-rockchip#rk-6.1-rkr1 rk35xx/rockchip-rk3588: vendor: switch to armbian/linux-rockchip#rk-6.1-rkr1 since https://github.com/armbian/linux-rockchip/pull/155 khadas-edge2: remove vendor branch, we've no kedge2 DT/patches for it yet View the full article
-
Description make common section similar to CLI remove deprecated remove 3rd party repository from 3d section remove / replace Codium with Code Jira reference number AR-2101 How Has This Been Tested? [ ] Manual builds 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 Enable rk3528 soc support to make rk3528 boards bootable. Enable lima gpu driver for mali 400/450 gpu on rk3528 and disable arm mali400/450 driver. Devicetree related change is already in https://github.com/amazingfate/linux-rockchip/commit/419410ff56c8e80b37e100c265d57f23cc0db835 How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] ./compile.sh kernel BOARD=hinlink-ht2 BRANCH=vendor DEB_COMPRESS=xz KERNEL_CONFIGURE=no [x] Lima gpu driver works on hinlink-ht2 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
-
Description Mainline kernel linux-6.7.y has broken dsi panel since 6.7.6, so we use back v6.7.5 avoid it. Other sm8250 device xiaomi 10 doesn't support panel in kernel so it should be fine. Use typec pd patch from lujianhua and now the typec port can auto switch to host mode when usb deivices are plugged in. How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] ./compile.sh kernel BOARD=xiaomi-elish BRANCH=sm8250 DEB_COMPRESS=xz KERNEL_GIT=shallow DEB_COMPRESS=xz [x] Xiaomi pad5 pro works fine. 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
-
Description Add the patching config file for rk35xx-vendor to easily patch in dts files by putting them in the dt folder. How Has This Been Tested? [x] Put new dts files in patch/kernel/rk3588-vendor/dt and successfully ran ./compile.sh build BOARD=nanopc-cm3588-nas BRANCH=vendor BUILD_DESKTOP=no BUILD_MINIMAL=no KERNEL_CONFIGURE=no RELEASE=bookworm. New patches were applied. 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 Initial commit of most recent KDE desktop v6.x Jira reference number AR-2100 How Has This Been Tested? [x] Generated x86 and arm64 image (Odroid N2) 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 [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article
-
u-boot: rewrite/rebase u-boot patches for a few boards; bump odroidm1 and orangepi3b u-boot: rewrite/rebase u-boot patches for a few boards; drop long-forgotten old version patches; no actual changes I guess this is most of the u-boot's I've touched over the years; notable exception is the orangepi3b (patches live in Kwiboo's tree) this is in preparation for bumping versions, hopefully soon radxa-zero, radxa-zero2, khadas-vim3, khadas-vim3l: drop patches for old u-boot versions no longer used odroidm1: bump u-boot to v2024.04-rc3 odroidm1: copy patches from v2023.10 odroidm1: rebase u-boot patches against v2024.04-rc3 odroidm1: drop v2023.10 u-boot patches orangepi3b: bump u-boot to Kwiboo's rk3xxx-2024.04 Add exact commit in a comment if it ever breaks Kwiboo's tree contains the OPi3B commits, not yet in upstream; I tried to rebase onto upstream v2024.04-rc3, but failed with "unmet direct dependencies detected for SPL_OF_LIBFDT" & SPL_LIBGENERIC_SUPPORT View the full article
-
cli: introduce rewrite-uboot-patches cli command, works similar to the kernel one cli: introduce rewrite-uboot-patches cli command, works similar to the kernel one it prepares git, applies patches to git, and re-writes them back from git same as kernel, it does git archeology for mbox-less patches, etc uboot-patches-to-git alias is also added, but my guess is rewrite is more useful refactor a common config function for both kernel and uboot example invocation: ./compile.sh BOARD=xxxx BRANCH=edge rewrite-uboot-patches View the full article
