Jump to content

All Activity

This stream auto-updates

  1. Past hour
  2. 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 .
  3. Hi Werner, What do you mean with outdated? Armbian Stretch? Armbian in general surely not... I run my home automation system on Rock64 and need to update npm to 8.xx anf nodejs to 18.xx I succeeded to update npm, but not yet nodejs, is it because Armbian? How can I change if needed to be future proof? Kind Regards Martin
  4. Today
  5. Hello, I saw that on March 13 you released an image with kernel 6.1.XX. using the image, I would like to share feedback. Should I write here or can I address someone specifically? Regards,
  6. 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`
  7. @Z11ntal33r thanks for posting the log. It looks obvious to me that the issue is the u-boot update process. In your logs I can see: `dd: error reading '/usr/lib/linux-u-boot-current-tinkerboard/': Is a directory` A bit of a dig into the code shows there's probably a dd process before that step that zeros out the boot sectors. Hence no boot at all on our boards. Might be an easy I'm not really sure how to patch any of this but thought I'd share what I found to help move this along.
  8. 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
  9. 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
  10. 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.
  11. 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.
  12. Yesterday
  13. 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.
  14. 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.
  15. That was one of the first things I tried but the result was the same. I know the document and I think there is code in "drivers/clk/sunxi-ng/ccu-sun6i-rtc.c". It is compiles as a kernel module but it doesn't get loaded. I'll put a few printk to see if its called and what happens inside.
  16. @OttawaHacker What specifically do you mean regarding "on/off" thing? Previously, I updated the Kodi config for for my CEC remote to manage how certain functions work with the remote in CEC. This was done through the menus in Kodi. If you can explain what you're trying to do, I'll try it on my setup. I usually leave the CEC setup so that the TV and other devices are not turned off or switched to/from when the events happen. If you go to Settings / System / Input / Peripherals and then select CEC Adapter, a list of items that can be modified is displayed. I don't know if all of them work or if it depends on your TV, other devices etc. Have a look. Let me know if you want me to post the list.
  17. My current TV doesn't have CEC but I'm planning to replace it with something that has CEC support and would really like to automate the on/off thing... Is cec-utils supported or is there an alternate kernel API?
  18. 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.
  19. That did it, @royk. Now I can boot from NVME. Thank you!
  20. 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.
  21. I found more information on 32kHz clock. Starting at page 275. https://www.scs.stanford.edu/~zyedidia/docs/allwinner/h616.pdf 3.13.3.4.6. RC Calibration The basic circuit of RC calibration is shown in Figure 3-39. Whether to output the calibrated RC clock can be selected by the RC_Cali_SEL control bit, the calibration principle is as follows. http://nskhuman.ru/allwinner/h616reglist.php?nreg=153 3.13.3.5.3. Fanout Set the bit0 of 32K_FANOUT_GATING_REG to 1, and ensure that external pull-up resistor and voltage are normal, then 32.768 kHz fanout square wave can be output. Fanout: The clock source of fanout can select RTC_32K, or 32K divided by PLL_PERI(2X), or 32K divided by HOSC. http://nskhuman.ru/allwinner/h616reglist.php?nreg=161 /* * There are other differences between models, including: * * - number of GPIO pins that can be configured to hold a certain level * - crypto-key related registers (H5, H6) * - boot process related (super standby, secondary processor entry address) * registers (R40, H6) * - SYS power domain controls (R40) * - DCXO controls (H6) * - RC oscillator calibration (H6) * * These functions are not covered by this driver. */ I guess there's no function to calibrate the internal RC oscillator yet. https://github.com/torvalds/linux/blob/master/drivers/rtc/rtc-sun6i.c This is the 32K_FANOUT_GATING_REG. #define SUN6I_LOSC_OUT_GATING 0x0060 rtc->ext_losc = clk_register_gate(NULL, clkout_name, init.name, 0, rtc->base + SUN6I_LOSC_OUT_GATING, SUN6I_LOSC_OUT_GATING_EN_OFFSET, 0, &rtc->lock); If we can find out which clock source we are using and change it to something more accurate? All though, Calibrating the RTC is the ideal solution. On these cheap boxes there is no external 32KHz oscillator.
  22. 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
  23. Just remove armbian from the list. There won't be any further updates anyways. Userspace is way outdated.
  24. Hi all, I have a Rock64, running ioBroker, and want to update the npm/nodejs to update all the adapters - mainly MQTT with which I have some problems. Trying to run apt update or iob nodejs-update, I run into: The repository 'http://apt.armbian.com stretch Release' does no longer have a Release file. in several versions. Can you help me? Sources.list is (changed, this works now) deb-src [trusted=yes] http://archive.debian.org/debian stretch main non-free contrib deb [trusted=yes] http://archive.debian.org/debian-security stretch/updates main non-free contrib Armbian.list is: deb https://apt.armbian.com stretch main stretch-utils stretch-desktop With hopful regards Martin
  25. 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
  26. 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
  27. @Joel @amazingfate Just tried the 6.1 image (Armbian_24.2.4_Orangepi5-plus_jammy_vendor_6.1.43_kde-neon-amazingfated_desktop.img.xz) and installed to the NVME (with only 1 ext4 partition) with armbian-install. Initially it didn't boot, there are no files in /boot. After copying the files from the boot partition of the SD-card to the /boot folder of the NVME and changing the UUID in armbianEnv.txt to the UUID of the NVME it boots.
  28. @SteeMan - I ended up setting the environment variable BOARD_NAME in /etc/defaults/armbian-motd for the V1 boards - thanks again
  1. Load more activity
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines