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
