Re: Few questions about porting Linux to SMP86xx boards

[Oleg Kolosov <bazurbat@gmail.com>]

On 02/02/15 21:09, Måns Rullgård wrote:
> Kevin Cernekee <cernekee@chromium.org> writes:
> 
>> On Sun, Feb 1, 2015 at 2:46 PM, Oleg Kolosov <bazurbat@gmail.com> 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