garinus

Hi, after having performed some tests I managed to have the mcp2518fd working with Armbian and Orange PI zero. In attachment there is a patch that works with the current version. The driver is the same as in the main kernel version: https://github.com/torvalds/linux/tree/master/drivers/net/can/spi/mcp251xfd after compiling the kernel it is necessary to add the following custom overlay in /boot/overlay-user /dts-v1/; /plugin/; / { compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,sun8i-h3", "allwinner,sun50i-a64", "allwinner,sun50i-h5"; fragment@0 { target-path = "/clocks"; overlay { #address-cells = <1>; #size-cells = <1>; can0_osc_fixed: can0_osc_fixed { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <20000000>; }; }; }; fragment@1 { target = <&pio>; overlay { can0_pin_irq: can0_pin_irq { pins = "PA10"; function = "irq"; bias-pull-up; }; }; }; fragment@2 { target = <&spi1>; overlay { #address-cells = <1>; #size-cells = <0>; status = "okay"; mcp2515 { reg = <0>; compatible = "microchip,mcp2518fd"; pinctrl-names = "default"; pinctrl-0 = <&can0_pin_irq>; spi-max-frequency = <10000000>; interrupt-parent = <&pio>; interrupts = <0 10 2>; /* PA10 IRQ_TYPE_EDGE_FALLING */ clocks = <&can0_osc_fixed>; status = "okay"; }; }; }; }; In my case the interrupt pin is on PA10 and the crystal on mcp is 20MHz, change them if necessary. copile it with armbian-add-overlay, then after the reboot launch the following commands: ip link set can0 type can bitrate 500000 ip link up can0 where 500000 is the bitrate of your canBus. It is possible to test the connection with: cansend can0 123#1122334455667788 or candump can0 mcp2518fd.patch

Hi, I'm sorry you meant this as a claim for help, the request aimed to knowing if there were any guides on how to make these kernel changes. I will not enter more into the discussion as in my opinion we are already off-topic. The need to switch from MCP2515 to MCP2518 is due to the fact that the MCP2515 is at the end of its life cycle, so soon other people will have the same need and therefore it seemed to me a good way to bring together all the procedures within a topic. Our questions have always been of this type, and at the end of the topic if we found a solution we summarized it, if necessary, and the same will appen in this case.

Hi, we are trying to make our Orange PI zero with custom shield working with an MCP2518FD on board with SN65HVD23 tranceiver. We started from the normal kernel already built, but according to this thread we found that it must be activated at compile time. So we downloaded the repo and built the Armbian image with this CAN configuration: CONFIG_CAN=y CONFIG_CAN_RAW=y CONFIG_CAN_BCM=y CONFIG_CAN_GW=y CONFIG_CAN_J1939=y # # CAN Device Drivers # CONFIG_CAN_VCAN=y CONFIG_CAN_VXCAN=y CONFIG_CAN_SLCAN=y CONFIG_CAN_DEV=y CONFIG_CAN_CALC_BITTIMING=y CONFIG_CAN_FLEXCAN=y CONFIG_CAN_GRCAN=y CONFIG_CAN_SUN4I=y CONFIG_CAN_TI_HECC=y CONFIG_CAN_C_CAN=y CONFIG_CAN_C_CAN_PLATFORM=m CONFIG_CAN_CC770=y CONFIG_CAN_CC770_ISA=m CONFIG_CAN_CC770_PLATFORM=m CONFIG_CAN_IFI_CANFD=y CONFIG_CAN_M_CAN=y CONFIG_CAN_M_CAN_PLATFORM=y CONFIG_CAN_M_CAN_TCAN4X5X=y CONFIG_CAN_RCAR=y CONFIG_CAN_RCAR_CANFD=y CONFIG_CAN_SJA1000=y CONFIG_CAN_SJA1000_ISA=m CONFIG_CAN_SJA1000_PLATFORM=m CONFIG_CAN_SOFTING=y # # CAN SPI interfaces # CONFIG_CAN_HI311X=y CONFIG_CAN_MCP251X=y # end of CAN SPI interfaces # # CAN USB interfaces # CONFIG_CAN_8DEV_USB=y CONFIG_CAN_EMS_USB=y CONFIG_CAN_ESD_USB2=y CONFIG_CAN_GS_USB=y CONFIG_CAN_KVASER_USB=y CONFIG_CAN_MCBA_USB=y CONFIG_CAN_PEAK_USB=y CONFIG_CAN_UCAN=y # end of CAN USB interfaces CONFIG_CAN_DEBUG_DEVICES=y # end of CAN Device Drivers we currently have two problems: 1. At the physical interface level, the driver in this kernel version works only with MCP2515, but not with our MCP2518FD. After reading the following tread we found the original repository from which we copied the folder with the MCP2518FD drivers, but we can't compile them and include them in our kernel (because we don't know how to do it). 2. We cannot activate the CanBus interface with these commands (we get Cannot find device "can0"): ip link set can0 type can bitrate 2000000 fd off ip link can0 set can0 up Is there a guide on how to build and include the drivers we need? Once the driver has been loaded we could test the .dtbo and see if the MCP initializes correctly.

