On Friday 13 January 2012 11:08 PM, 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<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.
It would have affected if the state of dirty bits and valid bits are
not guaranteed at reset. But looks like cache entries are guaranteed to
be invalidated on reset in ARM926ejs per the spec (which is not the
case in ARMv7). In this case, I agree that flush shouldn't harm
anything ideally.
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
I will be surprised too if D-cache is enabled by ROM code. But I agree
that your problem and the solution seems to indicate something like
that. To be sure can you check the value of CP15 System control
register on SPL entry? You are already reading it. Can you save it
somewhere and spit it out later?
this. But yes, like you mention, we must be cleaning the cache
before disabling it, so this fix is correct.
I think it will be good to add an invalidate of I-cache too. You have
replaced an invalidate of I & D cache with a flush of only D-cache.
br,
Aneesh
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
