[Top] [All Lists]

Re: Few questions about porting Linux to SMP86xx boards

To: Måns Rullgård <>, Kevin Cernekee <>
Subject: Re: Few questions about porting Linux to SMP86xx boards
From: Oleg Kolosov <>
Date: Tue, 03 Feb 2015 03:35:32 +0300
Cc: Linux MIPS Mailing List <>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bKc6N3CPBz0mlQFM4LaguUEjct5campmmH5ot4GuTTE=; b=m2jrLmglMssmOOc2LA8SZdBm3wVEerTLaybRPDNr/VlZKidlOg8JAGqt6BZsurnqXo Ggxfi97hizY7Sq65spdUnPRTj9zsXBDuZG9QDC0pA86xjKEOfcfu4u5jwWtVOZMa1ZNc DoJTMZHetf7PFplrCw14yCfH2K+ylMZCqWGFrwCXpR8AGrhefZmT9zFOqHfQNgTbnbkt MD49g+G/7+kS95mdHU40XWfUoWjj31Qy4d7ezJPpDH6sXqHE5luwS7SbOVGlwkewO1yW kC0sT4065SsytBQrTZiKsL5F/dp9b+Z/0AGctO+5MO2nxWyzFeusZL4quuM5oTojavDs 8Cxg==
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Organization: Art System
Original-recipient: rfc822;
References: <> <> <>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
On 02/02/15 21:09, Måns Rullgård wrote:
> Kevin Cernekee <> writes:
>> On Sun, Feb 1, 2015 at 2:46 PM, Oleg Kolosov <> wrote:
>>> 1. They (Sigma Designs) have overridden __fast_iob which is identical to
>>> the default one except for one line:
>>> ...
>> I do not have any direct experience with these SoCs, but you might
>> want to look at the memory map to try to figure this one out.  i.e. if
>> __fast_iob() normally performs an uncached dummy read from the first
>> word of physical memory, does the address need to be adjusted by 64MB
>> on the Sigma chips because system memory (or the memory allocated to
>> the Linux application processor) starts at PA 0x0400_0000 instead of
>> 0x0000_0000?
>> That theory would also explain why the exception vectors were adjusted
>> by the same offset.
> The 86xx has two DRAM controllers mapped with 1GB windows at 0x8000_0000
> and 0xc000_0000, and also with 256MB windows at 0x1000_0000 and 0x2000_0000.
> To complicate matters, CPU physical addresses starting at 0x04000000 are
> subjected to a set of remapping registers translating 6 blocks of 64MB
> to an arbitrary (64MB-aligned) bus address (not that these addresses
> overlap with the low mappings of the DRAM controllers).  The obvious way
> to support this would be to simply set these registers to an identity
> mapping and use highmem for anything that doesn't fit the low windows.
> Obviously, they didn't do that.

Thanks for the explanations! This is really useful.

>> BTW, you can override ebase from the platform code, as was done in
>> arch/mips/kernel/smp-bmips.c.  It probably isn't necessary to change
>> the common per_cpu_trap_init() code (but it may have been necessary
>> way back in 2.6.32).
> Most of the hacks they've done to generic code are actually completely
> unnecessary, if not outright wrong.

That was my suspicion as well. It is reassuring to have a confirmation
from someone more knowledgeable. Thanks!

>>> 2. In io.h they have added explicit __sync() to the end of
>>> pfx##write##bwlq and pfx##out##bwlq##p. Is this really necessary? I've
>>> not yet found any adverse effects of not doing so. Maybe this was a
>>> workaround for some old kernel issue which was fixed since then?
>> Adding a barrier in writel(), as was done on ARM, might have something
>> to do with the SoC's busing or peripherals.  Sometimes there are chip
>> bugs that cause MMIO transaction ordering to break in unexpected ways.
>> Or it could be there to compensate for missing barriers or bad
>> assumptions in a driver somewhere.
>> For #2 and #3, it is likely that somebody at Sigma could find a bug
>> report or changelog explaining why it was added.  In my experience
>> these sorts of changes are usually made to work around subtle problems
>> discovered in testing or production.  Figuring out the exact problem
>> that inspired the patch can be difficult without insider knowledge,
>> unless you happened to run across the same failure.
> I suspect the Sigma patches were produced by randomly prodding a kernel
> with a stick until it started working.

Regards, Oleg
Art System

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