> On Oct 20, 2014, at 13:20 , Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > > On 10/20/2014 12:09 PM, Gedare Bloom wrote: >> Cache manager implementations are a perennial open project. > +1 > > In this case,we only have ten RTEMS_CPU_MODELs which are not > addressed. There are currently two blocks of code in the file. One > is protected by this: > > #if defined(ppc603) || defined(ppc603e) || defined(mpc8260) > > And the other by this: > > #elif ( defined(mpx8xx) || defined(mpc860) || defined(mpc821) ) > > My guess with no research is that the first block of code is also > appropriate for these RTEMS_CPU_MODELs: > > e500 > mpc604 > mpc7400 mpc7455 mpc750 > qoriq > mpc55xx > > A quick google makes me pretty confident that the mpc690 and mpc7* models > belong in the ppc603 HID0 block. > > I do not have a guess about these > > ppc405 ppc440 mpc555 > > If we have to implement code to support something new, then I don't want > to do it. If we have the code and just need to check to see if more needs to > be added to the conditional, then we should. > > --joel >
I'm not sure. I looked at this briefly today. The MPC55XX has a unified cache, a lot of the unimplemented entry points had to to do with operations specifically on either the instruction or data cache. I agree you could implement a unified method where accessing either would affect the other, but I also agree with Sebastian that I'm not sure it matters if someone is trying to use one of those for good reason. However, should unimplemented versions return an error instead of being a NOP? That would force one to visit code that makes assumptions. Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
