[U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.

[Tom Rini]

On Sun, Jan 29, 2012 at 6:36 AM, Christian Riesch
<christian.riesch at omicron.at> wrote:

> 3) As Sughosh pointed out, the current code changes the V bit
> (location of exceptions). Sughosh's patch removes this code that does
> this change.  I'm not sure if this is correct or not, so maybe you,
> Tom, could put your TI hat on again and clarify this?

OK, I've asked Christian for questions I can pass along, and here's
what's I've learned:

Q1) Currently, the low level initialization code for ARM926EJS CPUs in
the u-boot bootloader clears the V-bit of the cp15 control register
c1. By default, this bit is set on AM1808 and OMAP-L138 before u-boot
ist started. Sughosh Ganu now submitted a patch to remove the code
that clears the V bit because he states that these SoCs have no valid
memory region at 0x0. I had a look at the memory map of the AM1808 and
yes, there is no valid memory at 0x0, so the V bit should be set and
not cleared. My question is: Since the AM1808 has no valid memory at
0x0, does clearing the V bit have any effect on the operation of the
processor? Or is is just a don't care bit since it doesn't make any
sense to clear it?

A1) This may be a design question, but I can say that the default
value of the V-bit is set to 1 because of tie-offs to the core, but
I'm not sure if the functionality of the V-bit is still active.  I
would guess that it is because I see no reason we would have mucked
around in the ARM core design to remove that functionality, so unless
there is another tie-off to the core that disables the V-bit
functionality entirely, I would guess clearing the V-bit is not a good
idea.  In fact, I don't see why the u-boot init code needs to mess
with the default value of that bit ever, for any device or arch.

Q2) RBL: In an earlier post to the u-boot mailing list Tom Rini wrote
that the RBLs of AM1808 and OMAP-L138 do not turn on caches. Does this
mean that caches (dcache and/or icache) are *never* enabled or does it
mean that they get enabled and then disabled before RBL exits. In the
latter case, does RBL do everything that is necessary to ensure
consistency between data and instruction streams (as described in the
ARM926EJ-S Technical Reference Manual,
http://infocenter.arm.com/help/index.jsp, Section "Instruction Memory
Barrier.1. About the instruction memory barrier operation")? Are there
maybe earlier versions of RBL in earlier versions of the SoC that have
a bug here?

A2) The RBL NEVER enables the caches.  Unfortunately, this does slow
the operation of the ROM boot loader, but it is what is

-- 
Tom