1 of 1 people found this helpful
If I understand what you want to do correcty .... (and I haven't done this and don't know of anyone who has, but it would be an interesting thing to try).
- You want to use the MPBT bit for non-MPB data. The reason you want to do this is so that you bypass L2 and then can use the CLIFLUSHMB instruction to flush L1 of that data.
- You don't actually want to have off-chip memory actually serve as the MPB.One area of research is to define an MPB in off-chip memory to see how much improvement the on-chip MPB gives; but this is not your goal.
I think the reason you wan to use MPBT data is to avoid L2 issues.
One possibility would be to just disable L2 (Table 9 in the EAS). Then, you could flush L1 with WBINVD. But with MPBT data you bypass L2 (L2 is not disabled) ... it is just not used for MPBT data.
I suspect one of the reasons you want to do this (in addition to just investigating how the chip oeprates) is because you have had difficulty realiably flushing L2. We have for some time promised an L2-flush routine and have not yet delivered. We do now have confidence in the cacheable shared memory driver that was described in last week's post; a Linux with this driver is available on our public SVN. We do believe that the description of how L2 operates that we posted on this site is correct, and so it should be possible to write a realiable L2 flush routine. And we still will provide that as soon as possible.
Yes, you are right.
I was trying to avoid L2.
It would be great if you provide reliable L2 flush routine.
By the way, I'm curious this scheme has no problem or not.
Could you give any explanation of this?
Is it work correctly with off-chip memory?