On Mon, 24 Aug 1998, Mark Brinicombe wrote:

> On Mon, 24 Aug 1998, Mike Pumford wrote:
> 
> > I a having problems booting a kernel built from sources supped on
> > 20/8/1998. The machine is a 200MHz StrangARM RiscPC with 48MB RAM and 2MB
> > VRAM which fails as follows.
> > 
> > init subsystems:stacks vectors undefined pmap panic: Branch to never-never land (zero)..... we're dead
> > 
> > boot: howto=00000100 curproc=f016e3e0
> > splmasks & ipl masks
> > 
> > If I enable ddb the panic tries to enter ddb but the kernel repeatedly
> > reports that the undefined instruction used to enter the debugger is 
> > undefined instead of entering ddb.
> Hi,
>   I have just noticed this problem. This appears to have been caused be a
> recent change somewhere (The last RPC kernel I built just over a week ago
> worked fine). I'm looking into the problem. It appears that for some
> currently unknown reason the return from pmap_bootstrap() is going via the
> reset vetor ;-(
> 
> Cheers,
> 				Mark
Hi,
  Ok I have just committed a fix for this problem... The problem was that
on a SA110 the data cache was losing sync with main memory after the
primary and secondary bootstraps due to the kernel address space being
moved around. This meant that after replacing the L1 pagetable in
initarm() the addresses used to clean the SA110 cache mapped to different
physical pages meaning that the act of changing the TTB put the entire
cache out of sync thus requiring an extra clean after the change.
The problem arose due to the removal of a data cache flush instruction
from setttb() so that setttb() can be called with interrupts enabled. This
is not normaly a problem as the kernel once booted the kernel does not
move around the virtual address space as it does during the bootstrap
relocation.

Neil: Do you remember be asking you what I had forgotten to do when I made
the interrupt changes to the cache cleaning code ? Now I know ...

Cheers,
				Mark