CAN Patch for 9x28 Chips


#1

Hello,

I am trying to work with the IOT CAN Card.
I followed this CAN Driver Instruction from the Mangoh Github Wiki.

In was able to activate the driver in the menu config.
I was not able to apply the patch for two reasons:

  1. My WP76 has a QualCom 9x28 Chip. The Patch is fpr 9615 Chips.
  2. I have no “linux” dir in the kernel dir

I flashed the firmeware anyway and was able to run the following commands:

mux 5
mux 16
modprobe can
modprobe can-dev
modprobe can-raw
modprobe mcp251x

logread -f gives me the following output:

Jan 6 00:12:47 swi-mdm9x28-wp user.warn Legato: -WRN- | mux[3157]/framework T=main | LE_FILENAME le_ref_CreateMap() 149 | Map name ‘refmangoh_muxCtrl_ClientHandlers’ truncated to ‘refmangoh_muxCtrl_ClientHandler’.
Jan 6 00:12:52 swi-mdm9x28-wp user.warn Legato: -WRN- | mux[3168]/framework T=main | LE_FILENAME le_ref_CreateMap() 149 | Map name ‘refmangoh_muxCtrl_ClientHandlers’ truncated to ‘refmangoh_muxCtrl_ClientHandler’.
Jan 6 00:12:56 swi-mdm9x28-wp user.info kernel: [ 772.586754] can: controller area network core (rev 20120528 abi 9)
Jan 6 00:12:56 swi-mdm9x28-wp user.info kernel: [ 772.586963] NET: Registered protocol family 29
Jan 6 00:13:00 swi-mdm9x28-wp user.info kernel: [ 776.630398] CAN device driver interface
Jan 6 00:13:02 swi-mdm9x28-wp user.info kernel: [ 779.074982] can: raw protocol (rev 20120528)

But there is no can interface if I run ifconf -a.

I measured the voltages at the MUX to check if the MUX 5 command is working. And it works like it should. I also measured the Voltage of the SPI_SS and SPI_CLK at the IOT slot. The SPI_SS is permanent active, when I run the mux 5 command. But the SPI_CLK doesn’t shows any activity. I measured the SPI_CLK directly at the measuring pad close to the primary socket. But there is also no clock signal.

Conclousion:
I need the patch file for the combination MangohGreen + WP76 + 9x28 Qualcom Chip. Is there any way to get such a patch file?

Thanks for any help!


#2

Has nobody a solution for this?


#3

Hi @abrdsa,
Btw, there are some basic kernel build differences between the 9x15 and 9x28 kernels. For example,
looking at the 9x15 kernel if you do the following commands:
root@swi-mdm9x15:~# zcat /proc/config.gz | grep -i CAN

CONFIG_CAN is not set

root@swi-mdm9x15:~# zcat /proc/config.gz | grep -i mcp251
root@swi-mdm9x15:~#
This tells me that the 9x15 kernel does not include CAN subsystem drivers nor the mcp251x chip driver
for the CAN chip mcp2515 on the MangoH green. Whereas for the 9x28 kernel we get:
root@swi-mdm9x28-wp:~# zcat /proc/config.gz | grep -i CAN
CONFIG_CAN=y
CONFIG_CAN_RAW=y
CONFIG_CAN_BCM=y
CONFIG_CAN_GW=y

CAN Device Drivers

CONFIG_CAN_VCAN=y

CONFIG_CAN_SLCAN is not set

CONFIG_CAN_DEV=y
CONFIG_CAN_CALC_BITTIMING=y

CONFIG_CAN_MCP251X is not set

This tells me that all the CAN subsystem drivers are in the kernel build but the CAN driver is not.
The procedures described in the link posted by @abrdsa are relevant only for the 9x15 MangoH Green.
I have updated the title to state that this is for the 9x15 only.

On the latest MangOH Red we have moved the non-kernel built-in CAN modules out of tree. Thus, on
Red 9x15 we require only the mcp2515 chip driver (linux_kernel_modules/can_9x15/) and some
platform setup code (linux_kernel_modules/can_common). For the Green 9x15, copy the 2 Red 9x15
directories and update the mangoH.sdef to build these out of tree modules. Update the start_can.sh
in can_common to use the mux commands from the Green link. Note the start_can.sh does remove
the built-in CAN drivers and then reloads them in the correct order. Btw, we had a hangout we did
that discussed the process for built-in, loadable, and out-of-tree modules :
https://www.youtube.com/watch?v=JTm4Oez2UPM
That should be it.

Zahid


#4

Hello @Zahid,

thanks for your reply, it was helpfull!!

Works for me!

Thanks alot!


#5

Hello @Zahid,

the driver is working now, but not corectly.

The current status is:
I have a can0 interface in the linux system.
I can send ONE Can Frame to another CAN Device.

BUT:
I can’t send a second frame.
I can’t receive any frames.

For me that sounds like the interrupt of the MCP251x is not making its way to the driver. Any idea how to fix that?

Best
Alexander


#6

Are you using Green or Red? If Green, what slot?


#7

Mangoh Green Slot 1.


#8

Hi Alexander (@abrdsa),
I assuming you have integrated the CAN IOT code for mangOH/linux_kernel_modules/can_9x07 & mangOH/linux_kernel_modules/can_common.
I am going to run through the steps I used to decide on the IRQ settings for the Green
slot 1 that you are using (thus hopefully you can map other IRQs as you need).

Note that the IRQ config in the can_common/can_iot.c is for CF3_GPIO42 which is defined in MangOH Red schematics on Page 2 as IOT0_GPIO1. For the Green we have
IOT1_GPIO1 (slot 1, GPIO 1) to be used for the IRQ. This is defined in the schematics on
the Green schematics (page 2) as GPIO25. Sierra has a renumbering
of the gpio’s in sysfs. Inspect the yocto kernel directory in file drivers/gpio/gpiolib-sysfs.c
with the gpio mapping table for the WP76xx, ext_gpio_wp, to see that GPIO25 maps to
the real CF3 GPIO number of 51, “{“25”, 51,FUNCTION_UNALLOCATED},”. Then we
should enter these GPIO mappings in linux_kernel_modules/mangoh/mangoh_common.h to add the macro for CF3_GPIO25.
Then change irq code in can_iot.c to use CF3_GPIO25. Hopefully, that should do it.


#9

Hi @Zahid,

it finaly solved the problem.

Thanks a lot.

You should consider to improve the documentation.
Not just for the CAN Card, but for the IOT Interface itself.
It is realy tricky to find all the information to use or even design a new card. We would highly appreciate if you could offer a better documentation in this points.

Best
Alexander


#10

Hi @abrdsa
Please give back to the community as well.
This is a community based platform. We are looking for contributions. It’s important to contribute not just to be expect the platform to keep improving without the community giving back.

Ashish