Jump to content

All Activity

This stream auto-updates

  1. Today
  2. Is there still an image somewhere to try? I just got back from being away and link for the image above is a 404.
  3. 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
  4. would love to use this board as part of my Ceph Cluster to back a distributed storage system for several Kubernetes clusters running ML workloads.
  5. 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
  6. 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
  7. Should be fixed by PR #6687 - my tests went well - additional testing and feedback welcome
  8. 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
  9. Hi, i got similar results, rk3588-eflasher-debian-bookworm-core-6.1-arm64-20240522.img works without issues but Armbian_community_24.5.0-trunk.667_Nanopi-r6s_bookworm_edge_6.8.10_minimal.img doesnt. Red light is the only one on. I got this result from the serial console - it shows an error about OPTEE: DDR 9fffbe1e78 cym 24/02/04-10:09:20,fwver: v1.16 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB Manufacturer ID:0x1 CH0 RX Vref:27.1%, TX Vref:19.8%,20.8% CH1 RX Vref:27.9%, TX Vref:19.8%,20.8% CH2 RX Vref:26.7%, TX Vref:21.8%,21.8% CH3 RX Vref:27.1%, TX Vref:20.8%,19.8% change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out U-Boot SPL board init U-Boot SPL 2017.09-g1b1171b7c71-220418 #fa (Apr 18 2024 - 11:12:44) unknown raw ID 0 0 0 unrecognized JEDEC id bytes: 00, 00, 00 Trying to boot from MMC2 No misc partition spl: partition error Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x00040000 ... sha256(7efcd01a0f...) + OK ## Checking uboot 0x00200000 ... sha256(b76f2f6c2a...) + OK ## Checking fdt 0x0031ec90 ... sha256(c5d44f02b4...) + OK ## Checking atf-2 0x000f0000 ... sha256(da90adf3a4...) + OK ## Checking atf-3 0xff100000 ... sha256(1163474a5b...) + OK Jumping to U-Boot(0x00200000) via ARM Trusted Firmware(0x00040000) Total: 402.313/555.636 ms INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang NOTICE: BL31: Built : 10:14:29, May 9 2023 INFO: spec: 0x13 INFO: ext 32k is valid INFO: ddr: stride-en 4CH INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO: system boots from cpu-hwid-0 INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 ERROR: dfs get fsp_params[0] error, 0xfead0004 != 0xfead0003 ERROR: dfs get fsp_params[1] error, 0x1111 != 0xfead0003 ERROR: dfs get fsp_params[2] error, 0x0 != 0xfead0003 ERROR: dfs get fsp_params[3] error, 0x60241520 != 0xfead0003 ERROR: loader&trust unmatch!!! Please update trust if need enable dmc INFO: BL31: Initialising Exception Handling Framework INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2017.09-armbian (May 21 2024 - 16:20:03 +0000) Model: NanoPi R6S MPIDR: 0x81000000 PreSerial: 2, raw, 0xfeb50000 DRAM: 8 GiB Sysmem: init Relocation Offset: eda3f000 Relocation fdt: eb9f9960 - eb9fecd0 CR: M/C/I Using default environment optee check api revision fail: -1.0 optee api revision is too low ### ERROR ### Please RESET the board ### I have no idea (yet) what that means or how to fix it. Any hints are apreciated :), thanks, J.
  10. yes, it is. 5.2V to .3 seems to be a reasonable value.
  11. Last week mesa 24.1.0 was released and friday 24.1.0-2 reached sid. This means that with sid + the armbian-edge kernels making panthor work on the rock-5b is pretty easy. Hope the AX210 follows soon. I've seen comments that it currently iis working on the Orange Pi 5. Can't wait until mesa 24.1 hits trixie.
  12. @D I'm really unfamiliar with DTS and such, hence there isn't much I'd help. But that are there any hints in dmesg etc? And as I suggested, try to decompile the dtb for your board and review that. In my case, I tried that for Orange Pi Zero 3 and did not see pwm devices listed. Hence, I'd guess those would need to be added by applying a .dtbo (device tree overlay binary). Accordingly, you may be able to check the same thing in a running system by checking them under /proc/device-tree as well. e.g. if you don't find them in /proc/device-tree, maybe that overlay isn't loaded.
  13. i don't have the tools to test the voltages and don't have a precise tunable powersource. as you seems to know about electronic can i ask you ? Is 6V will be too much overvoltage ?
  14. i don't need 32 for now, i jut bought it for the future. Should it be possible to lie on the size of the memory and only declare 16Gb usable ?
  15. @amazingfate you tested it on a 5C Lite right? I have an 5C non-Lite. Can anyone test the `Armbian_24.5.1_Rock-5c_noble_vendor_6.1.43.img.xz` on a Rock 5C (non-Lite)?
  16. Upgrade exiting DNS+Pi-hole / Syncthing / Veilid RPI HW to add own buildin NAS ! :-)
  17. The issue is probably due to the fact that rk35xx SoCs have to carve out some memory areas above 16 GB as reserved. Access to those areas leads to crashes. Because no fully open source TF-A is available yet, current mainline U-Boot has mechanisms landed to take the area information from the closed source TPL. Chances are the firmware you're using hasn't backported this yet, because devices larger than 16GB are only now becoming widely available in the open market.
  18. 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
  19. Download https://github.com/armbian/linux-rockchip/blob/rk-6.1-rkr1/arch/arm64/boot/dts/rockchip/overlay/orangepi-5-sata.dts and add it to the system using armbian-add-overlay orangepi-5-sata.dts it seems Like we don't have an overlay for sata0 for edge kernel yet
  20. Description As per title. How Has This Been Tested? [x] Patch test Checklist: [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article
  21. Description Maint, rename patch folder and rewrite kernel config. Jira reference number AR-2355 How Has This Been Tested? [x] Patch Checklist: [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article
  22. Description Maint, moving folder to expected location, add upstream patch Jira reference number AR-2354 How Has This Been Tested? [x] Patch test Checklist: [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article
  23. Voltage might be an issue. Most SBCs while rated for 5 volts prefer slight overvoltage, last but not least to compensate for voltage loss across wiring, connectors and the PCB itself. Even PSU sold by xunlong in combination with the OPi5, also while rated for 5v actually outputs about 5.2V. I verified this on an OPi5 month ago by measuring at the voltage source which was between 5.2 and 5.3 volts and the USB-A connector on the board which dropped to 5.0 volts when putting on a heavy CPU load. Since the PSU itself has way more than enough power voltage there were constant. Now think about what happens when your PSU only outputs barely enough wattage. Not only the voltage drop mentioned earlier will be there but also the voltage will break down at PSU level which increases the overall voltage drop to a (from a electronics perspective) crazy level. So if your input voltage is 5 volts only it will drop below this and malfunctioning is VERY likely then. I'd test this on the 5+ 32G model if I had one. But mine has 16G memory only.
  24. Description Maint, moving folder to expected location, add upstream patch. @belegdol Jira reference number AR-2353 How Has This Been Tested? [ ] CI Checklist: [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article
  25. More current (5A instead of 4A) did not resolve the problem for me. I tried the vendor distro (debian) and problem is not solved. Writing from SD to emmc makes crash too. even if no usb connected. A simple copy command make debian crash. i will go to orangepi forum 😕 for help.
  1. Load more activity
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines