RE: [U-Boot-Users] MPC83xx data cache lock?

What is the [non-existent] write performance? Can you tell me?
In message 9FCDBA58F226D911B202000BDBAD4673026FD90F@zch01exm40.ap.freescale.net you wrote:
MPC83xx data cache locked all ways in u-boot. This means data cache looks like cache-inhibit. when kernel run at this u-boot, kernel don't unlock data cache, so the data cache actually run at inhibited state. I suggest we need unlock data cache after re locate_code in start.S file.
Can you please retrict your line legth to the usual 70 characters or so? Thanks.
If unlock data cache in start.S file, we need change everything, such as BATs settings and DDR ECC test code. I have found some bugs in ECC test code.
Ummm.... Can you please be a bit more specific? I'm definitely interested in details. Did you find any way to improve the [non-existent] write performance?
------_=_NextPart_001_01C67E43.D555AAE4 Content-Type: text/html Content-Transfer-Encoding: base64
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW 9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF
...
And please, don't post HTML, especially not encoded as base64 which is a double PITA.
Best regards,
Wolfgang Denk

In message 9FCDBA58F226D911B202000BDBAD4673026FD910@zch01exm40.ap.freescale.net you wrote:
What is the [non-existent] write performance? Can you tell me?
Just measue the time it takes to initialize ECC memory either using the cache or DMA methods; here is a short summary (don't complain - you asked for it!):
----- quote begin -----
1. Read vs. write performance
Writing to DDR memory is *much* slower than reading it.
ECC off read duration: 509 ms write duration: 1546 ms
ECC on read duration: 509 ms write duration: 5703 ms
There's no clear indication in both DDR (8349) docs and Micron specification of our module on if and how read vs. write operations differ in timing. There is one pointer for the ECC case, which suggests writes can take three stages (full read-modify-write cycle) instead of just one:
"9.5.4 SDRAM Interface Timing - If ECC is disabled, writes smaller than double words are performed by appropriately activating the data mask. If ECC is enabled, the controller performs a read-modify write."
The problem is we see 3x difference when the ECC is off, and 10x when on. We also did a series of tests with various chunk sizes of data written, so as to be sure we do not do the indicated sub-double word writes, but the results were the same.
This is really strange, although at least read operations are not affected by enabling ECC (which is according to the book - there should be minimal overhead put on read operations while ECC on, see 3. below).
2. DMA (low) performance
Using DMA for transfers proves very inefficient. As mentioned earlier, the DMA module in 8349 is different than seen in other families, and it occured to us a bit "alien" when compared with the rest of the chip (DMA documentation part is rather limited, and different in style etc.), as if taken from elsewhere. It is also peculiar in technical aspects: endianness used is different, so we need to convert the order explicitly in s/w.
We tried increasing the local bus clocking but to no avail.
Given that low performance it doesn't make much difference whether ECC is enabled or not:
DMA, ECC on ddr init duration: 6947 ms
DMA, ECC off ddr init duration: 6721 ms
There seems something broken with the DMA operations in general as they are way slower than just plain read/write to memory, which is somehow confirmed by your recent communication from the customer.
3. ECC penalty
As can be seen in results given in 1. enabling ECC puts a huge burden on write access, which is contrary to 8349 UM:
p. 9-27 (above figure 9-24) "When ECC is enabled, one clock cycle is added to the read path to check ECC and correct single-bit errors. ECC generation does not add a cycle to the write path."
----- quote begin -----
Can you explain why writing to ECC memory is 10 times slower than reading?
In message 9FCDBA58F226D911B202000BDBAD4673026FD90F@zch01exm40.ap.freescale.net you wrote:
MPC83xx data cache locked all ways in u-boot. This means data cache looks like cache-inhibit. when kernel run at this u-boot, kernel don't
[Full quote deleted]
Please learn to quote! See http://www.netmeister.org/news/learn2quote.html
Best regards,
Wolfgang Denk
participants (2)
-
Liu Dave-r63238
-
Wolfgang Denk