AM5728: NOR boot timings in XIP mode

Please send a register dump of the GPMC registers (offset 0x0-x54 plus the appropriate CONFIG1-7 registers for the chip select being used)

Regards,
James

Hi,

Thank you very much for your kindness.
I really appreciate your help.

I will request to sent us the detail of those GPMC registers to the customer.

Best regards,

Hello,

 

Thank you very much for your kindness.

I really appreciate your help.

 

 

We got the details of those GPMC registers from the customer as below.

 

U-Boot# md 0x50000060 1　　　　GPMC_CONFIG1

50000060: 00401000                               ..@.

U-Boot# md 0x50000064 1　　　　GPMC_CONFIG２

50000064: 00101001                               ....

U-Boot# md 0x50000068 1       GPMC_CONFIG3

50000068: 22060514                               ..."

U-Boot# md 0x5000006C 1       GPMC_CONFIG4

5000006c: 10057016                               .p..

U-Boot# md 0x50000070 1        GPMC_CONFIG5

50000070: 010f1111                               ....

U-Boot# md 0x50000074 1       GPMC_CONFIG6

50000074: 8f070000                               ....

U-Boot# md 0x50000078 1      GPMC_CONFIG7

50000078: 00000000                               ....

 

They said "those register were checked after booting from SD-card".

Because NOR-boot program is under developing.

 

We would appreciate to continue to investigate the problem.

 

Best regards,

Can you double check the GPMC functional clock value? Use the AM572x Clock Tree Tool to trace the GPMC functional clock back to its source to determine what the frequency is.

James

Hello,
 
Thank you very much for your kindness.
I really appreciate your help.
I would like to ask the customer to check the GPMC functional clock value from your advice.

Best regards,

Hello,

 

Our customer sent us the feedback as below two;

 

  From E2E thread as below, they think the GPMC clock = 133MHz in default without any register setting at Booting.

  http://e2e.ti.com/support/arm/sitara_arm/f/791/t/498181?tisearch=e2e-quicksearch&keymatch=am572x%20133

 

 They also told us "SYS_CLK1(XI_OSC0)=20MHz & sysboot[9:8]-pin=10b" as a source clock setting from your advice.

 Because they think the GPMC clock is determined by SYS_CLK1 & sysboot-pin setting at Booting. 

  

1:Question:

  The GPMC clock = 133MHz in default without any register setting at Booting.

   Is this understanding correct?

 

  If there are any register to influence to the GPMC clock frequency, please tell us the register name which we should check.

   

2:We would also appreciate if you tell us where is the GPMC clock and how to find the GPMC clock in the AM572x Clock Tree Tool .

   We cannot find "the GPMC functional clock signal" which you mentioned.

 

Best regards,

The GPMC max functional clock is 88.6MHz, so the ROM should be adjusting the functional clock divider in GPMC_CONFIG1. If you are relying on the ROM configuration of the GPMC module, can you ensure you are not changing GPMCFCLKDIVIDER bit field?

Regards,
James

Hello,
 
Thank you very much for your kindness.
I really appreciate your help.

For Q1:
Our understanding is as below from your answer;
　- The ROM should be adjusting the functional clock divider in GPMC_CONFIG1.
- Please check GPMC_CONFIG1.GPMCFCLKDIVIDER bit field.

For Q2:
This question seems to be solved by ourselves.
- TRM(SPRUHZ6I) Figure 15-55.GPMC Integration shows "L3MAIN1_L3_GICLK as GPMC_FCLK source".
- We found L3MAIN1_L3_GICLK in the AM572x Clock Tree Tool .
- We did check the clock source like below;

SYS_CLK1=20MHz
->[DPLL_CORE]　
- [0x4A005120] CM_CLKMODE_DPLL_CORE=0x00000007
- [0x4A00512C] CM_CLKSEL_DPLL_CORE =0x00010A04
- [0x4A00513C] CM_DIV_H12_DPLL_CORE=0x00000204
->DPLL_CORE_CLKOUT2_H12 :532MHz
->CORE_X2_CLK ->532MHz
->[0x4A005100] CM_CKSEL_CORE=0x00000110 (div=2)
->L3_ICLK -> 266MHz
->Divider_L3MAIN1_L3_GICLK (div=2)
->L3MAIN1_L3_GICLK -> 133MHz

