[Top] [All Lists]

Re: Few questions about porting Linux to SMP86xx boards

To: Kevin Cernekee <>
Subject: Re: Few questions about porting Linux to SMP86xx boards
From: Måns Rullgård <>
Date: Tue, 03 Feb 2015 15:08:41 +0000
Cc: "Maciej W. Rozycki" <>, Oleg Kolosov <>, Linux MIPS Mailing List <>
In-reply-to: <> (Kevin Cernekee's message of "Tue, 3 Feb 2015 06:28:14 -0800")
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <>
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
Kevin Cernekee <> writes:

> On Tue, Feb 3, 2015 at 3:39 AM, Maciej W. Rozycki <> 
> wrote:
>>  For the record -- the exact address `__fast_iob' reads from does not
>> really matter, all it has to guarantee is no side effects on read access.
>> Using the base of KSEG1 was therefore a natural choice for legacy MIPS
>> processors that set the architecture back at the time this code was added,
>> as the presence of exception vectors there guaranteed this area of the
>> address space behaved like RAM so the same location did for any system.
>>  With the introduction of revision 2 of the MIPS architecture the CP0
>> EBase register was added and consequently there is no longer a guarantee
>> that exception vectors reside at the base of KSEG1.  Using the value read
>> from CP0.EBase to determine a usable address might therefore be a better
>> idea, although the current revision of the MIPS architecture specification
>> that includes segmentation control makes it a bit complicated.  Using a
>> dummy page mapped uncached instead might work the best.
> Would something like this work, assuming __fast_iob() doesn't get
> called before mem_init()?
> CKSEG1ADDR((void *)empty_zero_page)
> It is currently a GPL export, so maybe that would need to change to
> allow non-GPL drivers to use iob().  But that's still easier than
> allocating another dummy page.

The 86xx has a 64k remappable block at CPU physical address zero, so one
option would be to simply point this at some actual memory and leave the
macro alone.  There doesn't seem to be anything useful in that bus
address range anyway.  Reading returns zeros, and writes have no
apparent effect.  Maybe it's even safe to do a dummy read from there in

Måns Rullgård

<Prev in Thread] Current Thread [Next in Thread>