On 10/20/2014 12:29 PM, Gedare Bloom wrote: > If you do the legwork now, they could make reasonable GCI tasks if we > decide to participate and are accepted. And in this case, by the time I did the legwork, I could fix them. The legwork is 97.5% of this. :)
Find the manual for the CPU, look up HID0. If the cache bits match, it is in block 1. Check caching against the other block. If a match, it is in block 2. If not a match, then it either doesn't have cache methods or you have to write code. And the last one is likely beyond GCI. :( --joel > -Gedare > > On Mon, Oct 20, 2014 at 1:20 PM, 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 >> >>> On Mon, Oct 20, 2014 at 11:19 AM, Joel Sherrill >>> <joel.sherr...@oarcorp.com> wrote: >>>> On 10/20/2014 10:08 AM, Sebastian Huber wrote: >>>>> On 20/10/14 16:58, Joel Sherrill wrote: >>>>>> On October 20, 2014 9:41:57 AM CDT, Sebastian Huber >>>>>> <sebastian.hu...@embedded-brains.de> wrote: >>>>>>> Since nobody missed the unimplemented cache manager functions in >>>>>>> several years >>>>>>> it should be safe so simply remove this #warning. >>>>>> You didn't notice it for qoriq or e500 so years is an exaggeration for >>>>>> some models. >>>>> The QorIQ BSP is from 2011. >>>>> >>>>>> Take a look at the BSPs impacted. I don't care particularly about older >>>>>> CPU models but some are recent and should be addressed. >>>>>> >>>>>> After that dropping the warning is OK by me. >>>>>> >>>>> The useful functions are implemented and in case someone really needs the >>>>> exotic ones he should notice it if the function is a simple "blr". >>>>> >>>> OK. I will just remove the warning. >>>> >>>> Do we want to add a PR or Open Project idea for this? >>>> >>>> -- >>>> Joel Sherrill, Ph.D. Director of Research & Development >>>> joel.sherr...@oarcorp.com On-Line Applications Research >>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>>> Support Available (256) 722-9985 >>>> >>>> _______________________________________________ >>>> devel mailing list >>>> devel@rtems.org >>>> http://lists.rtems.org/mailman/listinfo/devel >> -- >> Joel Sherrill, Ph.D. Director of Research & Development >> joel.sherr...@oarcorp.com On-Line Applications Research >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> Support Available (256) 722-9985 >> >> -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
