linux-mips
[Top] [All Lists]

Re: Few questions about porting Linux to SMP86xx boards

To: Måns Rullgård <mans@mansr.com>
Subject: Re: Few questions about porting Linux to SMP86xx boards
From: Kevin Cernekee <cernekee@chromium.org>
Date: Tue, 3 Feb 2015 08:40:21 -0800
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>, Oleg Kolosov <bazurbat@gmail.com>, Linux MIPS Mailing List <linux-mips@linux-mips.org>, Jim Quinlan <jim2101024@gmail.com>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=SrkctTwalqwGYTjXBKpkOPEKVd1JyntR7EX7GVp4klc=; b=ogHw2rjKHqmbrlWz43o4/pZ8b7RdYbbuCgZriIReiHJA8zGrYD3s49y2pjnUoHp04g zN8LxZaJ0kpk8x7wle5OrRMUo9h4X81M079t1jiXzTiMOKqoLVj8EGBuR5aemR583KFX acXvRyU0IyNcgj3ibKJlJFfv/aj4pn5+Rm0R8=
In-reply-to: <yw1xsien9gna.fsf@unicorn.mansr.com>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <54CEACC1.1040701@gmail.com> <CAJiQ=7AQuP1JsiApEs4yAR449w6-pcR_qqhSqKdpqNHL5L1mRQ@mail.gmail.com> <yw1xwq409odv.fsf@unicorn.mansr.com> <54D017D4.70200@gmail.com> <alpine.LFD.2.11.1502030930000.22715@eddie.linux-mips.org> <CAJiQ=7DWiSEeBUiKCPZKn8fUwxUdOrCqMLDYFTaXSMTGsJCJOA@mail.gmail.com> <yw1xsien9gna.fsf@unicorn.mansr.com>
Sender: linux-mips-bounce@linux-mips.org
On Tue, Feb 3, 2015 at 7:08 AM, Måns Rullgård <mans@mansr.com> wrote:
> Kevin Cernekee <cernekee@chromium.org> writes:
>> On Tue, Feb 3, 2015 at 3:39 AM, Maciej W. Rozycki <macro@linux-mips.org> 
>> 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
> iob().

IIRC, one of the special operating modes on BCM7435 allows
partitioning the hardware in a way that prohibits accesses to PA 0.
Not sure how widely it is used, however.  I've also seen other
embedded MIPS systems that don't have RAM at PA 0, but they didn't run
Linux.

So there are two paths forward:

1) Make SMP86xx behave like other currently-supported CPUs, i.e. use
the remap registers to configure the chip so that uncached reads from
PA 0 do something sensible.  This sounds like the easiest fix.

2) Agree to support memory configurations where PA 0 doesn't map to
RAM, changing __fast_iob (and maybe other code) accordingly.

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