From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Mon, 21 Apr 2008 19:08:14 -0400 Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers In-Reply-To: <20080421221925.E6FD924764@gemini.denx.de> References: <20080421221925.E6FD924764@gemini.denx.de> Message-ID: <200804211908.15526.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Monday 21 April 2008, Wolfgang Denk wrote: > In message <200804211658.44036.vapier@gentoo.org> you wrote: > > > I tried understanding what you are trying to do, and even though I > > > feel it's not exactly an important or frequently used feature for > > > most of the users I tried to come up with a compromize that allows > > > you to do what you want to do without hurting others and without > > > polluting the command name space. > > > > i consider the cache one aspect of it. the users shouldnt have to know > > "oh i gotta turn off cache", they just have to know "i'm loading up my > > code and > > I agree that cache is just one aspect; I disagree that users > shouldn't know what they are doing. On contrary, I want to give them > all necessary control to do what they may want to do. It is a matter > of higher software levels to provide more convenient abstractions. yes, but the fact that we have to turn off caches is not for performance reasons. users should not need to be aware of these system deficiencies which is why i'm proposing a "noret" flag. > > it's going to take over the system". that is why a "-noret" flags makes > > Who says that *my* application which doesn;t return does the same as > your application? Maybe I *want* to have the caches on for perfor- > mance? i'm not concerned with the performance aspect. caches on the Blackfin are intertwined with protection, and protection handlers require a software vector to process exceptions. the act of executing a program that takes over the system means the exception handler is no longer reliable so i have to guarantee it wont be called. based on information given to me from our hardware team, this can only be accomplished implicitly by disabling caches. > I accept that the default settings may be not optimal for your use > case, so please accept that your settings may not be always optimal, > either. As a solution I imagine options to the "go" command. If you > consider this too complicated for your users, please feel free to > provide an alias in an envrionment variable which your users can > "run". i completely accept that the patch i posted to turn off caches for all things to "go" result in a suboptimal environment for standalone u-boot applications. for Blackfin usage though, that takes a back seat to things silently crashing. > > applications (while useful) dont really matter. such applications rely > > on u-boot remaining resident which is the opposite of what i'm talking > > about. > > But then it doesn't hurt, does it? Your application can do anything it > wants as long as it does not attempt to return to U-Boot. except that it may inadvertently do so on Blackfin. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/4e200f81/attachment.pgp