Jump to content

RSS Bot

Bot
  • Posts

    4244
  • Joined

  • Last visited

    Never

Everything posted by RSS Bot

  1. Description Move disable-debug-rtl8189.patch from kernel to misc(drivers_network.sh), theoretically, all release OS Image dislike these redundant debug information 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] Build completed normally without error messages, And the redundance debug information in the Image dmesg has disappeared 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
  2. Work continues on the Radxa ROCK5B RK388, as PCIe and RTL8125B networking support in U-boot have now been added. Publishing code as Open Source can benefit many different other projects, and allows anyone to benefit. View the full article
  3. Description After this pr https://github.com/armbian/linux-rockchip/pull/25 is merged, we don't need these patches anymore. View the full article
  4. Description This PR contains update to make creation of armbian i3-wm images possible for the following distributions listed by their code names. jammy focal bookworm bullseye Jira reference number AR-1708 How Has This Been Tested? So far I have made sure that the images can be built and that they are bootable and functional. Testing was done on real hardware, bare metal. [X] Test A - able to create the image in the first place without errors present [X] Test B - check if bootable and can be used like a regular i3-wm setup Checklist: Not sure what to mark exactly, so leaving most of these blank for now [] 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 [] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article
  5. Description Jira reference number AR-1443 How Has This Been Tested? [x] Build and boot test image https://paste.armbian.com/cozadamazi Checklist: [x] My code follows the style guidelines of this project [x] My changes generate no new warnings View the full article
  6. export-logs: add GHA output for logs_url (when SHARE_LOG=yes) View the full article
  7. RFC: introduce armbian-base-files artifact, which downloads & repacks base-files from upstream distro This was raised by Igor during upgrade testing. base-files upgrade coming from upstream distro causes many problems during upgrade, including losing the Armbian identity in /etc/os-release and /etc/issue. bsp-cli: now depends on base-files (>= ${REVISION}), this way upgrading the bsp-cli causes our base-files to be installed - bsp-cli no longer does gymnastics with /etc/os-release et al, all done in armbian-base-files now general/apt-utils.sh: introduce apt_find_upstream_package_version_and_download_url() base-files: add release to version, in order to comply with repo restrictions (valid repos can't have two different debs with same name and version, md5 must match) View the full article
  8. rootfs: partially revert f26a41ff, so all repo components (all -utils -desktop) are included in rootfs cache View the full article
  9. Description Just updating kernel configs. View the full article
  10. Updated missing desktop to the armbian-firstlogin script View the full article
  11. Description Panther X2 is a blockchain terminal device:https://shop.panther.global/ I used rock 3c's uboot defconfig and uboot devicetree and it worked fine. I may patch in the future, as the uboot patch is board specific. 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
  12. rpardini's mid-may/`23 pipeline fixes, debs-to-repo, rootfs-repo de-chicken-egg-ize General fixes for GHA/pipelines, produced debs, etc export-logs: add GHA output for logs_url (when SHARE_LOG=yes) github-actions: more logging for GHA actions outputs oci-oras: retry harder, and sleep for more time, if push failed artifacts(debs): include DEBIAN/md5sums and a correct Installed-Size: field in DEBIAN/control (for all debs) artifacts(debs): rationalize "bash hash" creation with new calculate_hash_for_bash_deb_artifact() helper kernel-debs: include "Priority: optional" in all kernel debs (all other packages have it...) also for fake_ubuntu_advantage_tools also include "Section: " missing for advantage artifacts-obtain: deb-tar: don't download .tar again if .debs are in-disk; delete .tar after extracting artifacts: include the artifact maps info (debs/packages) both as keys and values in the artifact JSON info this is valuable for the debs-to-repo process; we can now know which exact .debs are produced, and all the ways we can refer to them docker: remove dead code debs-to-repo and download-artifacts; those are mostly ready, but might need to be made parallel for speedyness. Not required, also not impacting. Works with reprepro for now pipeline: debs-to-repo (v7, working with reprepro) pipeline: artifacts: use better description for artifacts (artifact_name+artifact_version instead of artifact_final_file_basename) artifacts: download-artifact CLI. makes sure to only used local .deb, or download from OCI, never build Remove chicken-egg from rootfs vs repo rootfs/image: introduce new hook custom_apt_repo() (hashed into rootfs version); deploy different repo components/custom repos depending on rootfs or image rationale: we don't want an eternal chicken-egg problem with rootfs vs repo. but, desktop rootfs require some parts of repo. case in point: system-monitoring-center so only add certain components of repo (-desktop, -utils) to rootfs so that is honored introduce custom_apt_repo() hook for extensions to add their repos as well same chicken-egg-avoiding is possible via param CUSTOM_REPO_WHEN View the full article
  13. Description There are many rk3588 boards using u-boot from radxa, and they share the same patch fix_source_so_boot_scr_works.patch. It's better to have just one patch in the repo. So I create one common patch dir legacy/u-boot-radxa-rk3588 for all boards using radxa's u-boot. Since 0001-Add-defconfig-and-dtb-of-nanopi6.patch and add-board-mekotronics-r58.patch won't harm other boards so I also move them to the common dir. If someone want board specfic patches, he can put them to patch/u-boot/legacy/u-boot-radxa-rk3588/board_${BOARD}, just like patch/u-boot/legacy/u-boot-radxa-rk3588/board_hinlink-h88k/uboot-hinlink-h88k-config.patch. 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] rock-5b u-boot [x] hinlink-h88k u-boot [x] mekotronics-r58x u-boot [x] nanopi-r6s u-boot 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
  14. Add possibility of nilfs2 fs based image generation. nilfs2 automatically does snapshots and allow to restore any file to state back in time until it purged. 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: [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
  15. Description We voted to switch before release. Jira reference number AR-1695 How Has This Been Tested? [x] Boot Nanopi M4v2 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
  16. Description We somehow ended with non-bootable image yet again. Jira reference number AR-1692 How Has This Been Tested? Does not work yet, while it boots with defconfig. 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
  17. Description Add support for NanoPi R4SE, which has eMMC for R4S. The dts file mostly come from lede When upgrade to kernel 6.0, it will be much simple since the FriendlyElec already contrib it, armbian should only need this. How Has This Been Tested? I have compiled this patch in userpatches and running on R4SE hardware for a month (kernel upgrades disabled). 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 [ ] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article
  18. Description Current u-boot is a bit unstable, so this bump can't hurt. How Has This Been Tested? [x] Generated image, survived several reboots. Checklist: [x] My changes generate no new warnings View the full article
  19. Description The current kernel.sh build system uses the grab_version() function in utils-compilation.sh to determine the version string of the kernel and locate the build artifacts after make has completed. grab_version is a simple implementation that parses the makefile to guess the final kernel version, but if a userpatch has been applied to the kernel that includes a localversion-xx file (the PREEMPT_RT patch does this, for example), the returned value will be wrong (grab_version returns 5.10.110 when the true value used to name the vmlinuz image is 5.10.110-rt53-rockchip-rk3588) Thank you to @rpardini on Discord for helping me identify a fix for this issue. This patch switches kernel.sh to use the built in make kernelrelease command to return the kernel version, which takes into account any localversion-xx files in the kernel tree, as well as the LOCALVERSION=-${LINUXFAMILY} value appended by the armbian kernel-make.sh code. 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 kernel on current HEAD with localversion-rt file present. Expected result: build failure Packaging fails at kernel_package_callback_linux_image() --> lib/functions/compilation/kernel-debs.sh:213 which is run_host_command_logged ls -la "${kernel_pre_package_path}" "${kernel_image_pre_package_path}" This fails because kernel_image_pre_package_path is derived from grab_version [x] Compile kernel with this patch and no localverison-rt files: vmlinuz filenames are unchanged from current functionality and correctly located by kernel-debs.sh to be built into .deb files. Output from run_host_command_logged ls -la "${kernel_pre_package_path}" "${kernel_image_pre_package_path}": -rw-rw-r-- 1 root root 215715 May 10 19:33 config-5.10.110-rockchip-rk3588 -rw-rw-r-- 1 root root 7779350 May 10 19:33 System.map-5.10.110-rockchip-rk3588 -rw-rw-r-- 1 root root 34013696 May 10 19:33 vmlinuz-5.10.110-rockchip-rk3588 .deb creation is correct: linux-image-legacy-rockchip-rk3588_23.05.0-trunk--5.10.110-Sad1f-D4008-Pbb66-Cc2a1Hfe66-HK01ba-Vc222-B049d_arm64.deb linux-headers-legacy-rockchip-rk3588_23.05.0-trunk--5.10.110-Sad1f-D4008-Pbb66-Cc2a1Hfe66-HK01ba-Vc222-B049d_arm64.deb linux-dtb-legacy-rockchip-rk3588_23.05.0-trunk--5.10.110-Sad1f-D4008-Pbb66-Cc2a1Hfe66-HK01ba-Vc222-B049d_arm64.deb [x] Compile kernel with this patch and localverison-rt files: vmlinuz files are correctly named with both the localversion-xx file and the armbian localversion appended in kernel-make.sh. Output from run_host_command_logged ls -la "${kernel_pre_package_path}" "${kernel_image_pre_package_path}": -rw-rw-r-- 1 root root 210209 May 10 19:48 config-5.10.110-rt53-rockchip-rk3588 -rw-rw-r-- 1 root root 7777472 May 10 19:48 System.map-5.10.110-rt53-rockchip-rk3588 -rw-rw-r-- 1 root root 33714688 May 10 19:48 vmlinuz-5.10.110-rt53-rockchip-rk3588 .debs are created as expected: linux-image-legacy-rockchip-rk3588_23.05.0-trunk--5.10.110-Scbae-D4008-Pbb66-C3f61Hfe66-HK01ba-Vc222-B049d_arm64.deb linux-headers-legacy-rockchip-rk3588_23.05.0-trunk--5.10.110-Scbae-D4008-Pbb66-C3f61Hfe66-HK01ba-Vc222-B049d_arm64.deb linux-dtb-legacy-rockchip-rk3588_23.05.0-trunk--5.10.110-Scbae-D4008-Pbb66-C3f61Hfe66-HK01ba-Vc222-B049d_arm64.deb 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
  20. Description Radxa e 25 now booting 6.3 kernel, no test done yet 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: [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 [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article
  21. After the T-Display-S3 AMOLED board, LILYGO has launched another ESP32-S3 board with an AMOLED display named the T-Track that features a smaller 1.1-inch AMOLED display and a trackball that allows the user to navigate any menu or user interface shown on the display. The rest of the board’s specifications are very similar with an ESP32-S3R8 dual-core chip with 8MB PSRAM providing WiFi and BLE connectivity, a 16MB SPI flash for storage, two rows of pins for up to 18x GPIOs, a Qwicc connector for module expansion, and support for USB-C charging and a LiPo battery for power. T-Track specifications: Wireless MCU – Espressif Systems ESP32-S3R8 dual-core Tensilica LX7 @ up to 240 MHz with vector instructions for AI acceleration, 512KB RAM, 8MB PSRAM, wireless connectivity Storage – 16MB flash Connectivity via ESP32-S3 2.4 GHz 802.11 b/g/n Wi-Fi 4 with 40 MHz bandwidth support Bluetooth Low Energy (BLE) 5.0 connectivity with [...] The post LILYGO T-Track ESP32-S3 board combines 1.1-inch AMOLED display with trackball appeared first on CNX Software - Embedded Systems News. View the full article
  22. Orange Pi 5 Plus is the first Rockchip RK3588 SBC from the company and succeeds the cheaper Rockchip RK3588S-based Orange Pi 5 and Orange Pi 5B single board computers that had a more limited number of high-end interfaces. Switching to the I/O rich RK3588 processor allowed Orange Pi to add two 2.5GbE networking interfaces, support for NVMe SSD storage up to 2,000 MB/s, up to four display interfaces with two HDMI 2.1 ports, MIPI DSI and USB-C with DisplayPort Alt. mode, as well as an extra M.2 socket for optional WiFi 6 and Bluetooth connectivity. Orange Pi 5 Plus specifications: SoC – Rockchip RK3588 CPU – Octa-core processor with 4x Cortex-A76 cores @ up to 2.4 GHz, 4x Cortex-A55 cores @ up to 1.8 GHz Arm Mali-G610 MP4 GPU with support for OpenGL ES1.1/2.0/3.2, OpenCL 2.2, and Vulkan 1.2 6 TOPS AI accelerator with support for INT4/INT8/INT16/FP16 mixed operation VPU [...] The post Orange Pi 5 Plus SBC switches to Rockchip RK3588 SoC, brings dual HDMI 2.1, dual 2.5GbE, M.2 PCIe sockets appeared first on CNX Software - Embedded Systems News. View the full article
  23. Shenzhen Rongpin Electronic Technology (Rongpin) DR4-S905 and DR4-A311D are SO-DIMM system-on-modules (SoM) respectively powered by Amlogic S905D3 quad-core Cortex-A55 processor and Amlogic A311D octa-core Cortex-A73/A53 processor. The modules come with 2GB LPDDR4 and 16GB eMMC flash by default, but can be ordered with up to 4GB RAM and 128GB storage, and the company offered a feature-rich carrier board to test all interfaces provided but the system-on-modules. DR4-S905 system-on-module specifications: SoC – Amlogic S905D3 quad-core Cortex-A55 processor @ 1.9GHz with Arm Mali-G31MP2 GPU up to 800MHz supporting OpenGL ES 3.2, Vulkan 1.0 and OpenCL 2.0, real-time Cortex-M4 core for always-on processing, and 1.2 TOPS NPU System Memory – 2GB LPDDR4 by default (1GB/4GB options) Storage – 16GB eMMC 5.1 flash by default (8GB, 32GB, 64GB, 128GB options) SO-DIMM edge connector for connection to a carrier board Power management – Discrete design Dimensions – 69.6 x 30mm Temperature Range – -25℃ to [...] The post Rongpin DR4-S905/DR4-A311D SoM features Amlogic S905D3 or A311D processor appeared first on CNX Software - Embedded Systems News. View the full article
  24. fixes and squash warnings, mid May/'23: All not-eos artifacts & boards now build OK Board/family fixes for non-building stuff mt7623: remove packages/extras-buildpkgs/mmc-utils/debian/rules install that does not exist anymore (should fix bananapir2) no idea where this went... ❓ rootfs/aggregation/helios64: fix: include PACKAGE_LIST_BOARD_REMOVE (and FAMILY version) into rootfs' artifact_input_variables PACKAGE_LIST_BOARD_REMOVE is used only in helios64 board the fact is PACKAGE_LIST_BOARD_REMOVE removes the packages from the rootfs and not from the image (this is a breaking, unwanted, change in aggregation that happened during armbian_next, that should be fixed later) this only accounts for that fact, but in the future we should actually change how this works Generally curb WARNings that are either unuseful, unneeded, actually-debugging, or just too much for CI/GHA logging/retries: curb CI/GHA warning emitted for each retry binfmts: hide output when loading qemu-arm under aarch64 (some are native, some are emulated, all are good, errors can be ignored) [part 2/2] logging/rockchip64_common: curb warning about BOOT_SOC vs BOOTCONFIG if BOOTCONFIG is empty or 'none' we've enough warnings already logging: curb warning that always came up when SRC_EXTLINUX=yes SRC_EXTLINUX is quite prevalent, no use warning, it was more a debugging marker logging: curb CI/GHA special errors for cascading errors during build failure otherwise we get 4 errors for each "error" in CI one for the real error one for "wait for cleanups" one for "Docker build failed" one from GHA itself since command failed (we can't get rid of this) apt_purge_unneeded_packages_and_clean_apt_caches(): count files, don't use du: avoid WARNs when not needed; tolerate 1 file 'lock' might or not be there, tolerate 1 file (not 0) squash more warnings: odroidxu4's firmware hook for vendor kernel. such is life, no use warning. sun50iw9: vendor kernel with extension, proven working, stop warning - old kernels don't have working headers, it's a fact of life, remove warning View the full article
  25. KOKONI SOTA 3D printer with an inverted design (the printing head is under the hotbed) that supports printing speeds of up to 600mm/s, as well as 7-color printing through a filament tower adding support for 5 extra filament rolls. The upside-down design was made to move motors and rails to the bottom base of the printer to lower the center of gravity and help improve stability, reduce the vibration to virtually nothing, and enable the faster printing speed. KOKONI also says the SOTA 3D printer offers 0.1mm accuracy thanks to AI radar detection and error compensation and operates relatively silently at 30dB one meter from the 3D printer. KOKONI SOTA specifications: Printing size – 200 x 200 x 200 mm XY axis – Linear rail Z-axis SOTA Lite – Lead screw SOTA – High-precision ball screws Drive motor SOTA Lite – high-speed stepper motor SOTA – Closed-loop motor with magnetic [...] The post KOKONI SOTA 3D printer handles 600mm/s prints, 7-color printing (Crowdfunding) appeared first on CNX Software - Embedded Systems News. View the full article
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines