On Sun, Oct 26, 2008 at 06:33:44PM -0700, Chad Reese wrote:
> >> -#ifdef CONFIG_64BIT
> >> +#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_CAVIUM_OCTEON)
> >> + /*
> >> + * Note: We always set ST0_KX on Octeon since IO addresses are at
> >> + * 64bit addresses. Keep in mind this also moves the TLB handler.
> >> + */
> >> setup_c0_status ST0_KX 0
> > That's a bit odd - on 64-bit kernels KX would be set anyway and on 32-bit
> > kernels would be corrupted by exceptions or interrupts, so 64-bit
> > addresses are not safe to use on 32-bit kernels for most part.
> > 32-bit virtual addresses mapped to a non-compat address otoh will work fine
> > without KX set.
> > Ralf
> The Octeon IO space regions are significantly larger than a 32bit kernel
> could tlb map easily. The entire range takes 49 bits to address. As a
> not particularly clean, but working alternative, we enable 64bit
> addressing in the kernel and used XKPHYS to access IO. Every access was
> surrounded by a local_irq_save/local_irq_restore. Since this is ugly to
> the extreme, maybe we should drop being able to boot a 32bit kernel on
> Octeon until something better is worked out.
That address space may be huge but for any given application you're
probably only ever going to access a tiny fraction of it - in particular
one where the kernel model of choice is a 32-bit kernel.
If these assumptions don't hold for the Cavium, then I ditching 32-bit
kernels is the obvious choice. We've given up on 32-bit kernels for the
SGI O2 for example - it was just too ugly, too painful. For very small
configurations of SGI Origins it would have been possible similarly for
small Broadcom Sibyte configs - but in practice these days we use 64-bit
kernels. 32-bit is just so yesterday and the 64-bit Linux/MIPS kernels
are now nearly a decade old.