＜Registers above were checked after booting from SD-card＞
=> md 0x4a005120 1
4a005120: 00000007
=> md 0x4a00512C 1
4a00512c: 00010a04
=> md 0x4a00513C 1
4a00513c: 00000204
=> md 0x4a005100 1
4a005100: 00000110

From Your Advice:
We understood your request is the register value of GPMC_CONFIG1.
We already provided the register value of GPMC_CONFIG1 like below.
From this information, GPMC_CONFIG1.GPMCFCLKDIVIDER bit field: GPMC_CONFIG1[1:0]=0;
U-Boot# md 0x50000060 1　　　　GPMC_CONFIG1
50000060: 00401000

Is it enough?
If you need additional information to continue to investigate the problem, please tell us.

Best regards,

Sorry, I was incorrect in my previous post. The max frequency of the GPMC_CLK (which is the clock on the external pin) is 88.6 MHz. The functional clock of the GPMC controller can be 133MHz.

Your original question was about NOR boot. I double checked on a AM57x EVM, and the GPMC register dump that the customer sent does not reflect how the ROM sets up the GPMC controller during boot. The ROM sets the TIMEPARAGRANULARITY bit, so all timings will be x2 of what is set in the register. Also, several other registers are different than what the customer sent.

Is the scope shot taken before u-boot is executed or after u-boot is executed?

Regards,
James

Hello,

Thank you very much for your kindness.

I really appreciate your help.

Could you send your checked register dump?

We would like to know the difference with the customers result.

I'd like to check to the customer about your question below.

"Is the scope shot taken before u-boot is executed or after u-boot is executed？"

Our customer sent us the detail wave-form.

We would also appreciate if you check the attached pdf.

Best regards,

NOR_capt1.pdf

Most are you timings seem to be double than what you'd expect. I think it is possible that you are clocking the GPMC functional clock at half the speed than what you think it is. As an experiment, can they put the GPMC in sync mode? This will output the GPMC_CLK and will allow them to verify the functional clock frequency.
I also noticed that the have WAITREADMONITORING enabled. Are wait states being added, which is causing the delays they are seeing? Can they also check the WAIT signal on the scope?

Regards,
James

Hello,

 

Thank you very much for your kindness.

I really appreciate your help.

 

I'd like to send the answer to the customer.

 

We would also appreciate if you answer the question on page 6 of previous attached pdf like below.

 

Question:

  Can we capture DATA at this timing?

 

- They would like to know the appropriate DATA capture timing at NOR-boot(XIP mode).

- They found “GPMC_CONFIG5_i[20:16] RDACCESSTIME:Reset value =15" in TRM(Table 15-530. GPMC_CONFIG5_i).

  The appropriate DATA capture timing seemed to be 112.8[ns]. (=7.52x15 @133MHz-GPMC_FCLK).

 

Is this understanding correct?

 

If you have any recommended way or comment for the appropriate DATA capture timing at NOR-boot(XIP mode), please tell us.

 

Best regards,

Hello,

 

Thank you very much for your kindness.

I really appreciate your help.

 

Our understanding is as follows;

 - There are some difference between our CONFG1-7 register dump at SD-boot and your CONFIG1-7 register dump at NOR-boot(XIP mode).

 - At NOR-boot(XIP mode), the ROM sets CONFIG register such as the TIMEPARAGRANULARITY bit.

 

So, they would like to know the CONFIG registers values precisely at NOR-boot(XIP mode).

But they cannot find any information the CONFIG registers values which the ROM code sets at NOR-boot(XIP mode) in TRM(SPRUHZ6I).

 

So, our customer strongly require to provide your checked register dump about CONFIG1-7 at NOR-boot(XIP mode), again.

 

Currently, their product including booting software is under developing.

So, they cannot check the CONFIG register value which the ROM code sets at NOR-boot(XIP mode).

The only way seems to be check the waveform and reading CONFIG registers at SD-boot with SDK(Linux).

 - The NOR-boot(XIP mode) behavior seems to be checked by observing oscilloscope waveform.

 - But currently, they have only way to check the CONFIG register at SD-boot with SDK(Linux).

 

