Cannot get CPM to work

[kletzli]

I've compiled in the CPM GPIO control sample, and cannot get it to work on an XPort Pro. It appears to be failing in the library call to cp_config_type_set(), which always returns a -1.

I put some printf statements in that particular code section and get the following for the variables in the cp_config_type_set() function:

/etc # cpm -d -s
flag=0x200
cp_config_init() ... 3 (0x2,3)
cp_config_type_set(cp_config_nums): 3
cp_config_type_set(cp_config_ios):  2
cp_config_type_set(mask):           2
cp_config_type_set(cp_dev_fd):      3
cp_config_type_set(bits):           2
cp_config_type_set: ioctl executed
cp_config_type_set(2,1) ... -1
Error /etc/cpm.conf in 3

My /etc/cpm.conf file is as follows:

/etc # cat cpm.conf

config cp2 {
        type output
        state enable
        invert disable
}

If I add entries for cp1 and cp3, they never even get to the ioctl statement - seems that the mask is only allowing cp2. Is there a special configuration I need to perform to use all three of the CPx pins as programmable I/O? I also need to use the serial port, but do not need any of the control lines.

I suppose I should also mention I'm running the AUFS default configuration with the romfs.

Any ideas? Please let me know if you need additional information. Thanks.

Dave

[kletzli]

Looking at the integration guide, I'm pretty convinced this is a configuration problem, and that the CP pins are setup to support the serial port. I'll poke around some of the other pages, but does anyone know what setting I have to change in the kernel configuration to make these GPIO pins instead of serial port handshaking/control pins?

Thanks.

[kletzli]

Traced the problem in the cpm_ioctl() routine in the driver (ltrx_cpm.c), where there is no IO_CP_GPIO_DIRECTION case defined. This causes the default case to execute, which returns a failure code.

[vlkd2009]

The CP Management component in the XPort Pro is made up of two components – a kernel component (the CPM Device Driver) and the user land component (the CP Manager Library).

The CP Library interfaces with the CPM Device Driver via ioctl calls and provides an easy to use API for controlling the CPs within the user applications. The CPM and the LED Sample application demonstrate the use of the CP Library.

For the XPort Pro, the CPs are multiplexed with other device driver control signals. Depending on the customer’s platform, a CP can either be associated with a device driver (well known function) or be a general purpose I/O pin controlled by the CPM Device Driver in the kernel and controlled by the user applications via the CP Library.

In order to configure the mode of the CPs for a particular product, one must define the mapping of the CPs – answer whether they will be GPIOs or bound to one the supported device specific functions on that pin.

In directory linux-2.6.x/arch/coldfire/platform/520x/ please locate file cpconfig-xport_pro.h.
This is the file that defines the current mapping of the CPs. The default mapping in the kernel is set for working with the XPort Pro Evaluation Board. CP1 and CP3 are used as control lines for the serial port. CP2 is set as general purpose input.

There are other mappings also defined, but are kept disabled via #defines. These are just a representation of the other modes available on the XPort Pro Evaluation Board.

You MUST define your product specific mapping of the CPs here and enable that mapping table instead of the others in the header file.

For all the CPs that are mapped as General Purpose Inputs or General Purpose Outputs will now be controlled by the CPM Device Driver. The other CPs will be masked out. They are not available to the user space applications, since they are already in use.

The MatchPort AR product also has a similar configuration file named cpconfig-matchport_ar.h

Note:
For Linux SDK 2.0 release, we have made some changes to the kernel configuration (KConfig) so that one can quickly select some predefined maps or choose to manually set them up just like the above process. But for the 1.0.0.6 release, modifying the configuration header file is the only way to go.

[vlkd2009]

It appears that the CP Library and the CPM Device Driver were out of sync for the release 1.0.0.6. We made changes to the CPM Device Driver to support the mapping of the CPs to device specific functions and in the process broke the interface to the CP library. This is the reason why the CPM application is failing and the direct CP library access within the user applications are also having trouble.

We have fixed that for the SDK 2.0 release. I will be posting a beta of the SDK 2.0 release shortly. Please bear with us.

[kletzli]

Had already found the setting in cpconfig-xport_pro.h. I've created a patch that is a reasonable work-around to get by writing to the ports. I'm still having problems reading the ports.

Any idea on when you will be posting the new SDK?

Thanks.

[Systrom]

So when will we get this ??? so that cpm will work ?
also tftpd FW upgrade is broken .. i will fall back to good old dd to write the mtd devices !!!

[vlkd2009]

The SDK Beta Release has been posted. Please refer to the New Releases Thread for more details.
Thanks for your patience while we were trying to resolve image upload issues on the forum.

Your feedback on the Beta Release and specifically the CP Manager issues is greatly appreciated.

[Systrom]

do we have any document that describes changes to 1.0.6 ?? it is hard to switch to the new sdk in a quick manner as i had to adjust the sdk alot already to make properly work.

[sensorsoft]

Originally Posted by Systrom

do we have any document that describes changes to 1.0.6 ?? it is hard to switch to the new sdk in a quick manner as i had to adjust the sdk alot already to make properly work.

What I will be doing is diff'ing out my 1.0.0.6 changes against a "stock" 1.0.0.6 SDK, such that I end up with a series of patch files that represent my changes.

I can then attempt to patch those into the 2.0 beta SDK, or in any case, I will have all of my changes identified and encapsulated into patch files, so I also have the option to go and manually patch them in if need be.

If you want to see what has been changed in 2.0 (beta) SDK, simply diff 1.0.0.6 against the 2.0 beta SDK.

--Mike