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