CS3 not asserted in P1022 based proto system

[rammurmu]

Hi,

  We have proto system based on P1022. The following are the Chip Select and LAW configuration. CS0 ,CS1 and CS2 are currently not in use. CPLD is connected to CS3. We are probing CS3 on pull-up resistance. CS3 is not asserted on trying to access the CPLD. Data lines 0 to 7 and address lines 23 to 31 are connected to CPLD after latch/buffer.

The target is booted up with SPI flash.

BR0 : 0xE8001001

OR0 : 0xF8000FF7

BR1 : 0xFF800801

OR1 : 0xFFF8FF7

BR2 : 0xFFDF0801

OR2 : 0xFFFF8FF7

BR3 : 0xFFDF8001

OR3 : 0xFFFF8FF7

LAWBAR0 : 0x000E8000

LAWAR0   : 0x8040001B

LAWBAR1 : 0x000FFDF0

LAWAR1   : 0x8040000F

What could be reason and areas to debug ?

Regards

Ram

[ufedor]

If two or more eLBC banks overlap, the lower numbered one takes precedence.

In the described case BR2/OR2 are the same as BR3/OR3.

Set BR2[V]=0 and test the system behaviour.

[rammurmu]

>>In the described case BR2/OR2 are the same as BR3/OR3.

BR2 : 0xFFDF0801

OR2 : 0xFFFF8FF7

BR3 : 0xFFDF8801

OR3 : 0xFFFF8FF7

I still have a doubt how these two configurations (BR2/OR2 and BR3/OR3) are same.

I did try with BR2[V]=0 , however in this case the target did not boot at all.

In fact without the CS2 configuration and BR2[V]=1, the target is not booting up.

We have SPI flash to boot the target.

Please suggest.

[ufedor]

Sorry, I've overlooked that BR2 and BR3 have different base addresses.

The required fix for the CS3 is:

LAWAR1   : 0x80400010  (128kB instead of 64 kB0

Also, you wrote in the original request:

> CS0 ,CS1 and CS2 are currently not in use.

and in the last update:

> In fact without the CS2 configuration and BR2[V]=1, the target is not booting up.

These two statements seem to be contradictory.

[rammurmu]

Hi,

   We are also quite surprised and trying to debug, in spite of CS2 configuration not being used in our target, why the target does not boot without the CS2 configuration.

We have SPI boot flash to boot the target and u-boot code lies in the SPI flash only.

After the required fix of LAWAR1 (0x80400010) , CS3 is still NOT asserted.

[ufedor]

Please return back the LAWAR1 value - i.e. 0x8040000F.

Please explain how you test the CS3 behaviour?

Are you probin the signal at the processor's pin?

[rammurmu]

>>Please explain how you test the CS3 behaviour?

We have a memory read/write utility(p1022_util) to read/write any processor memory and memory mapped location(eLBC) having any size(byte, half word, word). CPLD is connected to  CS3 in our target. The utility 'p1022_util' can correctly read processor registers after target(kernel) boot-up. It(p1022_util)is verified by reading LAW and OR/BR registers.

                      On trying to read CPLD registers using this utility(p1022_util) in the memory mapped address range which is 0xFFDF8000 to 0xFFE00000, it is expected that CS3 should be asserted. However it is NOT.

./p1022_util 0xFFDF8000 b                ##CPLD port size is of 8-bits

>>Are you probin the signal at the processor's pin?

Yes

[ufedor]

Can you use a debugger to completely exclude a software issue?

What are MMU settings?

[rammurmu]

Hi,

   I have relocated the CS3 configuration to different address space and excluding all other CS configuration. Now I have only CS3 configuration. The target is booting up correctly irrespective of CS2 configuration as opposed to the case observed earlier.

BR3 : 0xE0008801

OR3 : 0xFFFF8FF7

LAWBAR0 : 0x000E8000

LAWAR0   : 0x8040001B

LAWBAR1 : 0x000FFDF0

LAWAR1   : 0x80400010

LAWBAR2 : 0x000E0000

LAWAR2   : 0x8040000F

MMU setting is attached herewith. Still the CS3 is not asserted.

[ufedor]

Please check the eLBC NOR muxing - refer to the P1022 QorIQ Integrated Processor Reference Manual, Table 3-3. eLBC NOR muxing-DIU.

[rammurmu]

Multiplex control register configuration seems OK.

GUTs_PMUXCR   : 0xA3801C00

GUTs_PMUXCR2 : 0xF28A8000

GUTs_DMUXCR   : 0x00000000

[rammurmu]

PFA tlb0 settings.