industrialNETworXnetx

pwhiteis

pwhiteis

NRAO

| 06.11.2008 | 16:17 | 4 replies

Mapping CIFX 50-RE PCI memory using Linux

Hello,

I have written a small Linux Kernel module which reads the PCI configuration register for the CIFX 50-RE and maps the PCI IO address into Kernel space. When I dump this memory area, I do not see the ASCII tag "BOOT" or "netX" as expected. Is there any document which describes the CIFX50-RE PCI configuration? Finally, does anyone know if a Linux Kernel module is available which maps DPM into User space?

Thanks,

-Pete-

M T

M T

Hilscher Gesellschaft für Systemautomation mbH

| 06.11.2008 | 20:19

You wont see netX or BOOT in the DPM, as the CIFX50-RE comes without any flash and needs to be prepared by a driver. This functionality is covered in the freely available cifX Toolkit.

The following steps need to be taken (and are implemented in the toolkit)
1. Download and start a second stage boot loader through the DPM
2. Download and start firmware modules to the second stage loader
3. Download any configuration databases for the fieldbus

Additionally the toolkit offers the documented cifX Driver API.

Regards

MT

pwhiteis

pwhiteis

NRAO

| 10.11.2008 | 18:38

Quote:

The following steps need to be taken (and are implemented in the toolkit)
1. Download and start a second stage boot loader through the DPM
2. Download and start firmware modules to the second stage loader
3. Download any configuration databases for the fieldbus

I am using the C-Toolkit to do this. What I'm missing is what is happening in the Win32 device driver which accesses PCI space. I just tried an experiment:

- On Windows system, I install the cifx50-RE card and reboot. Then, using Visual C++ I startup the C-Toolkit application only. Immediately after the getMemPtr call the value of 1st longword of pbDPM is 'netX'. This allows the C-Toolkit to proceed as follows: The card is NOT HW Reset, cifXBootLoader is called, then channels are created, and FW, CNF files are loaded, and finally a CHANNEL_INIT restarts things properly

- On Linux, I take the same card, install and reboot. Then I load a kernel module which maps the PCI address of the card into kernel space and dump the memory. I get 0xc5d43b27 as the 1st longword of pbDPM. This causes the C-Toolkit to instead call cifXHardwareReset, which results in failure and as a result, the bootloader does not get loaded and program exits.

What I am wondering is if I have to write something to PCI configuration space to make the DPM area visible to me. It seems that one needs this in order to load 2nd stage bootloader.

-Pete-

M T

M T

Hilscher Gesellschaft für Systemautomation mbH

| 11.11.2008 | 07:45

pwhiteis wrote:

- On Windows system, I install the cifx50-RE card and reboot. Then, using Visual C++ I startup the C-Toolkit application only. Immediately after the getMemPtr call the value of 1st longword of pbDPM is 'netX'. This allows the C-Toolkit to proceed as follows: The card is NOT HW Reset, cifXBootLoader is called, then channels are created, and FW, CNF files are loaded, and finally a CHANNEL_INIT restarts things properly

- On Linux, I take the same card, install and reboot. Then I load a kernel module which maps the PCI address of the card into kernel space and dump the memory. I get 0xc5d43b27 as the 1st longword of pbDPM. This causes the C-Toolkit to instead call cifXHardwareReset, which results in failure and as a result, the bootloader does not get loaded and program exits.

What I am wondering is if I have to write something to PCI configuration space to make the DPM area visible to me. It seems that one needs this in order to load 2nd stage bootloader.

-Pete-

On Windows the cifX Device driver already did the steps I described before. The Toolkit demo delivered with the toolkit cannot handle a PCI card (as the comment in the implementation tells), as it cannot access the PCI registers from userspace.

      /* Insert the basic information from a prior PCI scan (or like here from the driver), into
         the DeviceInstance structure for the toolkit.
         NOTE: The physical address and irq number are for information use 
               only, so we skip them here. Interrupt is currently not supported
               and ignored, so we dont need to set it */
      ptDevInstance->fPCICard          = 0;           /* if we set true here, the card would get reset
                                                         and vanish from the PCI bus, as the PCI registers
                                                         cannot be restored from user mode */

So the card is completely prepared by the cifX Device Driver (Downloaded&Start Second stage loader, Downloaded&Start Firmware). These steps cannot be done in Win32-Usermode. Thats why this demo implementation just uses the pre-configured card.

There are 2 Systemcalls you will need to implement for this to work. OS_ReadPCIConfig and OS_WritePCIConfig. Before the HW Reset is executed the toolkit will call ReadPCIConfig so you can save the PCI configuration space (256Bytes) and call WritePCIConfig after the reset to restore the card and bring it back to the PCI bus.

The whole process is described in the "cifX Device Driver manual Edition 8" (which comes with Toolkit V0.930), chapter Toolkit (6), page 85ff. Chapter 6.6 shows how a PCI card is "brought to life".

Regards

MT

pwhiteis

pwhiteis

NRAO

| 14.11.2008 | 02:24

As it turns out, I had not correctly implemented the OSRead/WritePCIConfig functions. Additionally I set fPCICard = 1. This gets the 2nd stage bootloader down and I can now see DPM as it should be.

Thanks for your help.

Login