Hi Sughosh,
On Thursday 19 January 2012 12:23 PM, Sughosh Ganu wrote:
On Tue Jan 17, 2012 at 08:27:58AM -0700, Tom Rini wrote:
On Mon, Jan 16, 2012 at 11:46 PM, Sughosh Ganu<urwithsugh...@gmail.com> wrote:
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?
Tried a few things on my end.
* Read the D-cache value in the spl, and confirmed that the data
cache is indeed not enabled.
What is the value of the B bit in CP15 SCR register? I wonder if RBL is
doing all the IMB operations required after copying the SPL image and
before executing it. IMB is required for consistency between data and
instruction sides. For instance after copying the SPL, the memory and
instruction cache could be incoherent. So, instruction cache needs to
be invalidated. In fact more needs to be done and there is an entire
chapter in the ARM926EJS TRM that discusses this (Chapter 9 -
Instruction Memory Barrier). Here is the key excerpt:
9.2 IMB operation
To ensure consistency between data and instruction sides, you must take
the following
steps:
1. Clean the DCache
2. Drain the write buffer
3. Synchronize data and instruction streams in level two AHB subsystems
4. Invalidate the ICache on page 9-4
5. Flush the prefetch buffer on page 9-4.
Ideally RBL should be doing all this before jumping to SPL. But, I
wonder if anything is missing in RBL and was getting done as a
side-effect of your flush.
Just a thought. Do you care to try 2-5 in SPL and see if it makes any
difference?(and avoid 1. in fact 1 seems to be the least useful thing
in our case!)
* Enabled the data cache explicitly in cpu_init_crit, and booted
u-boot. u-boot comes up fine, and trying a ping switches off the
data cache with the warning message.
How are you enabling D-cache. Please note that just setting C bit
doesn't enable D-cache. MMU needs to be enabled (M bit) for D-cache to
be enabled. MMU in turn needs page-table. I wonder if you are doing all
this in cpu_init_crit()?
br,
Aneesh
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
