On Mon, Jan 16, 2012 at 11:46 PM, Sughosh Ganu <urwithsugh...@gmail.com> wrote: > On Mon Jan 16, 2012 at 10:57:05AM -0700, Tom Rini wrote: >> On Fri, Jan 13, 2012 at 10:38 AM, Sughosh Ganu <urwithsugh...@gmail.com> >> 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 >> >> >> <urwithsugh...@gmail.com> 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 >> > 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. >> >> Putting my TI hat on, I've confirmed with the RBL folks that they >> aren't turning on ICACHE/DCACHE. > > Well, i'm not sure then why does the cache invalidation cause a > problem on my platform. Btw, will this patch be > accepted. Irrespective of the cache state on my board, it is not a > wrong fix, and moreover results in the booting of my board. > > I haven't yet tried out reading the cache bit state in the spl. Will > try out this experiment in a day or two, and share the results.
I think someone needs to look over this init code very carefully. If I can summarize from memory quickly, when we enable the CP_CRITICAL_INITS code for everyone that exposed a problem on the hawkboard that _looks_like_ DCACHE is enabled by RBL as changing the code from doing an invalidate to a flush+invalidate fixes a problem. But the manual says we should be doing flush+invalidate anyhow and the RBL code is not turning on DCACHE. Maybe we've got something else being done not as the manual says and that's tickling another issue? -- Tom _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
