P1021 bug on eLBC Bus Access not solved with P1021CE Chip Errata REv. N 06/2017 eLBC-A001

[roberto_perez]

Good morning:

We are having problems like file corruptions that impact in startup as well as erroneous reading of data in NOR flash. The problems arise when there is an access to NAND flash (FCM mode) prior to an access to NOR flash (GPCM mode). Both memories share the eLBC bus but use different modes. The problem seems different to the one described in P1021CE Chip Errata REv. N 06/2017 eLBC-A001 since we apply the workaround without success. In fact if we stop applying this workaround a lot of new error arise in the startup.

We include a document describing all the tests carried out. I think the oscilloscope pictures (included in this document) describe very well the problem.

We are applying for some recommendations to avoid this problem.

Thank you and best regards

Roberto

[emptyempty]

Just to summarize:

In order to solve the error scenarios mentioned in points 1-b and 1-c, we must wait for the completion of each FCM command, which is done in the eLBC NAND driver, before we can request a GPCM transaction.

is that correct?

[ufedor]

Correct.

[ufedor]

Which software is used?

Please note:

1) When FCM transaction is in progress, sending GPCM transaction (either from core or DMA) may cause following issues:

a) It can cause bus monitor timeout, which is explained in eLBC-A001 erratum.
b) It can also cause termination of GPCM transaction if LFRB/LGTA signal is asserted (by NAND device) and if the instructions written in FIR sequence are not the ones which wait for LFRB de-assertion.

c) GPCM transaction may get timeout at system bus (CCB). In that case system bus timeout error would get generated.

2) When GPCM transaction is in progress triggering FCM transaction should not cause any issues because FCM waits for GPCM transaction to complete before initiating the FCM transaction.

To avoid error scenarios mentioned in point (1) it's always recommended to synchronize the GPCM-FCM operations at software level.

[emptyempty]

Hi ufedor, thanks for your response.

I have some doubts:

What do you exactly mean with the sentence “it's always recommended to synchronize the GPCM-FCM operations at software level”?

are you suggesting that, for all the drivers that access the eLBC bus, we must implement some kind of mutual exclusion lock?

Has NXP published a kernel patch to avoid the error scenarios mentioned in points 1-b and 1-c?

[ufedor]

> are you suggesting that, for all the drivers that access the eLBC bus,

> we must implement some kind of mutual exclusion lock?

It is possible to wait for completion of each FCM command which is done in the eLBC NAND driver:

linux/fsl_elbc_nand.c at linux-4.9 · qoriq-open-source/linux · GitHub 

[emptyempty]

So, if I understood, we must modify the eLBC NAND driver and implement a mechanism

to wait for completion of each FCM command and this will solve the error scenarios mentioned in point (1-b).

but, what´s about the error scenario mentioned in point (1-c)?

[ufedor]

> what´s about the error scenario mentioned in point (1-c)?

This scenario is not possible if FCM command is completed before a GPCM access initiation.