• Content Count

  • Joined

  • Last visited

About HW_guy

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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 o
  2. 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:
  3. 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.
  4. 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, an
  5. 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).