Re: PowerPC Cache Warning Help Request
On Fri, Oct 24, 2014 at 1:36 AM, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 23/10/14 19:41, Gedare Bloom wrote: We might consider removing the cache manager in favor of making dcache flush/invalidate and icache invalidate lines part of the score/cpu port (are they the same across cpu's in the same arch family?) No, the caches are highly chip specific. OK. I just grepped and I don't see any CPU_cache being used from anywhere except bsp code. I suspect we should give this framework the axe, or reduce it drastically and move it into the BSP layer. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PowerPC Cache Warning Help Request
On October 23, 2014 1:52:47 AM PDT, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 21/10/14 04:56, Gedare Bloom wrote: On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufaultdufa...@hda.com wrote: On Oct 20, 2014, at 16:47 , Joel Sherrilljoel.sherr...@oarcorp.com wrote: However, should unimplemented versions return an error instead of being a NOP? That would force one to visit code that makes assumptions. If this is OK for the mpc55xx, feel free to submit a patch turning the warning off for it. I tend to agree that if I had a generic drive that wanted to flush data cache and all we can do on a target is flush all, then that's preferable to flushing nothing. If these are called from a cache test then we would end up with a hard error instead of a warning in that test which makes the issue worse. I'm flat-out, I can't do a proper job on this. I couldn't have told you that the MPC55XX had a unified cache before I checked this morning, but I would have gotten the answer correct on a multiple-choice question. I think that unimplemented operations should return errors and not OK, forcing one to add an implementation when it is OK. But the MPC55XX and its cache works fine as long as you keep cache-flushing in mind and flush it when you should, so I don't recommend anything be changed in the next RTEMS release. +1 What we should do is make sure any generic cache mgr functions that get called within RTEMS are all implemented (I recall there being some, they may be in score/cpu code though.) Then make the unimplemented calls be errors. If someone uses it without checking, they should get slapped for it. What do you mean with return errors? Should this be a fatal error or a linker error? Let's take the simplest case. A CPU with no cache control. Empty stubs is the right implementation. Next up is just enable, disable and flush. Can we map those to more specialized methods. Is it ok and expected that disable data cache does all? Or flush flushes all. My thinking is that there are probably tiers of cache capabilities and if we can define expected behavior of higher tier operations onto lower capability CPU models, then we have a good solution. I don't like any errors in this case because as Peter says the code works well enough for applications as is if it is being used. Injecting a fatal error would be breakage. Returning an error would (I think) take an API change which no code would look at. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PowerPC Cache Warning Help Request
On 23/10/14 15:16, Joel Sherrill wrote: On October 23, 2014 1:52:47 AM PDT, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 21/10/14 04:56, Gedare Bloom wrote: On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufaultdufa...@hda.com wrote: On Oct 20, 2014, at 16:47 , Joel Sherrilljoel.sherr...@oarcorp.com wrote: However, should unimplemented versions return an error instead of being a NOP? That would force one to visit code that makes assumptions. If this is OK for the mpc55xx, feel free to submit a patch turning the warning off for it. I tend to agree that if I had a generic drive that wanted to flush data cache and all we can do on a target is flush all, then that's preferable to flushing nothing. If these are called from a cache test then we would end up with a hard error instead of a warning in that test which makes the issue worse. I'm flat-out, I can't do a proper job on this. I couldn't have told you that the MPC55XX had a unified cache before I checked this morning, but I would have gotten the answer correct on a multiple-choice question. I think that unimplemented operations should return errors and not OK, forcing one to add an implementation when it is OK. But the MPC55XX and its cache works fine as long as you keep cache-flushing in mind and flush it when you should, so I don't recommend anything be changed in the next RTEMS release. +1 What we should do is make sure any generic cache mgr functions that get called within RTEMS are all implemented (I recall there being some, they may be in score/cpu code though.) Then make the unimplemented calls be errors. If someone uses it without checking, they should get slapped for it. What do you mean with return errors? Should this be a fatal error or a linker error? Let's take the simplest case. A CPU with no cache control. Empty stubs is the right implementation. Next up is just enable, disable and flush. Can we map those to more specialized methods. Is it ok and expected that disable data cache does all? Or flush flushes all. What is the use case for a cache disable/enable at application level? Most cache disable functions in the tree are broken. The only useful cache manager functions I see is data cache flush/invalidate lines and instruction cache invalidate lines. My thinking is that there are probably tiers of cache capabilities and if we can define expected behavior of higher tier operations onto lower capability CPU models, then we have a good solution. I don't like any errors in this case because as Peter says the code works well enough for applications as is if it is being used. Injecting a fatal error would be breakage. Returning an error would (I think) take an API change which no code would look at. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PowerPC Cache Warning Help Request
On October 23, 2014 6:38:27 AM PDT, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 23/10/14 15:16, Joel Sherrill wrote: On October 23, 2014 1:52:47 AM PDT, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 21/10/14 04:56, Gedare Bloom wrote: On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufaultdufa...@hda.com wrote: On Oct 20, 2014, at 16:47 , Joel Sherrilljoel.sherr...@oarcorp.com wrote: However, should unimplemented versions return an error instead of being a NOP? That would force one to visit code that makes assumptions. If this is OK for the mpc55xx, feel free to submit a patch turning the warning off for it. I tend to agree that if I had a generic drive that wanted to flush data cache and all we can do on a target is flush all, then that's preferable to flushing nothing. If these are called from a cache test then we would end up with a hard error instead of a warning in that test which makes the issue worse. I'm flat-out, I can't do a proper job on this. I couldn't have told you that the MPC55XX had a unified cache before I checked this morning, but I would have gotten the answer correct on a multiple-choice question. I think that unimplemented operations should return errors and not OK, forcing one to add an implementation when it is OK. But the MPC55XX and its cache works fine as long as you keep cache-flushing in mind and flush it when you should, so I don't recommend anything be changed in the next RTEMS release. +1 What we should do is make sure any generic cache mgr functions that get called within RTEMS are all implemented (I recall there being some, they may be in score/cpu code though.) Then make the unimplemented calls be errors. If someone uses it without checking, they should get slapped for it. What do you mean with return errors? Should this be a fatal error or a linker error? Let's take the simplest case. A CPU with no cache control. Empty stubs is the right implementation. Next up is just enable, disable and flush. Can we map those to more specialized methods. Is it ok and expected that disable data cache does all? Or flush flushes all. What is the use case for a cache disable/enable at application level? Most cache disable functions in the tree are broken. The only useful cache manager functions I see is data cache flush/invalidate lines and instruction cache invalidate lines. Personally I don't see enable and disable used besides during BSP initialization. Maybe disable when app starts if having trouble with a user provided driver. But much beyond that My thinking is that there are probably tiers of cache capabilities and if we can define expected behavior of higher tier operations onto lower capability CPU models, then we have a good solution. I don't like any errors in this case because as Peter says the code works well enough for applications as is if it is being used. Injecting a fatal error would be breakage. Returning an error would (I think) take an API change which no code would look at. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PowerPC Cache Warning Help Request
On Oct 23, 2014, at 09:38 , Sebastian Huber sebastian.hu...@embedded-brains.de wrote: What do you mean with return errors? Should this be a fatal error or a linker error? Let's take the simplest case. A CPU with no cache control. Empty stubs is the right implementation. Next up is just enable, disable and flush. Can we map those to more specialized methods. Is it ok and expected that disable data cache does all? Or flush flushes all. What is the use case for a cache disable/enable at application level? Most cache disable functions in the tree are broken. The only useful cache manager functions I see is data cache flush/invalidate lines and instruction cache invalidate lines. My original thinking about return errors is to return an error code when an unimplemented function is called, because somebody called that function for what they thought was a good reason. A link-time warning (not error) if the function is linked-in to the user application would be great, I don't know if that is possible. That approach moves the warning from the BSP compilation stage to the conscious usage of an unusual unimplemented function by a BSP user. I don't know what the use cases of all those cache manager functions are. The few real-world unusual cache usages that I can think of are chip and application specific (e.g. reserve a section of cache as a section to store some critical code in) and I wouldn't even attempt to generalize them for use in a manager. My desirements would be, in order and if possible: - Link time warning when an unimplemented function is called from an application; - Run-time error return (not fatal abort type thing, but something the application should handle) when an unimplemented function is called; - Nothing at all. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PowerPC Cache Warning Help Request
We might consider removing the cache manager in favor of making dcache flush/invalidate and icache invalidate lines part of the score/cpu port (are they the same across cpu's in the same arch family?) -Gedare On Thu, Oct 23, 2014 at 12:10 PM, Peter Dufault dufa...@hda.com wrote: On Oct 23, 2014, at 09:38 , Sebastian Huber sebastian.hu...@embedded-brains.de wrote: What do you mean with return errors? Should this be a fatal error or a linker error? Let's take the simplest case. A CPU with no cache control. Empty stubs is the right implementation. Next up is just enable, disable and flush. Can we map those to more specialized methods. Is it ok and expected that disable data cache does all? Or flush flushes all. What is the use case for a cache disable/enable at application level? Most cache disable functions in the tree are broken. The only useful cache manager functions I see is data cache flush/invalidate lines and instruction cache invalidate lines. My original thinking about return errors is to return an error code when an unimplemented function is called, because somebody called that function for what they thought was a good reason. A link-time warning (not error) if the function is linked-in to the user application would be great, I don't know if that is possible. That approach moves the warning from the BSP compilation stage to the conscious usage of an unusual unimplemented function by a BSP user. I don't know what the use cases of all those cache manager functions are. The few real-world unusual cache usages that I can think of are chip and application specific (e.g. reserve a section of cache as a section to store some critical code in) and I wouldn't even attempt to generalize them for use in a manager. My desirements would be, in order and if possible: - Link time warning when an unimplemented function is called from an application; - Run-time error return (not fatal abort type thing, but something the application should handle) when an unimplemented function is called; - Nothing at all. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PowerPC Cache Warning Help Request
On 23/10/14 19:41, Gedare Bloom wrote: We might consider removing the cache manager in favor of making dcache flush/invalidate and icache invalidate lines part of the score/cpu port (are they the same across cpu's in the same arch family?) No, the caches are highly chip specific. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PowerPC Cache Warning Help Request
Cache manager implementations are a perennial open project. 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.comOn-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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PowerPC Cache Warning Help Request
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.comOn-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.comOn-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
Re: PowerPC Cache Warning Help Request
If you do the legwork now, they could make reasonable GCI tasks if we decide to participate and are accepted. -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.comOn-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.comOn-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
Re: PowerPC Cache Warning Help Request
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
Re: PowerPC Cache Warning Help Request
On Oct 20, 2014, at 16:47 , Joel Sherrill joel.sherr...@oarcorp.com wrote: However, should unimplemented versions return an error instead of being a NOP? That would force one to visit code that makes assumptions. If this is OK for the mpc55xx, feel free to submit a patch turning the warning off for it. I tend to agree that if I had a generic drive that wanted to flush data cache and all we can do on a target is flush all, then that's preferable to flushing nothing. If these are called from a cache test then we would end up with a hard error instead of a warning in that test which makes the issue worse. I'm flat-out, I can't do a proper job on this. I couldn't have told you that the MPC55XX had a unified cache before I checked this morning, but I would have gotten the answer correct on a multiple-choice question. I think that unimplemented operations should return errors and not OK, forcing one to add an implementation when it is OK. But the MPC55XX and its cache works fine as long as you keep cache-flushing in mind and flush it when you should, so I don't recommend anything be changed in the next RTEMS release. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PowerPC Cache Warning Help Request
On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufault dufa...@hda.com wrote: On Oct 20, 2014, at 16:47 , Joel Sherrill joel.sherr...@oarcorp.com wrote: However, should unimplemented versions return an error instead of being a NOP? That would force one to visit code that makes assumptions. If this is OK for the mpc55xx, feel free to submit a patch turning the warning off for it. I tend to agree that if I had a generic drive that wanted to flush data cache and all we can do on a target is flush all, then that's preferable to flushing nothing. If these are called from a cache test then we would end up with a hard error instead of a warning in that test which makes the issue worse. I'm flat-out, I can't do a proper job on this. I couldn't have told you that the MPC55XX had a unified cache before I checked this morning, but I would have gotten the answer correct on a multiple-choice question. I think that unimplemented operations should return errors and not OK, forcing one to add an implementation when it is OK. But the MPC55XX and its cache works fine as long as you keep cache-flushing in mind and flush it when you should, so I don't recommend anything be changed in the next RTEMS release. +1 What we should do is make sure any generic cache mgr functions that get called within RTEMS are all implemented (I recall there being some, they may be in score/cpu code though.) Then make the unimplemented calls be errors. If someone uses it without checking, they should get slapped for it. -Gedare Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
