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 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
-
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
-
Description linux-rk3399-legacy.conf is unused. Remove it. How Has This Been Tested? No references to file found in build system, only to linux-rockchip64-legacy.conf, which is for the same kernel. 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
-
https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip-6.3/01-linux-0002-rockchip-from-list.patch#L248-L291 this looks like better alternative for this patch. and this patch has build issue when build mmc and dw_mmc-rockchip as module, no export symbol for mmc_power_off I should use bug report to create an issue to discuss, but I can't open docs.google.com. 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] 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: [ ] 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
-
rockchip64 edge 6.3: move to bare DTs and overlays + fixes rockchip64 edge 6.3: drop add-boards-to-dts-makefile.patch rockchip64 edge 6.3: add 0000.patching_config.yaml for rockchip64 rockchip64 edge 6.3: rebase v6.3.6 + drop DT Makefile patches rockchip64 edge 6.3: drop overlay patches in favor of bare overlays in specific folder rockchip64 edge 6.3: replace DT-symlink patches with bare .dts with #include rockchip64 edge 6.3: drop null-patched DTS files, add them bare in dt/ folder remove double/triple-patching of nanopi-m4v2 (everything is in the bare .dts now) rockchip64 edge 6.3: drop need_checking and disabled patches let git have the history rockchip64 edge 6.3: rename most remaining "add-board" patches to "board" (all "add-board"s are now bare .dts in dt/ folder) keep helios64 as a reminder that it was overwritten once and probably should be dropped, together with other helios64 patches This depends and requires https://github.com/armbian/build/pull/5308 View the full article
-
meson64 edge: bump 6.2 to 6.4 + reworks + use bare DT's and overlays meson64 edge 6.2: rebase v6.2.16, drop Makefile patches, archeology, mbox'ing drop empty doc patch add-board-bananapi-cm4-cm4io.patch meson64 edge 6.2: update .config with no changes meson64 edge 6.4: initial copy (as-is) of 6.2 patches meson64 edge: bump from 6.2 to 6.4 (family file + symlink) meson64 edge 6.4: add 0000.patching_config.yaml for meson64 meson64 edge 6.4: drop patches that landed upstream and backports meson64 edge 6.4: rebase to 6.4-rc5; 7 are failing to apply meson64 edge 6.4: drop patches for boards that landed; change BPICM4 from add to board with pyavitz's fixes meson64 edge 6.4: rework board-bananapim5-sd-use-270-mmc-clock-phase-via-dt.patch meson64 edge 6.4: drop ODROID-N2+'s gpio fan patches, something similar landed upstream meson64 edge 6.4: simple fix for drv-spi-spidev-remove-warnings.patch meson64 edge 6.4: hammer general-gpu-drm-add-new-display-resolution-2560x1440.patch meson64 edge 6.4: drop general-meson-gx-mmc-fix-deferred-probing.patch -- upstreamed https://lore.kernel.org/linux-arm-kernel/16b74882-d65b-93c9-f72b-1d53bfefa22f@omp.ru/T/#t meson64 edge 6.4: rework general-meson-mmc-3-arm64-dts-docs-Update-mmc-meson-gx-documentation-for.patch into YAML meson64 edge 6.4: update .config at 6.4-rc5 enable a bunch of new _MESON and _AMLOGIC stuff meson64 edge 6.4: drop overlay patches in favor of bare overlays in specific folder meson64 edge 6.4: drop null-patched DTS files, add them bare in dt/ folder convert add-board-t95z.patch to board-t95z-add-rc-remote-keymap.patch since that's all that's left -spinor DTS really should be overlays, but keep them as alternate .dtbs for now This depends and requires https://github.com/armbian/build/pull/5308 View the full article
-
patching: Patching Summary and Patching Failures tables using Python's Rich + auto patchers: bare dts, bare overlays, DT Makefile patching: Patching Summary and Patching Failures tables using Python's Rich even Rich'er patch output by colorizing certain strings green/yellow/red BASE_GIT_TAG now very sneakily also accepts a branch name IMPORTANT: this includes: BREAKING CHANGE: patches failing to apply now break the build. fixes #4958 also break on legacy process_patch_file() failure, remove EXIT_PATCHING_ERROR patching: auto patchers: bare dts, bare overlays, DT Makefile View the full article
-
artifact-kernel: log what is the actual ${USERPATCHES_PATH}/kernel/${KERNELPATCHDIR} so people can find it artifact-kernel: log what is the actual ${USERPATCHES_PATH}/kernel/${KERNELPATCHDIR} so people can find it case in point: some families point KERNELPATCHDIR to something like archive/sunxi-5.15 which makes it harder to find than sunxi-legacy View the full article
