When performing a burst transaction with the "plb_ddr_v1_00_b or plb_sdram_v1_00_c" cores, the PLB_MERR signal goes active. Why is this happening?
In these cores, a read burst (not a cacheline, but a true read burst transaction) that has addresses that cross row boundaries will return PLB_MERR. This occurs because the read burst implementation required that data be supplied each clock, and when row boundaries are crossed, a delay is incurred to activate the new row and so data can't be returned every clock.
Note that SDRAM memories have both row and column addresses. We require the row address bits to be stable during a burst.
This has been fixed in "plb_ddr_v1_00_c' (currently released in EDK 6.1) and "plb_sdram_v1_00_d" (will be released in EDK 6.1 SP2).
A temporary work-around for "plb_sdram_v1_00_c" would be to turn off burst/cacheline support (C_INCLUDE_BURST_CACHELN_SUPPORT = 0). This will convert all burst and cacheline transactions to single transactions and will, therefore, allow the crossing of row boundaries. Since "plb_ddr_v1_00_c" is available, no work-around is needed.
Note that the PPC405 DOES NOT perform burst transactions (only cachelines), so this is not a problem for code execution. The problem is seen when an OPB core using DMA is bursting data to the OPB through the OPB-PLB bridge. The OPB-PLB bridge has the capability of performing burst transactions. The alternate work-around would be to turn off burst support in the OPB-PLB bridge (C_RNGx_BURST where x = 0 -3 representing the different OPB2PLB Bridge address ranges).
The choice of which work-around to use depends on the use of the PLB SDRAM in the system. If being used for mostly code execution and the application is code intensive, it might be best to turn off burst support in the OPB2PLB Bridge so that the processor still has cacheline accesses to PLB SDRAM. If being used mostly for data storage, then it might be best to turn off burst support for that address range in the OPB2PLB bridge.