Unable to read write to CPLD in kernel space : T1040RDB

[hrishikesh23]

Below is the u-boot log :

U-Boot 2014.07QorIQ-SDK-V1.7+g659b6a2 (Dec 13 2014 - 18:00:52)

CPU0:  T1040E, Version: 1.1, (0x85280011)
Core:  e5500, Version: 2.1, (0x80241021)
Clock Configuration:
       CPU0:1400 MHz, CPU1:1400 MHz, CPU2:1400 MHz, CPU3:1400 MHz,
       CCB:600  MHz,
       DDR:800  MHz (1600 MT/s data rate) (Asynchronous), IFC:150  MHz
       QE:300  MHz
       FMAN1: 600 MHz
       QMAN:  300 MHz
       PME:   300 MHz
L1:    D-cache 32 KiB enabled
       I-cache 32 KiB enabled
Reset Configuration Word (RCW):
       00000000: 0c18000e 0e000000 00000000 00000000
       00000010: 66000002 80000002 ec027000 01000000
       00000020: 00000000 00000000 00000000 00032810
       00000030: 00000000 0342500f 00000000 00000000
Board: T1040RDB
Board rev: 0x01 CPLD ver: 0x09, vBank: 0

Here i can see the u-boot code is able to read the cpld version register.

I want to do the same thing from kernel space.

i added some code to in fsl_ifc.c : attached herewith.

i believe there is something with memory mapping the external device. need few pointers to start with.

I have attached a log.txt file herewith :

which details out the register values of IFC,u-boot log and kernel log.

Please do provide suggestion and valuable comments to proceed further.

Original Attachment has been moved to: log.txt.zip

Original Attachment has been moved to: fsl_ifc.c.zip

[bpe]

Unlike u-Boot, Linux kernel has a non-flat memory model, thus accessing

a memory mapped peripheral without explicitly mapping it first like you do in

cpld_read() is fundamentally wrong and results in errors like you

observe.

Suggestions:

1. Study ioremap and use it:

http://mirror.linux.org.au/linux-mandocs/2.6.12/ioremap.html

2. fsl_ifc.c contains a code that supports the IFC controller by itself,

   not the peripherals connected to it. If you need to access such

   peripheral from the kernel space, it is a good idea to create a

   separate module.

3. Kernel programming is different from u-Boot in many aspects. If you

   are not familiar with  it, studying the material at the link below

   can save you many hours of try-and-fail experience:

   http://www.xml.com/ldd/chapter/book/

Have a great day,

Platon

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[hrishikesh23]

Hi Platon,

Thanks for the valuable suggestions from your side.

i tried to figure out the physical address of MY CPLD :

Local Access window Register :
LAWBARH03: 0x0000000f LAWBARL03: 0xffdf0000 LAWAR03: 0x81f00010

PHYSICAL ADDRESS :
#define CONFIG_SYS_CPLD_BASE 0xffdf0000
#define CONFIG_SYS_CPLD_BASE_PHYS (0xf00000000ull | CONFIG_SYS_CPLD_BASE)

base_ptr  = ioremap((unsigned long)CONFIG_SYS_CPLD_BASE_PHYS, (1024*4));

if(!base_ptr)
{
  printk(KERN_INFO " OCU IOREMAP Failed ");
}
else
{
  printk(KERN_INFO " OCU IOREMAP successful ");
}

printk(KERN_INFO "BASE PTR rev: %x",base_ptr);

for(i=0;i<28;i++)
{
printk(KERN_INFO "CPLD DATA: 0x%02x\n",readb(base_ptr+i));
}
base_ptr value comes out to be 0xf10fe000.

Now when i try to read the cpld version that is (base_ptr + 2) does not match.

With respect to your previous suggestion. yes i am going to write the driver file separately.
but for now i just need to read/write the cpld. is there a some simple method to prove the simple read write.

[hrishikesh23]

I got the solution. I have to iomap the node of t1040rdb-cpld from dts file. then the base ptr is same. and works.

Thanks for the all support.