Dennboy

  • Content Count

    31
  • Joined

  • Last visited

Everything posted by Dennboy

  1. Hi tparys, Thanks for your reply pointing to the upstream debian repo's, and sorry for posting an upstream bug here. I just looked up the dtc package in debian, and they appear to have it fixed in their newest update 1.4.7-4 from 27 january 2021 (see DTC debian changelog), it is now available in Armbian too, and seems to be working. Apparently it took some time to travel to the repo/mirrors, it wasn't yet available when I posted here. Kind regards, Dennis
  2. Dear all, My system logs: http://ix.io/2Pgj I consistency get a crash with dtc on both orangepi, nanopi neo+2, nanopi neo3 when I try to see the current devicetree via the filesystem, e.g.: $ dtc -I fs /sys/firmware/devicetree/base/ <stdout>: Warning (unit_address_vs_reg): /memory: node has a reg or ranges property, but no unit name <stdout>: Warning (clocks_property): /soc/spdif@1c21000:clocks: cell 0 is not a phandle reference <stdout>: Warning (clocks_property): /soc/spdif@1c21000:clocks: cell 2 is not a phandle reference .... /dts-v1/; / {
  3. I tried to override the interrupt affinity using a devicetree overlay, but also this seems to be ignored on sunxi. Anybody knows why? Is the affinity simply not implemented by sunxi? Below is the overlay to change the interrupt affinity. Devicetree before modification shows interrupt-affinity=<&cpu0>,<&cpu1>,<&cpu2>,<&cpu3>; /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3","allwinner,sun50i-h5","friendlyarm,nanopi-neo2"; fragment@1 { target-path = "/pmu"; __overlay__ {
  4. Hi, I experimented some further and set /proc/irq/default_smp_affinity to 1 for the first core, and it looks good on paper, but in practice most interrupts still go to the second core. echo 1 > /proc/irq/default_smp_affinity # dynamically load ADC kernel driver HomeCT2:~:% cat /proc/irq/162/smp_affinity 1 HomeCT2:~:% cat /proc/irq/162/effective_affinity 0 HomeCT2:~:% grep ads /proc/interrupts 66: 1397 0 0 0 sunxi_pio_edge 1 Edge ads131a04 162: 557 1394461 27 0 ads131a04-dev0 Edge ads131a04_cons
  5. Dear all, I'm frequently losing GPIO interrupts on various boards, which seem to be caused by bursty processes. When I shield the cores that have those interrupts according to /proc/interrupts with e..g. "cset shield --cpu=0,1" , way less interrupts are lost (e.g. for 4kHz interrupts one in hours instead of once per minute). Most of these (ADC) interrupts are handled by my own kernel module, but couldn't find how to restrict them to e.g. CPU0, and they are not movable using /proc/irq/*/smp_affinity. HomeCT1:~:% grep ads /proc/interrupts 66: 166559
  6. Hi Igor, Thanks very much for fixing this, building out-of-tree modules now works great in Armbian 20.02.1, on 5.10.12-sunxi (opi0) and 5.10.12-rockchip64 (neo3)! Kind regards, Dennis
  7. Yes Igor, for sure we are thankful for all your help here! I'm glad only toys got broken Hope you can teach your kid to repair toys some day I tried with the nanopineo2 (Armbian 20.11.6 Buster), the modules build fine but the installation reports SSL errors during installation of the module, that didn't appear on the orangepizero. The module(s) can be loaded and run after depmod -a. INSTALL pps_timer.ko At main.c:160: - SSL error:02001002:system library:fopen:No such file or directory: ../crypto/bio/bss_file.c:69 - SSL error:2006D080:BIO routines:BIO_new_file:no such file: ../cryp
  8. Hi @hjoe, Your fix seems to work beautifully on the orangepizero, thanks! My kernel module loads and runs beautifully. Tomorrow I'll try on nanopi neo2+ and neo3. @Igor Good luck with the family in these strange times. I hope things change for the best in the next months as more people get vacinated. Kind regards, Dennis
  9. Just retried with Armbian 20.11.7 kernel on nanopineo+2, but have the same issue on that board.
  10. Just retried with a very simple kernel module (added license in second attempt to get rid of kernel taint), with the same result. $ sudo modprobe ktest_module modprobe: ERROR: could not insert 'ktest_module': Exec format error $ dmesg|tail [ 24.151391] pps_timer: module PLT section(s) missing [ 33.784067] vcc3v0: disabling [ 33.784092] vcc5v0: disabling [ 33.784099] vcc-wifi: disabling [ 1413.944125] pps_timer: module PLT section(s) missing [ 7157.483985] ktest_module: module license 'unspecified' taints kernel. [ 7157.484004] Disabling lock debu
  11. Dear all, I can successfully build an out-of-tree module on 5.9 and 5.10.x kernels, but have trouble running them since Armbian 20.11.6. I fixed the module.lds missing problem using the receipt from a bugreport with an extra Makefile target: PWD=$(shell pwd) VER=$(shell uname -r) KERNEL_BUILD=/lib/modules/$(VER)/build # Later if you want to package the module binary you can provide an INSTALL_ROOT # INSTALL_ROOT=/tmp/install-root MY_CFLAGS += -g -DDEBUG # for newer 5.10.x kernels with x<=4 $(KERNEL_BUILD)/scripts/module.lds: $(KERNEL_BUILD)/scripts/module.lds.S sudo
  12. Dear maintainers, I have my sensors configured to reboot every night via a user cronjob (0 0 * * * /sbin/reboot), 14 sensors do this without a problem. I've fixed the nanopi neo+2 reboot from NAND some months ago (by re-using friendlyarm first stage u-boot). I just stumbled upon a failed reboot with one of my nanopi neo+2 nodes, after two successful reboots. Looking at the /var/log.hdd/syslog, it got stuck in the shutdown procedure when the watchdog reported a failure. The /var/log.hdd/syslog.1 extracts below show the start of the watchdog, and the stop of the watchdog and it
  13. Hi Quanta, Depending on the type of serial connector, it may (partly) power the nanopi, I usually only connect the GND, RX and TX with my FT232RL USB to TTL Serial Adapter. I've seen cases where parts of the board didn't fully reset when the serial was still connected. You can of course start a separate thread about serial adaptor power issues, which may be a more general issue. My reboot problems however also seem to occur without the serial connected, i.e. can can notice it doesn't become reachable again after reboot is invoked remotely. Kind regards,
  14. Yes, I use the image from FriendlyArm mentioned on their website (in my case, I booted the image that was on the MMC when it got shipped, which is most likely the same one). To capture their first stage bootloader with dd, I analysed the nand-sata-install script to see what needed to be copied. It may be possible to directly fetch the bootloader part from the sdcard image, with a similar dd with if=sdcard.img when you have a linux PC. Since u-boot is opensource, we can probably ask FriendlyArm for their software/configuration changes to the first-stage u-boot in order to get this i
  15. Hi Quanta, Thanks for you reaction. In my case the (re)boot from sdcard do not fail, I only had failing EMMC re-boots. I think the older first stage u-boot from FriendlyArm is running at slower speed so there is less chance of failures. Your u-boot on the sdcard may be fixable with a similar procedure, i.e. by capturing the first stage u-boot bytes from FriendlyArm NEO image and writing it to the sdcard instead of the MMC I guess it would be possible to do this on a linux PC without first booting from the sdcard. Before changing the sdcard, you can of course make a backup on your hard-dri
  16. For your information, with this work-around, U-boot warns about a SPL version mismatch (DRAM: sunxi SPL version mismatch: expected 3, got 2), but works nontheless. I wonder what is different in the SPL version that makes the boot possible (maybe the CPU frequency or DRAM frequency?), and if we can transfer this functionality to the newer SPL without breaking the reboot. See the serial trace of a successful reboot below for the NanoPi neo plus hardware revision 2.0 (revision 1.2 with 512MB DRAM works as well): [ 311.266768] reboot: Restarting system
  17. Dear all, Starting from NAND memory used to work fine on the nanopi neo plus2, however with the new boards (both v1.2 and v2.0 revision) we just obtained it frequently doesn't want to reboot, while a cold boot works fine (I tried also earlier u-boot versions (2019.04, 2018.11) without much success for the reboot from NAND). The re-boot process stops at this point (from the serial console): [ OK ] Reached target Shutdown. [ 152.452083] reboot: Restarting system U-Boot SPL 2019.10-armbian (Jan 25 2
  18. A way to disable hardware is by setting its status to disabled in the device tree, take a look at " dtc -I fs -O dts /sys/firmware/devicetree/base|less" to see the runtime devicetree. For instance for sound and video this would look like below, which you can convert to dtb with something like "dtc -I dts -O dtb youroverlay.dts > youroverlay.dtb" and add as a user-overlay (place dtb file in /boot/overlay-user) and add "user-overlays=youroverlay" line in /boot/armbianEnv.txt. /dts-v1/; / { compatible = "allwinner,sun8i-h3","allwinner,sun50i-h5","friendlyarm,nanopi-neo2"
  19. Hi Robert, I recently looked at the spi controller driver and discovered that the DMA configuration is not used by the SPI controller. It found that dma_set_mask_and_coherent only gives a result until kernel version 4.13.3 (and maybe a bit later), and fails after kernel version 4.14.39 and later). The result is that the DMA configured for SPI is silently ignored, and regular SPI transfers are done instead. Can you confirm that you don't see any performance improvement with DMA enabled? Kind regards, Dennis
  20. I digged further into the kernel code and had a look at spi.c and spi-sun6i.c. It appears that can_dma is a function pointer that is checked while setting up DMA for a transaction. This function pointer is not assigned in spi-sun6i.c (and spi-sun4i.c for that matter). This would explain why I don't see performance improvements when I try to use DMA for with kernel 4.13.3, since the DMA ignored because can_dma=0x0. I compared the behavior with the spi-stm32.c in the 4.14.67 kernel, and this driver reads the controller DMA addresses and sets the can_dma function pointer when they are
  21. Dear Ohms, Many thanks for your feedback. Indeed, the dma_set_mask_and_coherent call does no longer work with the same driver code and device tree. Regarding the sunxi modifications, I cannot easily find release notes of the modifications between kernel 4.13.3 and newer. The change could also be in the mainline kernel updates, e.g. stricter checks in the DMA or SPI driver. The strange thing is that independent of kernel version spi->controller->can_dma is 0x0, which is supposed to tell whether the controller supports DMA according to spi.h. @can_dma: determine whethe
  22. Dennboy

    Dennboy

  23. Hi user283746, Thanks for your suggestion, it could indeed be better to change the defaults, but then with the userspace governor. I initially placed the my cpufreq command in /etc/rc.local to make it persistent. cpufreq-info tells me the available frequencies and governers (e.g. on H5): available frequency steps: 408 MHz, 648 MHz, 816 MHz, 912 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil I have no clue how to underclock RAM, didn't find hints in
  24. Dear mainline developers, I'm writing a (mainline) SPI driver for de ads131 from TI which I would like to make use of DMA, on the orangePIzero H2, zero+ H3/H5 and nanopi NEO2+. On the 4.13.3-sunxi kernel (armbian 5.33), this works fine, the driver is automatically loaded when the associated devicetree overlay is loaded, and the DMA can be allocated. However, when I compile the same driver for newer kernels (4.14.17-sunxi, 4.14.39-sunxi, 4.14.67-sunxi armbian 5.59), the dma allocation no longer appears to work, while the SPI part of the devicetree is identical except for the phandle (ch
  25. Dear all, I discovered that the leds section is missing in the devicetree of orangepizeroplus2 H5 (at least upto kernel 4.14.39), and had to write an overlay to get them to work. The overlay has been attached. I've added this overlay file to /boot/overlay-user/ and added the overlay in /boot/armbianEnv.txt as follows: Kind regards, Dennis sun50i-h5-orangepi-zeroplus-leds.dts