HW_guy

As per documentation, I'm providing a custom kernel config, and I do get the message during my build: [ o.k. ] Using kernel config provided by user [ userpatches/linux-sunxi64-current.config ] which is great! The problem I face is that although the message is shown, the config that takes place seems to be something different, as can be checked when booting the image and looking up the config file in /boot/config-5.9.8-sunxi64 Digging a little bit in compilation.sh, I can see that cp .config "${DEST}/config/${LINUXCONFIG}.config" will only be run if KERNEL_CONFIGURE=yes As I want a fully automated image build, I have set in my config-default.conf: KERNEL_CONFIGURE="no" KERNEL_KEEP_CONFIG="no" How can I run then an automated (no human intervention) build with a custom kernel config? Am I missing something here or is it currently not possible?

Thanks for the tip @martinayotte! This also helped me to deploy successfully the mcp25xxfd CAN_FD driver on the oPi R1. If anyone else decides to move from CAN "classic" to CAN FD, look at:

Got it to work! candump and cansend produce expected results against another CAN device on the network. Great! 2 main issues were: target-path = "/"; (instead of target-path = "/clocks"; ) This solves uBoot FDT_ERR_BADOVERLAY error clock-frequency = <40000000>; (instead of clock-frequency = <0x400000>; ) This is the clock frequency of the Crystal oscillator on your board. If you get this wrong, you will still see traffic in the CAN bus, it will just be at the wrong bitrate. Also worth mentioning, if you are testing it against a non FD adapter (e.g. CANable), you should temporarily disabled the FD from the mcp2517/mcp2518 by using "fd off" when setting the interface: $ip link set can0 up type can bitrate 250000 fd off There is no need to set the dbitrate if you use fd off. More info about this here: https://www.kernel.org/doc/Documentation/networking/can.txt

Following a successful deployment of an MCP2515 SPI to CAN device with the great help of https://forum.armbian.com/topic/3588-can-bus-support-orange-pi-zero/ I’ve been looking into using an SPI to CANFD device with the orangePi R1 (H2+ based). (CANFD allows greater bitrate than the “regular” CAN) I am looking into using the driver made for the mcp2517fd/mcp2518fd, which has been submitted but not yet linux mainlined: https://github.com/msperl/linux-rpi/tree/upstream-v5.0-rc3-mcp25xxfd-v6.11/drivers/net/can/spi/mcp25xxfd This driver seems to be functional with the raspberry pi, and an example of PCB and associated overlay can be seen here: https://github.com/Seeed-Studio/pi-hats/tree/master/CAN-HAT I’ve been able to compile the drivers successfully (on kernel 4.19.72) and insmod/modprobe them. I also managed to compile the overlays into a dtbo (with dtc v1.4.7 and using -@ argument), but uBoot seems to find some errors in it: Applying kernel provided DT overlay sun8i-h3-spi1-mcp25xxfd.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADOVERLAY Error applying DT overlays, restoring original DT 29943 bytes read in 4 ms (7.1 MiB/s) Any ideas as to how I could look into debugging this? libfdt (https://github.com/qemu/dtc/blob/master/libfdt/fdt_overlay.c) shows 14 different ways that the dtbo file can fail loading and have FDT_ERR_BADOVERLAY thrown This is my dts: /dts-v1/; /plugin/; //#include <dt-bindings/interrupt-controller/irq.h> / { compatible = "allwinner,sun8i-h3"; fragment@0 { target-path = "/aliases"; __overlay__ { spi1 = "/soc/spi@01c69000"; }; }; /* the interrupt pin of the can-controller */ fragment@1 { target = <&pio>; __overlay__ { can0_pin_irq: can0_pin_irq { allwinner,pins = "PA2"; allwinner,function = "irq"; allwinner,drive = <0x0>; allwinner,pull = <0x1>; linux,phandle = <0x1>; phandle = <0x1>; }; }; }; /* the clock/oscillator of the can-controller */ fragment@2 { target-path = "/clocks"; __overlay__ { /* external 20M oscillator of mcp2517fd on SPI0.0 */ mcp2517fd_osc: mcp2517fd_osc { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <0x400000>; linux,phandle = <0x2>; phandle = <0x2>; }; }; }; /* the spi config of the can-controller itself binding everything together */ fragment@3 { //target = <0xffffffff>; target = <&spi1>; can_overlay:__overlay__ { status = "okay"; /* needed to avoid dtc warning */ #address-cells = <1>; #size-cells = <0>; mcp2517fd: mcp2517fd@0 { reg = <0>; compatible = "microchip,mcp2517fd"; pinctrl-names = "default"; pinctrl-0 = <&can0_pin_irq>; spi-max-frequency = <10000000>; interrupt-parent = <&pio>; interrupts = <0 2 8>; /* PA2 / IRQ_TYPE_LEVEL_LOW */ clocks = <&mcp2517fd_osc>; }; }; }; };

I had the same issue with running kernel version 4.19.72 (armbian 5.96): when asking for headers installation through armbian-config, 4.19.68 would be installed instead. There is one workaround if you compile your own image: just add them directly to it at compile time with INSTALL_HEADERS="yes" in your config-default.conf. This way, the headers present in /usr/src/linux-headers-X.XX.XX-sunxi will be the exact same as the ones used during the image compilation (and what you are currently running if you did not update anything on the fly).