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

[Sughosh Ganu <urwithsughosh@gmail.com>]

On Mon Jan 30, 2012 at 10:03:40AM -0700, Tom Rini wrote:

> 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.

  I'm not sure about whether the V-bit functionality is disabled by
  some setting, but the omapl-138 ref manual states this(section 2.4
  "Exceptions and Exception Vectors").

" NOTE: The VINTH signal is configurable by way of the register
setting in CP15. However, it is not recommended to set VINTH = 0, as
the device has no physical memory in the 0000 0000h address region." 

-sughosh