From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Sun, 15 Jan 2012 09:13:47 +0100 Subject: [U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it. In-Reply-To: <20120113173821.GC4482@Hardy> References: <1326133550-6706-1-git-send-email-urwithsughosh@gmail.com> <1326219136-1953-1-git-send-email-urwithsughosh@gmail.com> <20120113082618.GA1557@Hardy> <4F104DD9.2080308@denx.de> <20120113173821.GC4482@Hardy> Message-ID: <4F128ABB.7060901@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Sughosh, Sughosh Ganu wrote: > hi Heiko, > > On Fri Jan 13, 2012 at 04:29:29PM +0100, Heiko Schocher wrote: >> Hello Sugosh, >> >> Sughosh Ganu wrote: >>> hi Christian, >>> >>> On Fri Jan 13, 2012 at 09:06:26AM +0100, Christian Riesch wrote: >>>> Hi Sughosh, >>>> I had a look at the patch and I tried to understand what's going on >>>> here (I must confess that I didn't know anything about this cache >>>> stuff). >>> Ok, thanks for taking time off to understand this issue. >>> >>>> On Tue, Jan 10, 2012 at 7:12 PM, Sughosh Ganu wrote: >>>>> The current implementation invalidates the cache instead of flushing >>>>> it. This causes problems on platforms where the spl/u-boot is already >>>>> loaded to the RAM, with caches enabled by a first stage bootloader. >> Hmm.. how did u-boot work on such boards? How can u-boot work with D-Cache >> enabled, if u-boot is not initializing it? (And I think, on davinci SoC >> we have a none working uboot ethernet driver if d-cache is enabled too). >> There must be a page_table in DRAM for using D-Cache in U-Boot, if u-boot >> don't initialize it, it maybe overrides it ... or miss I something? > > Well, there is some data in the cache, which if not flushed creates > problems on my board. I get the board to boot just by commenting out > cpu_init_crit call. My hypothesis that the D-cache is enabled is That is what I not understand, because, if the RBL really enables the D-Cache, how could u-boot work, if it not disables it! > simply because cache invalidation followed by cache disabling breaks > the board, while flushing it prior to disabling gets it to boot > fine. This(invalidation) would not have been a problem if the cache > was in the disabled state. > >> Are you sure, the RBL enables the D-Cache on your board? Nevertheless, >> I think, we must disable the D-Cache here with "cleaning" it (as your >> patch did) instead only invalidating it, as current code did. > > I am not sure, this is just my guess. By default, the caches are > disabled on reset, so the only possible source is the rbl. But I > don't have access to the rbl code to say for sure. Unfortunately i > also don't have JTAG or any other debugger to dig more into :-( You maybe could read the interesting values, and store them some- where, and print it later? > this. But yes, like you mention, we must be cleaning the cache > before disabling it, so this fix is correct. Yes, the fix is correct, but we should try to understand, what is really the problem on your hw! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany