Re: actual kernel not compiling

[Paul M. <pau...@re...>]

On Mon, Nov 12, 2007 at 09:47:57AM +0100, Heiko Schocher wrote:
> Paul Mundt schrieb:
> > On Sun, Nov 11, 2007 at 12:22:13PM +0100, Heiko Schocher wrote:
> >> If I make a while (1); at the end of the function sh_cpu_init() in
> >> arch/sh/kernel/cpu/init.c the cpu dont restart, the next function
> >> called is start_kernel (). If I make there as first a while (1), the
> >> cpu restarts ... dont see an SH7750R specific thing in
> >> arch/sh/kernel/head.S on this place:
> >>
> > Sounds like something could be falling out as a result of the initial
> > cache flush in cache_init(), possibly due to things left over from your
> > boot loader. You might try playing with that a bit.
> 
> Hmm.. didnt enable the cache in the bootloader ...
> Hmm.. I have running code from a selfmade OS, with caches enabled. There
> I set the CCR_CACHE_ORA bit in the CCR register, as I see in the 
> cache_init()
> function, this bit is never set ... Doesnt Linux want this Bit to be set?
> 
No, Linux doesn't want this bit set, and presumably neither do you. We
used to have special casing for it, but its implementation varied too
widely on different CPU subtypes (especially with the transition from 2
to 4-way set associative dcaches) to make it easy to support.

The initial cache flush checks to see if the boot loader has set the ORA
bit, in which case the flush can be optimized, as there's only half of
the cache to flush. If you plan to use operand cache RAM mode under
linux, you will have to handle the cache halving commonly, and account
for the fact that the memory-mapped cache access varies depending on the
CPU subtype (different subtypes use different ways for RAM mode, with and
without EMODE).

Also if your bootloader is not setting the CCR enable bit, the initial
cache flush and subsequent ORA check should never be hit in the first
place.