From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eugene Surovegin Date: Sun, 30 Jan 2005 02:26:15 -0800 Subject: [U-Boot-Users] MIPS build environment In-Reply-To: <20050130091359.A2B2EC108D@atlas.denx.de> References: <20050130014351.GB24482@gate.ebshome.net> <20050130091359.A2B2EC108D@atlas.denx.de> Message-ID: <20050130102615.GC24482@gate.ebshome.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sun, Jan 30, 2005 at 10:13:54AM +0100, Wolfgang Denk wrote: > > Anyway, my comment still stands, this is bogus and cannot work for 4kc > > at least. The only reason INCA-IP port works is because memory is > > really initialized before stack is accessed. > > Please feel free to submit a patch. Unfortunately, it's not that simple :). This is one of those rare cases when bug might have become a "feature". Let me explain. Comment about setting up a temporary stack is obviously incorrect, but there is side effect of this cache locking (probably unintentional). Dcache is never get _unlocked_ after we copied U-Boot into the RAM. This effectively _disables_ dcache, because it's highly unlikely that we will use those addresses again during normal operation. This in turn makes cache-coherency (4kc is non-cache coherent core) a non-issue, making drivers simpler. When I first discovered this "cache-locking-for-temporary-stack" inconsistency, my first attempt was to remove cache locking altogether, and it even worked, although I haven't done extensive testing. Then I started thinking about side effect I just described and I wasn't quite sure that just removing this was safe. This is the main reason I haven't submitted patch in the first place, because I didn't have time to audit all the code for the cache-coherency problems.