RSS Bot
Bot-
Posts
4244 -
Joined
-
Last visited
Never
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Everything posted by RSS Bot
-
Description Maintenance job. We provide options to build several desktop combinations, but we don't have a mechanism for verifying if those targets still work. I developed a simple action script that cycles all variants that are either supported or community supported. Community supported will only check for deboostrap success. This commit is a result of reading build logs of that Action script. Kde-Neon is in EOS zone as it doesn't build anywhere (atm). AR-2358 How Has This Been Tested? [x] Targets were tested for (x86 qemu which will be further tested on VM once CI extents to this functionality) image compiling. 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 [x] Any dependent changes have been merged and published in downstream modules View the full article
-
Description Due to crypto policy update, apt now (since v2.7.13, see the commit) requires repositories to be signed using one of the following public key algorithms: RSA with at least 2048-bit keys Ed25519 Ed448 Affected: Ubuntu Oracular when adding Mesa PPA. More info https://ubuntuhandbook.org/index.php/2024/04/workaround-apt-warning-signature-key-uses-weak-algorithm/ Jira reference number AR-2359 How Has This Been Tested? [x] https://github.com/armbian/os/actions/runs/9434613892 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 [x] Any dependent changes have been merged and published in downstream modules View the full article
-
Description Per Igor comment helios64 required work to sync with upstream changes. I took the liberty to keep more of upstream than in Armbian 6.8, namely: I kept nodes at their upstream location to remove unnecessary work when syncing to the upstream keep "ethernet0 = &gmac;" in aliases, to let the ethernet MAC retrieved from OTP in u-boot apply. This will restore this feature (the u-boot was still functional). U-boot retried ethernet MACs are in u-boot printenv output "ethaddr" and "eth1addr". Seems for a few years I had the Linux kernel autogenerated one but my config still had the correct one commented (I did not find why it broke back then). I removed the overclock disabling code as the overclock is not included in the dts so no need to disable it (will lower the sync to upstream burden) kept upstream fix 93b36e1d3748c352a70c69aa378715e6572e51d1 "arm64: dts: rockchip: Fix USB interface compatible string on kobol-helios64" from upstream in vcc3v0_sd node I kept "enable-active-high;" and "gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;" sync to upstream from helios64::status to helios64:green:status for system_leds : status_led kept startup-delay-us = <2000000> on hdd nodes from upstream (I believe they should not be the same value for rail a and b of the HDD, one should do as in the helios64 u-boot code where one is started after the other to lower the current load) I also did not sync with upstream the differences of gpio pull config for "power > sdmmc0_pwr_h" and "pinctrl > pmic > pmic_int_l" I kept the upstream DTS model "Kobol Helios64" instead of the armbian "Helios64". Ethernet rename from armbian-hardware-optimization works. Documentation summary for feature / change [ ] short restore ethernet MACs for eth0 read from OTP via u-boot [ ] This will restore the original intent which is to have the eth0 mAC be defined from the mainboard. This might affect MAC-based DHCP definitions [ ] ip l to get the Linux-defined eth0/end0 MAC, printenv in u-boot to see ethaddr and eth1addr for eth0/end0 and eth1 How Has This Been Tested? [ ] Compile, installed, and reboot, checked assigned IP was from the dnsmasq dhcp-host definition for this ethernet MAC. Did a few other reboots. 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 On every PR, a workflow is started to check if artifacts should be built. This happens not only once, but many times, e.g. for every selected reviewer. Since the workflow has cancel-in-progress enabled, workflows are started and immediately cancelled by the next one, resulting in many notifications (see https://github.com/armbian/build/actions/workflows/build-artifacts-pr.yml how many of the workflows were duplicates which were cancelled). Move the cancel-in-progress concurrency policy to the second job which starts only after a check is done if the 'Build' label is even active on the PR. This should greatly reduce "Workflow cancelled" notifications via GitHub and email (if enabled by the user). Documentation that concurrency can also be used on jobs: https://docs.github.com/en/actions/using-jobs/using-concurrency#example-using-concurrency-and-the-default-behavior Also don't start the workflow on PR 'reviewer_requested' trigger. It does not need to be started every time a single reviewer is added, since requesting a review does not change the build. If the 'Build' label was already added earlier, the build workflow will have been started already. In addition, don't run shellcheck if a PR message ot title was edited since it does not change the code at all. See doc: https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=edited#pull_request How it has been tested [x] Check started workflow this PR: https://github.com/armbian/build/actions/workflows/build-artifacts-pr.yml Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code View the full article
-
Description The "swapaccount=" option has been deprecated in 6.1. Disable it in almost all boot scripts except "boot-sun50iw9.cmd" since that one is used in sun50iw9 legacy kernel, which is version 4.9. In theory, rk3588-legacy is also still <6.1, but that boot script is also used by 6.1 vendor kernel and the amount of new images being built/used with the 5.10 legacy kernel is likely minimal. As far as I know, bootscript won't update automatically, so these changes will only apply to freshly built images. Please correct me if I'm wrong. Link to kernel commit: https://github.com/torvalds/linux/commit/b25806dcd3d5248833f7d2544ee29a701735159f Closes issue https://github.com/armbian/build/issues/6633 Also, there are other kernel parameters, e.g.: cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory https://github.com/armbian/build/blob/d7db1cd26b926bff2b19193f6de30dbc1910aa20/config/bootscripts/boot-rockchip64.cmd#L42 I couln't find out why cgroup_enable= is added here. The official kernel parameters doc (https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt) only lists a cgroup_disable= option. Maybe this is some relic of the past? Does anyone know?` Is there a way to find out on a live kernel what the boot arguments actually did? Jira reference number AR-2321 View the full article
-
Description In an effort to reduce wifi driver burdens AR-1745, I went through the 6.10 kernel to check if any third party wifi drivers can be removed. The following drivers are part of the mainline kernel as of 6.10: RTL8723CS (driver: RTW88) RTL8811CU and RTL8821C (driver: RTW88) RTL8192EU (driver: RTL8XXXU) To give them some more time in the oven, use them not from 6.10 but from 6.11 onwards. I went through the Armbian forums, Atlassian and GiHub issues to see if anyone had used those drivers for these chips in the past and had reported issues. But I haven't found anything yet. RTL8723DS is also supported by RTW88, but I have not touched that driver since it is still required for the RockPi-S wifi to work properly as reported by @brentr Jira reference number AR-1745 How Has This Been Tested? [x] Build success: ./compile.sh BOARD=nanopc-cm3588-nas BRANCH=edge RELEASE=trixie EXPERT=yes KERNEL_CONFIGURE=no BUILD_MINIMAL=no BUILD_DESKTOP=no [ ] Mainline drivers should be tested LOOKING FOR TESTERS: Drivers for RTL8811CU, RTL8821C and RTL8192EU are available also in 6.9, so if you have a device with those chips, it would be very nice if you could test them with their respective kernel driver (RTW88 or RTL8XXXU). You may have to enable them in your board's kernel config. If you have a board with a RTL8723DS chip, please test the RTW88 driver. If RockPi-S is the only board which broken RTL8723DS driver, we could switch most other boards to RTW88 for this chip. 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 [x] Any dependent changes have been merged and published in downstream modules View the full article
-
The final installment of a series explaining how Collabora is helping shape the video virtualization story for Chromebooks with a focus on the future plans for cros-libva and cros-codecs. View the full article
-
Description Allow to use Docker credentials for oras-cli push artifacts when CI=true is set, but not in GitHub action. TODO: fix GITHUB_OUTPUT use if CI=true is set. Jira reference number AR-2357 How Has This Been Tested? [X] correct push to external container registry with CI=true 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 Ubuntu noble ships qbootctl with a bug which makes qbootctl service can't start: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057918. I fixed it in my ppa liujianfeng1994/qcom-mainline. I use a silly dd method to create rootfs. It's better to use losetup to load the built image and copy rootfs from the mounted loop device. Note: ubuntu noble also ships mkbootimg with bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050300, which will make this extension not working. So it's better not using noble as build environment. Debian's fix is still not packaged: https://salsa.debian.org/android-tools-team/android-platform-tools/-/commit/d26c3b5ac89efd92eb96ad029cd06400c1c9f015 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 BOARD=xiaomi-elish BRANCH=current BUILD_DESKTOP=yes BUILD_MINIMAL=no DEB_COMPRESS=xz DESKTOP_APPGROUPS_SELECTED= DESKTOP_ENVIRONMENT=gnome DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base KERNEL_CONFIGURE=no KERNEL_GIT=shallow RELEASE=noble 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 [ ] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article
-
Description The general improvements for RK3588 on 6.9 and 6.10 weren't as many as we've hoped, but still this is what was mainlined: USB3 DRD support, including PHY usbdp HDMI PHY GPU We already had most of those features patched in via patches, but this gives us the chance to finally be able to remove those and stay closer to mainline. -> PR summary: (+5,895 - 28,098) ~= 22,000 lines less 👍 (meaning less hassles in the future, less maintenance needed) In addition to that, I have also updated our patch to support RK3588 thermal sensors and management, enabling and improving the use of cooling fans. This patch also includes updates for CpuFreq and OPP. We had an old patch that patched in the HDMI Controller driver, but this patch does not build on 6.10. Fortunately, I was able to include a new, improved version for this driver, which is as recent as 1st of June. Since out "general-add-overlay-compilation-support.patch" became obsolete in Linux 6.9 (see AR-2352) , @paolosabatino developed an improved way on adding overlays as first seen in https://github.com/armbian/build/pull/6690. I have adapted this patch for 6.10, which also paves the way for other kernel bumps to 6.10 in the future. In addition to that, there are some fixes included for Orange Pi 5 and Khadas Edge 2 patches, which were failing on 6.10. Please see the commit messages for details. How Has This Been Tested? [x] Compile success: ./compile.sh BOARD=nanopc-cm3588-nas BRANCH=edge RELEASE=trixie EXPERT=yes KERNEL_CONFIGURE=no BUILD_MINIMAL=no BUILD_DESKTOP=no [ ] HDMI is untested [ ] More general testing is needed 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
-
it is alone in 6.8 dir :) View the full article
-
u-boot-radxa-rk3588/legacy: use 000.patching_config; fix boot from SD when combined with from-factory eMMC blobs (TEE mismatch) u-boot-radxa-rk3588/legacy: rewrite u-boot patches, no changes u-boot-radxa-rk3588/legacy: add 0000.patching_config.yaml and move all null-patches into dt and defconfig dirs as bare files DTs and defconfigs should be identical to their null-patch equivalents u-boot-radxa-rk3588/legacy: rewrite nanopc_t6_defconfig -- no changes CONFIG_REGULATOR_RK806=y seems a leftover that's not really used? u-boot-radxa-rk3588/legacy: rewrite nanopc_cm3588_defconfig -- no changes CONFIG_REGULATOR_RK806=y seems a leftover that's not really used? u-boot-radxa-rk3588/legacy: nanopc_cm3588_defconfig: disable OPTEE (for OOB working boot with from-factory blobs in eMMC) makes it compatible with vendor out-of-box blobs (which include TEE) in the from-factory eMMC Armbian itself doesn't ship TEE blobs when combining from-factory eMMC blobs with an Armbian SD card, TEE blobs are in practice found by u-boot but then proceeds to fail with optee api revision is too low disable OPTEE in defconfig fixes it, TEE isn't used in any way by Armbian u-boot-radxa-rk3588/legacy: nanopc_t6_defconfig: disable OPTEE (for OOB working boot with from-factory blobs in eMMC) makes it compatible with vendor out-of-box blobs (which include TEE) in the from-factory eMMC Armbian itself doesn't ship TEE blobs when combining from-factory eMMC blobs with an Armbian SD card, TEE blobs are in practice found by u-boot but then proceeds to fail with optee api revision is too low disable OPTEE in defconfig fixes it, TEE isn't used in any way by Armbian View the full article
-
Last week I attended the GStreamer spring hackfest in Thessaloniki to work on the PipeWire GStreamer elements and connect with the community. View the full article
-
Description New codec and hub code for HDMI and analog sound on Allwinner H616 and H618 SOCs, including all the bits and pieces to implement the code (dts and configs). How Has This Been Tested? The patch was implemented on a recent fork of armbian build main. two images were built, Debian bookworm server from edge and Debian bookwork desktop xfce from current. Server testing: Analog audio was unmuted using alsamixer by unmuting Left out DACL and Right out DACR. Mpg123 was installed and used to play an mp3 file. Aplay speaker-test was also used to check left and right audio. Playing the mpg file and the speaker-test were also performed from an HDMI monitor connection. root@orangepizero3:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: audiocodec [audiocodec], device 0: CDC PCM Codec-0 [CDC PCM Codec-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: HDMI [HDMI], device 0: ahub_plat-i2s-hifi i2s-hifi-0 [ahub_plat-i2s-hifi i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 root@orangepizero3:~# aplay -L null Discard all samples (playback) or generate zero samples (capture) hw:CARD=audiocodec,DEV=0 audiocodec, CDC PCM Codec-0 Direct hardware device without any conversions plughw:CARD=audiocodec,DEV=0 audiocodec, CDC PCM Codec-0 Hardware device with all software conversions default:CARD=audiocodec audiocodec, CDC PCM Codec-0 Default Audio Device sysdefault:CARD=audiocodec audiocodec, CDC PCM Codec-0 Default Audio Device dmix:CARD=audiocodec,DEV=0 audiocodec, CDC PCM Codec-0 Direct sample mixing device hw:CARD=HDMI,DEV=0 HDMI, ahub_plat-i2s-hifi i2s-hifi-0 Direct hardware device without any conversions plughw:CARD=HDMI,DEV=0 HDMI, ahub_plat-i2s-hifi i2s-hifi-0 Hardware device with all software conversions default:CARD=HDMI HDMI, ahub_plat-i2s-hifi i2s-hifi-0 Default Audio Device sysdefault:CARD=HDMI HDMI, ahub_plat-i2s-hifi i2s-hifi-0 Default Audio Device dmix:CARD=HDMI,DEV=0 HDMI, ahub_plat-i2s-hifi i2s-hifi-0 Direct sample mixing device root@orangepizero3:~# ANALOG tests: sysadmin@orangepizero3:~$ mpg123 Scarborough\ Fair.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3 version 1.31.2; written and copyright by Michael Hipp and others free software (LGPL) without any warranty but with best wishes Terminal control enabled, press 'h' for listing of keys and functions. Playing MPEG stream 1 of 1: Scarborough Fair.mp3 ... MPEG 1.0 L III cbr96 44100 j-s Title: Scarborough Fair/canticle Artist: Paul Simon Comment: Album: Art Garfunkel / The Graduate - Year: 1968 Genre: Soundtrack sysadmin@orangepizero3:~$ speaker-test -t wav -c 2 speaker-test 1.2.8 Playback device is default Stream parameters are 48000Hz, S16_LE, 2 channels WAV file(s) Rate set to 48000Hz (requested 48000Hz) Buffer size range from 32 to 131072 Period size range from 16 to 65536 Using max buffer size 131072 Periods = 4 was set period_size = 32768 was set buffer_size = 131072 0 - Front Left 1 - Front Right Time per period = 0.737457 0 - Front Left 1 - Front Right Time per period = 2.737752 0 - Front Left 1 - Front Right HDMI tests: sysadmin@orangepizero3:~$ mpg123 -a hw:1,0 Scarborough\ Fair.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3 version 1.31.2; written and copyright by Michael Hipp and others free software (LGPL) without any warranty but with best wishes Terminal control enabled, press 'h' for listing of keys and functions. Playing MPEG stream 1 of 1: Scarborough Fair.mp3 ... MPEG 1.0 L III cbr96 44100 j-s Title: Scarborough Fair/canticle Artist: Paul Simon Comment: Album: Art Garfunkel / The Graduate - Year: 1968 Genre: Soundtrack [src/libout123/libout123.c:out123_play():700] error: Error in writing audio, wrote only 3824 of 4608 (Success?)! [0:14] Decoding of Scarborough Fair.mp3 finished. sysadmin@orangepizero3:~$ speaker-test -D hw:1,0 -t wav -c 2 speaker-test 1.2.8 Playback device is hw:1,0 Stream parameters are 48000Hz, S16_LE, 2 channels WAV file(s) Rate set to 48000Hz (requested 48000Hz) Buffer size range from 32 to 131072 Period size range from 16 to 65536 Using max buffer size 131072 Periods = 4 was set period_size = 32768 was set buffer_size = 131072 0 - Front Left 1 - Front Right Time per period = 0.729233 0 - Front Left 1 - Front Right Time per period = 2.737477 0 - Front Left 1 - Front Right ^CTransfer failed: Bad address sysadmin@orangepizero3:~$ Results: all tests worked as expected. Desktop testing: The server tests were performed from a terminal window on the desktop image. In addition a music video with audio was played on chromium youtube. An mp3 music file was played with the Celluloid app. The tests were done on both analog and HDMI, using pulseaudio to switch between outputs. All tests performed as expected. There was an anomaly observed when using the pulseaudio volume control on the analog output. When pulse audio volume control was selected, the analog audio started to play at high speed. This did not happen on HDMI output. The issue can be worked around by using pulseausio volume control configure tab to turn off HDMI when using the analog output. This patch, a repository with the patch and a few images were posted to the Allwinner sunxi community forum from where a number of members reported successful tests. https://forum.armbian.com/topic/37718-sound-on-h616h618-socs/ Checklist: [ x ] My changes generate no new warnings [ x] Any dependent changes have been merged and published in downstream modules View the full article
-
Checklist: [x] I have performed a self-review of my own code View the full article
-
Description Fix the typo in config file concerning dtb How Has This Been Tested? build/boot tested Checklist: Please delete options that are not relevant. [x] I have performed a self-review of my own code [x] My changes generate no new warnings View the full article
-
Description Bump rockchip64 edge kernel to 6.9. The same fix that has been proposed in https://github.com/armbian/build/pull/6690 has been ported here too and it works as well. Note: at the current status, helios64 board patches have been disabled because the base device tree does not apply on kernel 6.9. Jira reference number AR-2348 How Has This Been Tested? [x] Compiled successfully [x] Upgrade the kernel (and device trees obviously) on a rk3318/rk3328 live system, dtbo applies correctly and system boots fine [ ] Upgrade the kernel on a live rk3399 system 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 [x] My changes generate no new warnings View the full article
-
Description As per subject, bump rockchip 32 bit edge kernel to 6.9. Patches have been left as is because all of them applied fine, except for the device tree overlay compilation and installation. The device tree things have changed in 6.9 and the patch does not apply anymore. After some headeaches with the terrible makefiles, the second commit of this PR contains some hints on how I did the job and can serve as a icebreaker for other families perhaps. In particular: Some little accomodations in the overlay Makefile. the kernel makefile already supports dtbo files, but it wants the sources with .dtso extension, so all the device trees in overlay directory must be renamed with .dtso extension. This also greatly simplifies the existing general-add-overlay-support-compilation patch the kernel lacks support for .scr, but it is simple to add into scripts/Makefile.lib (see general-add-overlay-compilation-support.patch patch) architectures that have the flattening device tree directory kernel config option enabled (like rockchip), really flattens everything. Changing a line in scripts/Makefile.dtbinst strips away the base vendor name (rockchip/ in this case) and keeps the subdirectories (perhaps this can be generalized to work with all families, but makefile are awkward and I could not find a simple way to strip just the first directory entry in the path) With such changes, the dtb deb package contains this in the boot directory: paolo@armbian-build:~/armbian-build/output/debs/dtbs$ find boot/ | sort boot/ boot/dtb-6.9.3-edge-rockchip boot/dtb-6.9.3-edge-rockchip/overlay boot/dtb-6.9.3-edge-rockchip/overlay/README.rk322x-overlays boot/dtb-6.9.3-edge-rockchip/overlay/README.rockchip-overlays boot/dtb-6.9.3-edge-rockchip/overlay/rk322x-bt-8723cs.dtbo boot/dtb-6.9.3-edge-rockchip/overlay/rk322x-cpu-hs-lv.dtbo boot/dtb-6.9.3-edge-rockchip/overlay/rk322x-cpu-hs.dtbo boot/dtb-6.9.3-edge-rockchip/overlay/rk322x-cpu-stability.dtbo ...cut... boot/dtb-6.9.3-edge-rockchip/overlay/rk322x-fixup.scr ...cut... boot/dtb-6.9.3-edge-rockchip/overlay/rockchip-ds1307.dtbo boot/dtb-6.9.3-edge-rockchip/overlay/rockchip-fixup.scr boot/dtb-6.9.3-edge-rockchip/overlay/rockchip-i2c1.dtbo boot/dtb-6.9.3-edge-rockchip/overlay/rockchip-i2c4.dtbo ...cut... boot/dtb-6.9.3-edge-rockchip/rk3188-radxarock.dtb boot/dtb-6.9.3-edge-rockchip/rk3228-evb.dtb boot/dtb-6.9.3-edge-rockchip/rk3229-evb.dtb boot/dtb-6.9.3-edge-rockchip/rk3229-xms6.dtb boot/dtb-6.9.3-edge-rockchip/rk322x-box.dtb boot/dtb-6.9.3-edge-rockchip/rk3288-evb-act8846.dtb ...cut.. boot/dtb-6.9.3-edge-rockchip/rk3288-rock-pi-n8.dtb boot/dtb-6.9.3-edge-rockchip/rk3288-rock2-square.dtb boot/dtb-6.9.3-edge-rockchip/rk3288-tinker-s.dtb boot/dtb-6.9.3-edge-rockchip/rk3288-tinker.dtb boot/dtb-6.9.3-edge-rockchip/rk3288-veyron-brain.dtb boot/dtb-6.9.3-edge-rockchip/rk3288-veyron-fievel.dtb ...cut... which seems quite ok (.dtbo, .src and readme files are all in overlay directory, .dtb files are outside) compared to a live installation I have around. Jira reference number AR-2347 How Has This Been Tested? [x] Compilation works without errors [x] Manually checked dtb file [ ] Upgrade of a living system - this is crucial, since the previous overlay compilation involved other steps that have been removed and I don't know if they are still necessary (perhaps they aren't, since dtc matured in the years). 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
-
Adds the needed files support the spidev on the NanoPi Neo3 with a different address. Tested on my own NanoPi Neo3 with a LoRaWAN concentrator connected via SPI. I am unsure about the changes in rockchip-fixup.scr-cmd. It needs a user to use a not very convenient device "number" specific to the NanoPi Neo3. But I did not know how to do this differently without possibly breaking other boards. Any suggestions on how this is usually done are welcome. Still it seems I am the only person on this planet to use SPI on the NanoPi Neo3 as no one else seems to have reported anything... Any constructive feedback is very welcome. View the full article
-
Description Currently, dtbo path in boot.ini is wrong. So we cannot load device tree blob overlays for cloudshell2. This commit fix this path in boot.ini How Has This Been Tested? Path was tested and dtbo's are succesfully loaded. 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 [ ] I have commented my code, particularly in hard-to-understand areas [X] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article
-
Description ssh.service activation fails on first boot due to a race condition with armbian-firstrun (missing host keys at ssh.service startup) By changing armbian-firstrun.service to run After=ssh.service SBC is always reachable realibaly via ssh, even on first run, so that it can be configured headlessly by remote login IT also reverts commit IDs: #911c756083164c32051d533ca3f2de488f202130 and #30c47f6f6cebd75f5c28866918fea093b8c82b44 disabling ssh.socket - this fixes SSH Deamon behavious to honour ListenAddress directive when set via sshd_config Jira reference number [AR-2356] How Has This Been Tested? [x] Compiled and first-run vanilla armbian Bookworm-Edge [x] Compiled and first-run vanilla Armbian Trixie-Edge [x] Simulated additional first-run(s) via systemd enable armbian-firstrun.service and touch /root/.not_logged_in_yet(Bookworm-Edge && Trixie-Edge) 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 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. Adding support for the fine3399 board. 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: Adding support for the fine3399 board 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. The system can boot normally and all other functions work fine, including PCIe support, but the WiFi and Bluetooth functionalities are not available due to the lack of corresponding drivers for AP6236 in the Armbian/firmware.I have submitted the corresponding driver for AP6236 to Armbian/firmware. Please kindly review and accept it. 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 [ ] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article
