Strange conflict between CG5 (ethernet clk) and CG0 (ECSPI1 clk)...

[EdSutter]

For the last few days I've been working on an SPI-nor-flash driver on the MX6Q-SDB Sabre Smart Devices board.

Part of that initialization is to set the two CG0 bits in CCM_CCGR1; however, I'm noticing that when I do

that with a read/modify/write (ORing the register with 0x3) my ethernet interface stops working.  To get

around this I OR the register with 0x0c03 (which includes the CG5 bits for ethernet).  It appears that when I

set the CG0 bits of CCM_CCGR1, that causes the CG5 bits to need to be set again.

Any idea why I should have to do that?

[maheshmahadeva1]

The MX6 Linux BSP enables the ECSPI by only setting bits CG0 in CCM_CCGR, without impacting ENET.

[EdSutter]

Mahesh, thanks for responding...

At that point in the CPU's startup, all of these bits have already been played with by u-boot, so its a slightly different point in the CPU initialization.

Regardless of that, maybe I missed something in the RM, but it appears to me that some of the CCM_CCGR1 bits are either not readable or they can automatically clear themselves.  For example, I read the content of CCM_CCGR1, OR it with 0x00000C00 (CG5 bits set) and write it back.  Then I read the register again and neither of those bits are set.  This would explain why doing the logical ORing of 0x3 (to enable SPI in that same register) in my original question caused ENET to

not function.  Has anyone else observed this or can someone try to reproduce this?

[maheshmahadeva1 · Accepted solution]

There is no known limitation with modifying the CGR bits. You can play around with these bits using the memtool utility found in the Linux BSP, below is an example:

root@linaro-ubuntu-desktop:/home/linaro# /unit_tests/memtool -32 0x20C4068 8

Reading 0x8 count starting at address 0x020C4068

0x020C4068:  00400F3F 00300C00 01FF3033 177033C0

0x020C4078:  0000F303 0F000031 00000000 FFFFFFFF

root@linaro-ubuntu-desktop:/home/linaro# /unit_tests/memtool -32 0x20C4068=0xFFFFFFFF 1

Writing 32-bit value 0xFFFFFFFF to address 0x020C4068

root@linaro-ubuntu-desktop:/home/linaro# /unit_tests/memtool -32 0x20C4068 8

Reading 0x8 count starting at address 0x020C4068

0x020C4068:  FFFFFFFF 00300C00 01FF3033 177033C0

0x020C4078:  0000F303 0F000031 00000000 FFFFFFFF

[EdSutter]

Mahesh,

Ok I see my problem... I tried your test and it worked as you said.  My problem was in my code.  I had a misplaced parenthesis that was causing the macro to behave incorrectly.

Thanks!  Resolved!

Ed