Could you provide your checked register dump about CONFIG1-7 at NOR-boot(XIP mode)?

 

Now, we are waiting for the recommended way or comment for the appropriate DATA capture timing at NOR-boot(XIP mode) from you.

 

And we also appreciate if you provide your checked register dump about CONFIG1-7 at NOR-boot(XIP mode).

 

Best regards,

Do they have JTAG access? If so, they can inspect the registers with CCS after ROM attempts XIP NOR boot.
Here is what i see:
GPMC_GPMC_CONFIG1_0
00400010
GPMC_GPMC_CONFIG2_0
00101080
GPMC_GPMC_CONFIG3_0
00020201
GPMC_GPMC_CONFIG4_0
0F031003
GPMC_GPMC_CONFIG5_0
000F1111
GPMC_GPMC_CONFIG6_0
0F030080
GPMC_GPMC_CONFIG7_0
00000F48

Regards,
James

Hello,

 

Thank you very much for your kindness.

I really appreciate your help.

 

I'd like to send the answer to the customer with your suggestion about inspecting by JTAG&CCS.

 

We also appreciate if you tell us the recommended way or comment for the appropriate DATA capture timing at NOR-boot(XIP mode) .

 

Best regards,

You can check timing of data capture during NOR boot by triggering on the first accesses to the NOR after power up.

James

Hello,

 

Thank you very much for your kindness.

I really appreciate your help.

 

From your answer, can we understand "the appropriate DATA capture timing should be design by observing the triggering on the first accesses to the NOR

on the customers board using like oscilloscope?"

 

Are there any recommended description to design the appropriate DATA capture timing for XIP-NOR in TI official document?

We are little confused. So, could you tell us about it in more detail?

 

Our customer's Question seems to be like below;

  -The data capture timing for XIP-NOR should be designed by the register value of GPMC_CONFIG5_i[20:16](RDACCESSTIME).

 

Is this understanding correct? (Is it enough?)

 

We would appreciate if you answer this question.

 

Best regards,

Sorry, I'm confused by your question.
The timing configured in the GPMC_CONFIG0-7 registers for a particular chip select should be reflected on the interface during GPMC accesses. Your customer sent their GPMC configuration, however, the timing they configured does not match what they see on the interface. I agree this is a problem.
I need them to correlate the configuration with the scope pictures. It is likely that the ROM configures the GPMC one way, and uboot configures it a different way. When are the scope shots taken? Is it when the ROM is executing during boot, or when they are sending a command in uboot?

It would be good to get scope shot from both scenarios.

Regards,
James

Hello,

 

Thank you very much for your kindness.

I really appreciate your help.

 

Sorry for your confusion.

It seems to be understood what you say.

So, at first, I'd like to clarify your confusion.

Then, I'd like to focus on how to answer our customers question.

 

>Your customer sent their GPMC configuration, however, the timing they configured does not match what they see on the interface.

 - The waveform is captured at NOR-boot(XIP mode).

 - The CONFIG0-7 register values are read after SD-card boot.

So, the waveform picture seems to be mismatch with CONGIG register configured behavior.

The reason/back-ground are as below;

  - Their NOR-boot program is under developing.

   -> So, they told us "it is difficult to read CONFIG register after NOR-boot(XIP mode)". 

  - They would like to know "The GPMC behave with CONFIG register reset value or not?"

    -> They got the answer "The GPMC behave with CONFIG register which the ROM sets" in this E2E thread.

 

Then we shall focus on to their question in previous provided NOR_capt1.pdf(page6) as below;

 - "Can we capture DATA at this timing?"

 

I'd like to answer like below;

 - The DATA capture timing is basically specified with CONFIG registers including RDACCESSTIME bit which the ROM code sets at NOR-boot(XIP mode).

    Please check the CONFIG register values after NOR-boot(XIP mode).

    15.4.4.9.8 Access Time (RDACCESSTIME / WRACCESSTIME) in TRM is also helpful.

 

If you agree, I'd like to the answer to the customer.

 

Best regards,

I can't answer that, because I don't know what the timing parameters of the device you are reading. The READACCESSTIME will be dependent on the access time of the device you are reading. You must set this based on specs from that device. You cannot rely on what the ROM code sets. You may also need to utilize WAIT states based on the device's specifications

Regards,
James