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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
