Dear Sir or Madam,
[Environment]
Boot: Parallel NOR Flash (EIM_CS0)
[Issue]
Refer to Table 43. EIM Asynchronous Timing Parameters Table Relative Chip to Select in IMX6SDLAEC(Rev.3.0).
There is below description.
"WE35" : Max "3 + (OEA - RCSA)"
My customer set the OEA = 0 and RCSA = 0.
So, It should become WE35 = Max 3 [ns].
But, my customer observed WE35 = 20 [ns] with 1st access on custom board.
[Reproduce Steps]
I reproduced this issue following steps on SABRE-AI.
1. Start-up the SABRE-AI from Parallel NOR.
2. Measured 1st clocks of CS and OE.
3. You can see the 20 [ns] delay.
[Question 1]
Why was WE35 = 20 [ns] observed with 1st clock?
[Question 2]
Refer to OEA bit of EIM_CSnRCR1 field descriptions in i.MX6SDLRM(Rev.1) (P.1043).
There is description of "If EIM_BOOT[2] is 1, the reset value for EIM_CS0RCR1 is 0b010".
Could you tell me the external pin connected with "EIM_BOOT[2]"?
Keita
解決済! 解決策の投稿を見る。
Hi Keita,
here is explanation why you can see two different delays between /CS and /OE:
So observed behavior is correct.
/Jiri
Just to clarify, you are using an i.MX6S processor and the 20ns delay occurs only on the first clocks? From what I understand the delay is beyond the expected maximum only on the first events.
As for your second question, EIM_BOOT[1:0] are internal chip signals and are fixed. Signals that are mapped to GPIO pins for override are listed on table 8-9 of the i.MX6S Reference Manual Rev 1.
In table 6-2 of the Reference Manual you may see that EIM_BOOT[1:0] bits correspond to DSZ[1:0] bits of the EIM_CS0GCR1 register. The reset values are given and cannot be changed. In case you wish to configure these you would need to change the register after reset.
Hi, gusarambula
Thank you for your reply.
>Just to clarify, you are using an i.MX6S processor and the 20ns delay occurs only on the first clocks?
>From what I understand the delay is beyond the expected maximum only on the first events.
Yes. This phenomenon occurred only on the first clocks (events).
(i.e. There is no problem in the waveform after 2nd clocks.)
But, 20ns delay had exceeded the i.MX6SDL's spec "WE35".
So, my customer was worried with the specification violation.
Keita
Hello Keita San,
Are you using the SDK to test it? or do you think you can share the piece of code regarding the first event, I am thinking the problem it is related to the way the register settings or the flag status check, maybe a flag that it is already set and never clear after the first event?.
Do you think your customer can test it using the SDK in case you reproduced the issue cn you please share the steps.
Dear jamesbone,
Hello.
[Steps on SABRE-AI]
I tested it on i.MX6 SABRE-AI and used L3.0.35_1.1.0.
1. Write the Linux image (bootloader) to Parallel NOR Flash.
2. Power On.
3. Measure on Parallel NOR (Pin#32) [= EIM_CS0] and Parallel NOR (Pin#34) [= EIM_OE] on SABRE-AI.
4. I was able to see the this issue.
Reproduced on customer's board is same.
Best Regards,
Keita
This problem is probably related to the way the registers and flags are set on the driver and that’s why it’s appearing only on the first events.
Even if it’s out of the datasheet parameters it shouldn’t cause any functional issue other than that first added delay. Are you encountering any functional issue other than this?
Hi gusarambula,
>This problem is probably related to the way the registers and flags are set on the driver and that’s why it’s appearing only on the first events.
Sorry. I couldn't understand well.
Let you clarify why occurred 20[ns] delay regardless OEA=1 && RCSA=0.
Best Regards,
Keita
I had some feedback on this issue:
From the u-boot, there is a setting in weim_norflash_cs_setup() in mx6q_sabreauto.c
writel(0x0a020000, WEIM_BASE_ADDR + 0x008);
which means RCSA is 0, OEA is 0. //EIM_BOOT[2] gives 2 cycles
After entering into kernel, there is another setting in mx6q_setup_weimcs() of board-mx6q_sabreauto.c
writel(0x1C022000, nor_reg + 0x00000008);
which means RCSA = 0, OEA = 2. //kernel should be 2 cycles
May we know which stages you set these values and at which stages is this delay being measured?
Dear gusarambula,
Hello.
Please send me your answer as soon as possible.
Many days have passed about this SR from my first question (Jun-2).
Best Regards,
Keita
cyborgnegotiator Sep 19, 2014 7:10 AM (in response to gusarambula)
Hi,
I checked boot rom. After fast look to code, I cannot see any changes to EIM_CS0RCR1 (use preset values).
But here can be another possibility, EIM_WIAR[ERRST] - first fetch access will be pended until device will be ready.
Regards,
Jozef
Dear Karina,
Thank you for your reply.
>I checked boot rom. After fast look to code, I cannot see any changes to EIM_CS0RCR1 (use preset values).
OK. I got it.
>But here can be another possibility, EIM_WIAR[ERRST] - first fetch access will be pended until device will be ready.
A user can't set the EIM_WIAR[ERRST] register at the ROM boot-up.
And, default setting of EIM_WIAR[ERRST] was RDY_INT After Reset Disable.
Is this register cause of the problem?
Does it make this register Enable in internal boot ROM?
Best Regards,
Keita
cyborgnegotiator please continue with the follow up.
Dear Karina and Jozef,
Do you have any update?
Keita
Jozef Maslik any update?
Dear Karina and Jozef,
Do you have any update?
Please send me your answer as soon as possible.
Keita
cyborgnegotiator do you have an advance?
jiri-b36968, vilemzavodny-b50857 could you help?
Jozef
Hi Keita/Jozef,
checked BootROM code. There is not anything which should cause the issue. WE35 can be longer in the case of multiplexed mode, but it is not the case. Maybe something in EIM controller itself. Asked designers to help with it.
/Jiri
Dear Jiri and Jozef,
Thank you for your reply.
Have you reproduced this problem?
I and my customer reproduces the problem on SABRE-AI and custom board.
Keita
jiri-b36968 can you add the status of this case?
Hi Keita,
The issue is registered as designers request in our system and designers are working on it. Their manager is also informed.
/Jiri