I would like some help on implementing some of the workarounds from AN3532 in Linux, with a secondary goal of getting these into the main Linux project

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

I would like some help on implementing some of the workarounds from AN3532 in Linux, with a secondary goal of getting these into the main Linux project

Jump to solution
1,556 Views
tonyvanderpeet
Contributor I

My company's products using PowerQUICC run on two different operating systems. The original code includes a number of the workarounds in AN3532 concerning Instruction Cache Parity Errors and others.

Our newer OS is based on Linux, and while I see that the kernel does include a few workarounds, these do not apply to the code for processors that we are running, and the code in the Linux kernel looks slightly different to what I would expect given the app note.

Specific questions:

  • Does the code introduced into Linux in 2010 directly relate to the application note AN3532?
    • (my own answer) Algorithm in the application note just invalidates one cache line, the Linux code flushes the entire instruction cache. The app note algorithm also covers another case - not sure if this is required if the whole cache is flushed?
  • Can we run this exact same code for the e500 case (the code in Linux is for e500mc)?
    • (my own answer) There seem to be slight differences in the way the flush case bit works for e500 and e500mc, so the code would have to be changed slightly.
  • Are there more up to date app notes relating to these issues?
    • (my own answer) Couldn't find any in the archives.
  • Are there existing patches that address these issues?
  • Is Freescale interested in getting some of these workarounds into the main Linux project?

The Linux change to which I refer is: powerpc/e500mc: Implement machine check handler. · fe04b11 · torvalds/linux · GitHub

Thanks

Tony

0 Kudos
1 Solution
1,385 Views
alexander_yakov
NXP Employee
NXP Employee

The errata CPU30, mentioned in the AN3532 appnote, is present only in rev 2.0 of the e500 core. This is quite old revision, it was used in old processors like MPC8541 mentioned in the tags of this topic.

Starting from core revision 3.0 (from MPC8572 processor), the errata CPU30 is not listed as present, so this means this is fixed in e500 core starting from revision 3.0

Regarding the machine check code - in case of machine check because of multibit error machine check handler may handle this error in different ways. The way, described in the errata is relatively complex - it requires cache inhibited region to place machine check handler and so on.

Invalidating whole cache is much easy and therefore more safe way. Of course, it takes more time, but assuming the procedure is not executed very frequently, I think performance impact may be ignored.

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
1 Reply
1,386 Views
alexander_yakov
NXP Employee
NXP Employee

The errata CPU30, mentioned in the AN3532 appnote, is present only in rev 2.0 of the e500 core. This is quite old revision, it was used in old processors like MPC8541 mentioned in the tags of this topic.

Starting from core revision 3.0 (from MPC8572 processor), the errata CPU30 is not listed as present, so this means this is fixed in e500 core starting from revision 3.0

Regarding the machine check code - in case of machine check because of multibit error machine check handler may handle this error in different ways. The way, described in the errata is relatively complex - it requires cache inhibited region to place machine check handler and so on.

Invalidating whole cache is much easy and therefore more safe way. Of course, it takes more time, but assuming the procedure is not executed very frequently, I think performance impact may be ignored.

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos