On Tue, Aug 19, 2014 at 10:00:34AM +0200, Ralf Baechle wrote: > On Mon, Aug 18, 2014 at 10:55:02PM -0400, Joshua Kinard wrote: > > > --- a/arch/mips/include/asm/mach-ip28/spaces.h > > +++ b/arch/mips/include/asm/mach-ip28/spaces.h > > @@ -18,7 +18,7 @@ > > #define PHYS_OFFSET _AC(0x20000000, UL) > > > > #define UNCAC_BASE _AC(0xc0000000, UL) /* 0xa0000000 + PHYS_OFFSET */ > > -#define IO_BASE UNCAC_BASE > > +#define IO_BASE _AC(0x9000000000000000, UL) > > > > #include <asm/mach-generic/spaces.h> > > I think the real culprit is not the definition of IO_BASE but of > UNCAC_BASE. 0xc0000000UL is KSEG2 for a 32 bit kernel - but for a 64 bit > kernel UNCAC_BASE should be defined as _AC(0x9000000000000000, UL). that was my first thought as well. I just wondered whether it's necessary to reflect PHY_OFFSET != 0... nevertheless UNCAC_BASE is not usuable for memory access on IP28 at all. At least not without poking at the memory controller for slower access cycles, which the current kernel avoids totaly. > Which are the defaults in <asm/mach-generic/spaces.h> so just deleting > both UNCAC_BASE and IO_BASE from mach-ip28/spaces.h should fix things? I'll give a spin later. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]
