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

[Christian Riesch]

Hi Tom,

On Mon, Jan 30, 2012 at 6:03 PM, Tom Rini <tom.rini at gmail.com> wrote:
> 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:

Thanks a lot!

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

Ok. So this should not be cleared, at least not for davinci.

> 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

I think this ends our speculations about RBL causing the hawkboard
problems. We will need someone with a hawkboard and a JTAG debugger to
find out more...

For now I think we should make these changes:
1) correct the comments
2) replace invalidating the cache with flushing the cache since this
is the way to do it according to the ARM manual (Sughosh's patch)
3) do not clear the V bit on DA850 SoCs
4) revert Heiko's patch that changes the behavior of
CONFIG_SKIP_LOWLEVEL_INIT and add a possibility to remove this option
on boards that need lowlevel config
2) respect CONFIG_SYS_ICACHE_OFF

I prepared a patchset that also includes Sughosh's patches and have
just submitted it (The people on Cc received it twice, sorry for
this...).

Regards, Christian