Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

In case it is important I am using the Am1810 with the industrial IO board. I have tried both Linux branches and they both give the same error. It seems the pinmux isn't right but I am uncertain as to what it should be.

Can you dump the text of "ifconfig -a"?

-Mike

It is just the eth0 and lo entries. there is no can0 entry. the probe fails on boot up.

Can you please send me the revision of the board you are working with (there should be an 80- number somewhere on the board)?

I will try to reproduce the issue. Could be a pinmux thing, but that would mean we have a problem with our kernel configs or baseboard implementation file.

Are you just running a standard "make ... industrialio_defconfig"? Have you tailored your kernel at all?

Also, do you have anything plugged into the expansion connectors? The SPI lines I believe are also routed to the expansion headers.

-Mike

The revision # is 80-000268RI-2B

I downloaded the latest release today and compiled the kernel with out the audio card and mmc stuff. no modification to the baseboard implementation file.

I will redo the kernel with zero changes and see what happens.

I do not have anything plugin to the expansion headers. I am just using the industrial IO board it self.

The only other thing is I have your rs485 converter card plugged into the expansion port for UART2

Hello Mr. Young,

I have reproduced the issue here. There are some patches that never made it to our external git tree that need to be added.

You were right, one of the patches involved the SPI1 pin-mux enables.

I will get the patches pushed out. Are you dead in the water at this point? It may take me some time (a couple of days) to get that done.

The patches were originally built up against a 2.6.34-rc1 ("master") branch snapshot when the CAN controller was functionally verified. I would like to put them against our 3.2 branch, which is what we recommend folks use at the moment. OK?

I am very sorry for the inconvenience. Clearly, our software regression tests haven't been covering the CAN interface.

-Mike

Hello,

I've pushed a patch set (really only need the last one) to the mitydsp-linux-v3.2 branch that will get the CAN controller to probe again.

The root filesystem I have does not have the can utilities installed, I will look at that a little later.

The reset pin for the CAN part did not have the mux configuration correct, so that part was stuck in reset.

The other patches I had been referring to were already installed.

-Mike

I am dead in the water at the moment. I will try the patch set on the 3.2 kernel and let you know how it goes.

I applied the patch to the 3.2 kernel and it is now up and running. I will now check the the functionality with the canutils. Thanks for the quick response.

Jeremy

Well, Although the kernel now sees the CAN controller the ifconfig -a reads all zeros for everything even after I apply the IP command and bring up the interface with ifconfig. Let me know if there is anything else I need to do to bring up the interface.

Jeremy

Can you dump out the exact commands you used?

Thanks. (I am not a CAN expert, but I can try to track down the engineer that did the original testing).

-Mike

Okay, I had wiring problem. candump now dumps the received frames to the console. So we are up and running. thanks for your help.

Jeremy