RE: 2.6.28 will not boot on 24K processor, ebase incorrectly modified in set_uncached_handler

["David VomLehn (dvomlehn)" <dvomlehn@cisco.com>]

> From: Kevin D. Kissell [mailto:kevink@paralogos.com] 
> Sent: Sunday, January 25, 2009 2:18 AM
> To: David VomLehn (dvomlehn)
> Cc: linux-mips@linux-mips.org; Dezhong Diao (dediao); Victor 
> Williams Jr (williavi); Michael Sundius -X (msundius - Yoh 
> Services LLC at Cisco)
> Subject: Re: 2.6.28 will not boot on 24K processor, ebase 
> incorrectly modified in set_uncached_handler
> 
> David VomLehn (dvomlehn) wrote:
> > The 2.6.28 kernel dies in memcpy when called from 
> set_vi_srs_handler on
> > a
> > 24K processor. The problem is that ebase has an invalid value. The
> > original
> > value of ebase comes from a bootmem allocation, but the 
> following code
> > in
> > set_uncached_handler takes a perfectly good kseg0 address 
> and turns it
> > into
> > an invalid kseg1 address.
> >
> >     if (cpu_has_mips_r2)
> >             ebase += (read_c0_ebase() & 0x3ffff000);
> >
> > This code was added in commit 
> 566f74f6b2f8b85d5b8d6caaf97e5672cecd3e3e.
> >   
> I remember worrying about why it was "+=" and not "=" when others had 
> problems with that patch. See the thread "NXP STB225 board 
> support" from 
> January 8 or so.  When I asked about that, I got a comment 
> that the add 
> operation was correct, but that patch *should* have said 
> "uncached_ebase 
> += (read_c0_ebase() & 0x3ffff000);"  I guess uncache_ebase is 
> assumed to 
> contain something interesting in some non-address bits. Try 
> pre-pending 
> "uncached_" to that "ebase"...

Just adding uncached_ to the ebase doesn't appear to work. Looking at
the git
log makes it a bit unclear as to exactly who made this change, but it
would
be helpful to know what was intended.