Yes, the goal is to use a 485 tranceiver directly, without acting at high level on RTS pin. Now I use ioctl to verify the finish of the tx and i change the state of the pin. This works in 99% of cases except when the cpu is doing something and there is a delay before the change of the signal. I'm having diffculties in applying the patch because i'm a noob in git and kernel compiling. Please correct me if I do something wrong: put the file .patch in the folder build/cache/sources/linux-mainline/orange-pi-5.5 launch the command git apply rs485-8250_dw.patch error: patch failed: drivers/tty/serial/8250/8250.h:136 error: drivers/tty/serial/8250/8250.h: patch does not apply error: patch failed: drivers/tty/serial/8250/8250_dw.c:637 error: drivers/tty/serial/8250/8250_dw.c: patch does not apply then if the apply goes well launch compile.sh in /build I'm doing something wrong that i receive this errors?

Hi, thanks Martin. I built the last image. There aren't errors on boot and the ttS2 now works when I add the param param_uart2_rtscts=1. I have still some problems on rts. The signal is high until I open the serial connection, then goes low for all the time the serial stay open and then it become high when I close the serial connection. I made several tries with all the settings I know. The simplest metod to test it is using tio: tio /dev/ttyS2 -f hard-b 115200 With -f none (no hardwae flow control) the serial has the same behaviour.

thank you yoq, i did all what you said, but the serial works until i add param_uart2_rtscts=1 in the armbianEnv.txt file: verbosity=1 logo=disabled console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=uart2 usbhost2 usbhost3 rootdev=UUID=48c1e88a-b408-42ec-9d6c-9aaacd147312 rootfstype=ext4 user_overlays=uart2_rtscts_fix param_uart2_rtscts=1 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

I found this in boot: Applying kernel provided DT overlay sun8i-h3-usbhost2.dtbo 504 bytes read in 5 ms (97.7 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost3.dtbo 502 bytes read in 5 ms (97.7 KiB/s) Applying kernel provided DT overlay sun8i-h3-uart2.dtbo 502 bytes read in 5 ms (97.7 KiB/s) Applying kernel provided DT overlay sun8i-h3-uart3.dtbo 4155 bytes read in 5 ms (811.5 KiB/s) Applying kernel provided DT fixup script (sun8i-h3-fixup.scr) ## Executing script at 44000000 libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND ## Loading init Ramdisk from Legacy Image at 43300000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 7347265 Bytes = 7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK what can be the cause of this error?

I'm trying to debug it using the oscilloscope, and I see that the TX signal is not initialized to 3v3 when I add the "param_uart2_rtscts=1" in the armbianEnv.txt file. If I do not edit the armbianEnv file, the board initializes correctly the TX and RX signals.

Hi all, I need to enable rts/cts on my OrangePi Zero with Armbian buster with Linux 5.4.26-sunxi installed. I added the "param_uart2_rtscts=1" (I'm using /dev/ttyS2) to the /boot/armbianEnv.txt file On mi code I use this initialization of the port. xxxxx.c_cflag |= port_parity | port_bits | port_stop | CLOCAL | CRTSCTS | CREAD; Not only rts/cts but also the tx and rx pin aren't working now. Has anyone managed to enable the port on this board? Am I doing something wrong?

Hi, I have 3 Orange Pi Zero running with the same sd image. It's all working fine, but yesterday I added a fourth device, which for some reason took a MAC address that is the same of another device, causing issues on the connection for both of them. I'm using the mainline kernel ARMBIAN 5.38 stable Debian GNU/Linux 9 (stretch) 4.14.18-sunxi. Searching on the internet, I found someone saying that mac addresses for Orange Pis are randomly generated every time the device reboots, but in my case the taken MAC address is always the same for every device. I saw to that people suggested to check the content of the /etc/modprobe.d/8189fs.conf file, but I don't have it. Do you encountered the same problem? How is the mac address generated on the Orange Pi Zero? Thank you in advance for your cooperation.

Sorry I check a second time on the schematic and I saw the two resistor. I dissoldered them and now it work as i expected. On these pin i have two relays, so when it turns on the relay switch on for some seconds until or the bootloader or the program takes over the control of the pins. Yesterday I tried other option to clear the pins, I report them here to share: connecting on serial press space on the reboot until the console of the bootloader came up (it shows a line: Autoboot in 1 seconds, press <Space> to stop.) write on the console the command: setenv set-io 'gpio clear PXXX' where PXXX is the pin to clear, (eg. PA18), set instead of clear to set high. is possible to set two or more pins using: setenv set-io 'gpio clear PXXX; gpio clear PXXX' now we add on the line preboot. we need to know what is write on this line so we launch the command: printenv and we read the line preboot, like: preboot=usb start now we store the new command: setenv preboot 'run set-io; usb start' and we save saveenv now is possible to boot and reboot the system as usual from armbian: boot this is for me the command that start first. Does anyone know some command that start before the preboot? Or how to put it at the beginning of the bootloader

Hi, I'm tring to solve an issue on my Orange Pi Zero: at boot time the pins PA18 and PA19 are stucked to Vcc. I tried a lot of solution, now the best result is to add at the beginning of the file boot.cmd the command to clear the gpio configuration: gpio clear PA18 gpio clear PA19 and recompile the boot.scr. Despite this the pins goes HIGH for some seconds until the bootloader reach this line. What is the boot scheme? Why i get this pin HIGH? Is it because the I2C1 is configured? Is it possible to disable it? Thanks Simone