Jump to content

Active threads

Showing topics posted in for the last 365 days.

This stream auto-updates

  1. Past hour
  2. Hello, Thanks to @ALIGMSTEN and @SteeMan, these days I will write what I have tested. Regards,
  3. Thanks to sponsors like STMicroelectronics, Netflix, Living Optics, and ChromeOS, Collabora once again came in first place with the most contributors for this release, with 16 developers taking part. View the full article
  4. Today
  5. Hello everyone. This is my first post here. My background is software development but not very experienced in the Linux SBC world. So, I have 2x Radxa Zero 3W (not listed on Armbian) with a Rockchip 3566 MCU. And here the questions start... - why don't the Orange Pi 3B or Quartz 64B Armbian images, with the same MCU, don't work on the Radxa Zero 3W ? Aka, shouldn't an OS be portable ? I'm not expecting such of Windows, but I did expect it from Linux - what do the loaders contain exactly ? I have this situation where an older loader seems to boot with Armbian (and then shuts down) but a newer one doesn't... yet the older one doesn't work with the OS from Radxa but the newer one does. If we are talking memory address to chain-boot from, aren't these somewhat standard ? - the last time I installed some Linuxes on a PC was when socket 939 was a new thing, over 15 years ago. An installation was pretty slim, yet now a Debian image decompresses on an SD card to about 12 GB ?! - are these images actually an "in between" an official release kit and a working Linux image ? Thank you in advance for your patience !
  6. To be more precisely, I run my system with ioBroker... KR Martin
  7. Jojo

    C4 and opencl

    @usual user Well, that doesn't look that bad, I would say. But I personally am stuck where clinfo tells me that the GPU has not been found and that the kernel driver module seems not to be loaded. I tried a lot of thing like the default panfrost driver, self-compiled ARM driver, ARM userspace driver... Sure, I might have screwed some things up by myself. But I wouldn't have started tinkering around with that if it had worked from the beginning on .
  8. Hello all, I am using an Odroid N2 with a 16Gb emmc and Armbian Bookworm. However as this got a bit small, I installed Armbian Bookworm to a new 64Gb emmc (Armbian is installed on an SD and can then be copied/installed to emmc). This seemed to work fine, and I had a running system. However, on the 3rd or 4th reboot, I got the error that the file "boot.scr" wasn't readable. With that, the emmc was not bootable anymore. I reinstalled multiple times, and each time, the emmc would work for a 2-5 boots, but no more. Each time, i got the error as above, or the error as below (partition could not be found) I never had this issue with the 16Gb emmc? Does anyone know this behaviour, or better: does anyone know what is causing this and how to solve it? thanks,
  9. I've repaired my install by manually applying the failed dd step. 1. Mount the SD card on another Linux machine and open up a terminal. 2. `cd` to the SD card, for me it's `cd /media/scott/sdcard/` 3. `cd` to the u-boot image directory `cd usr/lib/linux-u-boot-current-tinkerboard/` 4. make note of which device the sd card is, you could use `mount | grep media` for example 5. for me it's `/dev/sdb` but it could be something like `/dev/mmcblk1` 6. IMPORTANT make sure you absolutely have the right device 7. run the following, replacing XXX with your target device `dd if=u-boot-rockchip-with-spl.bin of=/dev/XXX bs=32k seek=1 conv=notrunc`
  10. Hi. I testing out different images for my DIY NAS project. My plan is to use the Orangepi3b board with armbian bookworm and OMV. I have built images from armbian github, (main,trunk) the edge 6.7.10 kernel is working great. But I do get some Iperf3 retries when sending from Opi3b. From Opi3b 60-70MB/s To Opi3b 110MB/s. With Orangepi own bookworm image I have 110/110 and no retries. The same with Joshua Riek's Ubuntu server image, no retries and 110/110. Orangepi3b armbian with 6.7.10 kernel orangepi@orangepi3b:~$ iperf3 -c 192.168.10.197 -f M Connecting to host 192.168.10.197, port 5201 [ 5] local 192.168.10.155 port 56514 connected to 192.168.10.197 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 74.5 MBytes 74.5 MBytes/sec 217 19.8 KBytes [ 5] 1.00-2.00 sec 75.9 MBytes 75.9 MBytes/sec 218 11.3 KBytes [ 5] 2.00-3.00 sec 79.1 MBytes 79.1 MBytes/sec 200 25.5 KBytes [ 5] 3.00-4.00 sec 73.3 MBytes 73.3 MBytes/sec 225 29.7 KBytes [ 5] 4.00-5.00 sec 79.1 MBytes 79.1 MBytes/sec 210 33.9 KBytes [ 5] 5.00-6.00 sec 77.8 MBytes 77.8 MBytes/sec 211 86.3 KBytes [ 5] 6.00-7.00 sec 77.4 MBytes 77.4 MBytes/sec 202 36.8 KBytes [ 5] 7.00-8.00 sec 76.1 MBytes 76.1 MBytes/sec 207 73.5 KBytes [ 5] 8.00-9.00 sec 75.0 MBytes 75.0 MBytes/sec 222 12.7 KBytes [ 5] 9.00-10.00 sec 73.3 MBytes 73.3 MBytes/sec 239 11.3 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 761 MBytes 76.1 MBytes/sec 2151 sender [ 5] 0.00-10.04 sec 760 MBytes 75.7 MBytes/sec receiver Orangepi3b Ubuntu with 6.1 kernel ubuntu@ubuntu:~$ iperf3 -R -c 192.168.10.197 -f M Connecting to host 192.168.10.197, port 5201 Reverse mode, remote host 192.168.10.197 is sending [ 5] local 192.168.10.154 port 42888 connected to 192.168.10.197 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 112 MBytes 112 MBytes/sec [ 5] 1.00-2.00 sec 112 MBytes 112 MBytes/sec [ 5] 2.00-3.00 sec 112 MBytes 112 MBytes/sec [ 5] 3.00-4.00 sec 112 MBytes 112 MBytes/sec [ 5] 4.00-5.00 sec 112 MBytes 112 MBytes/sec [ 5] 5.00-6.00 sec 112 MBytes 112 MBytes/sec [ 5] 6.00-7.00 sec 112 MBytes 112 MBytes/sec [ 5] 7.00-8.00 sec 112 MBytes 112 MBytes/sec [ 5] 8.00-9.00 sec 112 MBytes 112 MBytes/sec [ 5] 9.00-10.00 sec 112 MBytes 112 MBytes/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.04 sec 1.10 GBytes 112 MBytes/sec 1 sender [ 5] 0.00-10.00 sec 1.10 GBytes 112 MBytes/sec receiver So to see if the vendor kernel was different I built with the new 6.1.43-vendor-rk35xx kernel, but It will not boot. build command: ./compile.sh build BOARD=orangepi3b BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=no RELEASE=bookworm J=4 It seems to be something with power to the NPU. ? "rockchip-pm-domain fdd90000.power-management:power-controller: failed to get ack on domain 'npu', target_idle = 0, target_ack = 0, val=0x6" uart log attachment kernelpanic.log
  11. Description Commit 562d96128ba6 introduces new variable "BOOT_SOC". This var is used at u-boot post install script, so "BOOT_SOC" must be avaiable on system image. Without this u-boot upgrade on tinkerboard will be completely broken. https://forum.armbian.com/topic/35677-tinkerboard-not-booting-after-updates/ How Has This Been Tested? [x] Add BOOT_SOC=rk3288 to /etc/armbian-release and the issue is fixed. 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
  12. You are right there is calibration code here. static int ccu_iosc_32k_prepare(struct clk_hw *hw) { struct ccu_common *cm = hw_to_ccu_common(hw); u32 val; if (!have_iosc_calibration) return 0; val = readl(cm->base + IOSC_CLK_CALI_REG); writel(val | IOSC_CLK_CALI_EN | IOSC_CLK_CALI_SRC_SEL, cm->base + IOSC_CLK_CALI_REG); return 0; } static void ccu_iosc_32k_unprepare(struct clk_hw *hw) { struct ccu_common *cm = hw_to_ccu_common(hw); u32 val; if (!have_iosc_calibration) return; val = readl(cm->base + IOSC_CLK_CALI_REG); writel(val & ~(IOSC_CLK_CALI_EN | IOSC_CLK_CALI_SRC_SEL), cm->base + IOSC_CLK_CALI_REG); } static unsigned long ccu_iosc_32k_recalc_rate(struct clk_hw *hw, unsigned long parent_rate) { struct ccu_common *cm = hw_to_ccu_common(hw); u32 val; if (have_iosc_calibration) { val = readl(cm->base + IOSC_CLK_CALI_REG); /* Assume the calibrated 32k clock is accurate. */ if (val & IOSC_CLK_CALI_SRC_SEL) return LOSC_RATE; } val = readl(cm->base + IOSC_32K_CLK_DIV_REG) & IOSC_32K_CLK_DIV; return parent_rate / IOSC_32K_PRE_DIV / (val + 1); } static unsigned long ccu_iosc_32k_recalc_accuracy(struct clk_hw *hw, unsigned long parent_accuracy) { struct ccu_common *cm = hw_to_ccu_common(hw); u32 val; if (have_iosc_calibration) { val = readl(cm->base + IOSC_CLK_CALI_REG); /* Assume the calibrated 32k clock is accurate. */ if (val & IOSC_CLK_CALI_SRC_SEL) return 0; } return parent_accuracy; } So I was looking at the code and I believe it's not the way the user manual calibrates the internal 32kHz clock.. I think it has to do with this. "One major difference regarding the H6 is the 24 MHz crystal is now routed through the RTC, as a digitally compensated oscillator (DCXO). This is not covered in this patch and will be supported later. Other differences are either unrelated to RTC or clock functionality, such as boot or crypto related registers, or the driver simply doesn't use the feature in question. One example of the latter is the calibration function for the RC oscillator. We consider this clock to be very bad and avoid using it." https://patchwork.kernel.org/project/linux-arm-kernel/patch/20181128093013.24442-7-wens@csie.org/ This code seems to be using the prescaler. IOSC_32K_PRE_DIV.
  13. The box can be toothpicked into a loader from where there are options available including ADB - which I also have no experience with. When trying to boot a generic rk3566 LE image from SD the device stays dark. Which means to me it's trying to boot. Good but not progress. I now have a UART adaptor but didnt get a word over the line yet. UART may need enabling or may be misconfigured or may not be a UART port at all. Flying blind is not great. ADB may be a more productive approach. Eyeballing the board there is a wifi 2.4/5 & BT chip (LGX9358) which had me worried cos no search engine hits but device tree says wifi_chip_type = "ap6398s" and this seems known. I tried to contact the manufacturer wrt general information and about getting maybe access to their (legacy) kernel SDK, but haven't heard back yet. Other sources suggest that this manufacturer is not interested in open source software on their products. Maybe this is true, maybe not, I'll wait, it's only been a week. There is a lot to learn and I havent spent much time on this yet, busy with other stuff.
  14. Yesterday
  15. TV Box Status Information Template Version 1.0 ======================================= TV Box Name: Leelbox S1 (PCB marking: "A95X_DDR4" "V1_1 2160906") CPU: AMLogic S905X RAM: 1 GB DDR4 (reported: 860 MiB) - 2 x SpecTek (Micron) "PPE05-075" "F1646" Armbian build file name: Armbian_community 24.5.0-trunk.226 DTB file used: meson-gxl-s905x-p212.dtb Kernel Version: Linux 6.6.22-current-meson64 Distribution Installed: Bookworm Working Ethernet (Yes/No): Yes Max Ethernet Speed that works (100/1000): to be verified Does wifi work (Yes/No): Yes (RTL8189ETV) Does bluetooth work (Yes/No): No Does HDMI audio work (Yes/No): Not tested Comments: - also sold as ABOX-A1 according to online sources; - installation to MMC worked without issue using the dedicated script.
  16. in the past I had a script to power on/off my TV through home assistant. The CEC supports putting devices in sleep and waking them up. If this works in Kodi then the standard kernel interface is available in Armbian. The important part is the hardware support - very few devices support sending CEC data but if Kodi can change input and turn on/off already, then we should be all good with Armbian and OPI5.
  17. This is amazing!!!! Is Wayland supported yet? I'll give this a shot once all these updates make it to the official pre-release images.
  18. I have created a small patch and pull request to package the linux-libc-dev headers in the Armbian build process. https://github.com/armbian/build/pull/6408 I'am open to work on suggestions if you notice anything.
  19. Description When booting U-Boot for rockchip64 or rk3588 devices, the error Failed to load '...-fixup.scr' pops up. This PR fixes this error by checking if the file exists before trying to load it. This PR partially fixes https://github.com/armbian/build/issues/6398 Unfortunately, I was not able to fix the error with missing kaslrseed (even though it may only be cosmetic). Note: U-Boot uses Hush cli language. Not this Hush cli (!) but a different old Hush shell in Busybox which is very badly documented overall unfortunately. I could not find any Hush functionality or a U-Boot command to check if the command kaslrseed exists. Should we include CONFIG_CMD_KASLRSEED for every rockchip64 and rk3588 device? Jira reference number AR-2105 How Has This Been Tested? Just compiling a new uboot image and installing it with dpkg -i (+ armbian-config after that) did not work. [x] Compiled a new image, flashed it and checked U-Boot log ./compile.sh build BOARD=nanopc-cm3588-nas BRANCH=vendor 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 [ ] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings View the full article
  20. Description Added the necessary parts to create linux-libc-dev packages when creating armbian images. This functionality was not added to the new build system but worked just fine up until v23.02. In my opinion linux-libc-dev should always be created when building an armbian kernel as the kernel versions often differ greatly from the ones natively in the distros (eg. debian bookworm: 6.1.76 vs. armbian current 6.6.21). Also the armbian package source previously included the package but does not anymore, so the latest updates available were 23.02.2. See also https://forum.armbian.com/topic/36140-linux-libc-dev-packages-not-available-after-2302/#comment-184962 How Has This Been Tested? Used the updated scripts to build deb packages and images for bananapi and rpi4b. The created package linux-libc-dev installs the expected headers. 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
  21. Description Fix/rewrite-kernel-config two kernel configs (mvebu64-current and sun50iw9-btt-legacy) to adapt them to the latest wireless driver updates in drivers_network.sh. Without doing a rewrite-kernel-config refresh, their kernel builds might potentially fail due to misconfigured wireless driver modules. Checklist: [x] My changes generate no new warnings View the full article
  22. @SteeMan - I ended up setting the environment variable BOARD_NAME in /etc/defaults/armbian-motd for the V1 boards - thanks again
  23. i've try Armbian_21.11.0-trunk_Aml-s812_focal_current_5.14.0.img with dtb file : meson8b_hd18q meson8b_m200_1G meson8b_m201_1G meson8b_m201C_512M meson8b_m201d meson8b_m203a meson8b_m202_512M meson8b_m203b meson8b_mk808bplus meson8b_mxq meson6-atv1200 meson8b-ec100 meson8b-mxq meson8b-odroidc1 meson8m2-m8s meson8m2-mxiii meson8m2-mxiii-plus meson8m2-wetek-core meson8-minix-neo-x8 meson8-tronsmart-s82 no result good i search dtb file with AP6330 wifi can you help , please thank you
  24. I've updated. Now my version is 6.1.47-current-sunxi. This is a very new Linux. I have a similar problem. Where can I tell the headers for this version. There is none of them
  25. I could not get either of the most two recent armbian x84 images to startup in a proxmox vm. Bummer, that I'll be migrating away from Armbian to Debian. I get it though, Armbian is great on SBCs.
  26. Yes, it crashes. It looks like it’s related to nvme drive activity. Running 6.8-rc7 atm.
  27. Description We are using out-dated hdmi patches and now mainline has hdmi phy merged. HDMI bridge driver is WIP by collabora but I can get it work on rock5b. Comparing deleted 0032 patch and new 0040 patch for rock5b, we can see devicetree is a llitle different from the old one, for example, we don't need node hdmi-con and hdmi0_out. We have to rewrite all these boards with hdmi support referring to rock5b: [ ] hinlink h88k [ ] rock 5a [x] rock 5b [ ] nanopi r6s/r6c [ ] khadas edge2 [ ] orange pi 5/5b [ ] orange pi 5 plus 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=rock-5b BRANCH=edge DEB_COMPRESS=xz KERNEL_GIT=shallow [x] HDMI works on rock5b 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
  1. Load more activity
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines