Thanks James. That was useful. Sagar On Fri, Sep 9, 2016 at 7:50 AM, James Hogan <james.hogan@xxxxxxxxxx> wrote: > On Fri, Sep 09, 2016 at 06:17:13AM -0700, Sagar Borikar wrote: >> Thanks James. >> >> On Fri, Sep 9, 2016 at 5:36 AM, James Hogan <james.hogan@xxxxxxxxxx> wrote: >> > Hi Sagar, >> > >> > On Thu, Sep 08, 2016 at 08:33:57PM -0700, Sagar Borikar wrote: >> >> Hello, >> >> >> >> I am upgrading kernel for a MIPS Interaptive CPU from 3.10.60 to >> >> 3.14.10 (stable) from: >> >> https://www.linux-mips.org/wiki/Malta_Linux_Repository >> > >> > Unfortunately that wiki page needs updating. >> > >> > If you're upgrading anyway, I think we'd recommend switching all the way >> > to a recent mainline kernel release / stable branch, e.g. 4.4 (LTS) or >> > 4.7 (and maybe update to 4.9 (LTS) when it is released or when 4.7 goes >> > EOL). I think all the stuff you'll need for interAptiv should be in >> > mainline now anyway. >> >> I see. We generally upgrade to malta repo as its maintained by mips >> (imgtec). I presume you are referring to kernel.org. I think linux-mti >> is having 4.1.7 as stable, right? > > Yeh I was referring to kernel.org. 3.14 was the last linux-mti branch. > A lot of stuff in mti-3.10 got upstreamed (with a lot of changes and > clean ups made along the way), and I think as a result mti-3.14 was > mostly backported patches from mainline. That may explain this > regression. > > We're now trying to focus a lot more on mainline (although we have > engineering branches in that same linux-mti repository, which are more > for supporting new architecture features & new cores before they've > found their way into mainline). > >> >> The platform has non-contiguous low memory and high memory. After the >> >> upgrade, highmem is not getting enabled due to max_low_pfn and >> >> highend_pfn not being the same. >> >> >> >> The commit cce335ae47e231398269fb05fa48e0e9cbf289e0 introduced the >> >> change apparently for sibyte platform. That change doesn't hold good >> >> for all platforms where the high memory and low memory is sparsed. >> >> >> >> If I comment out only following change in arch/mips/mm/init.c, highmem >> >> gets initialized properly. >> >> >> >> 296 if (cpu_has_dc_aliases && max_low_pfn != highend_pfn) { >> >> 297 printk(KERN_WARNING "This processor doesn't support highmem." >> >> 298 " %ldk highmem ignored\n", >> >> 299 (highend_pfn - max_low_pfn) << (PAGE_SHIFT - 10)); >> >> 300 max_zone_pfns[ZONE_HIGHMEM] = max_low_pfn; >> >> 301 lastpfn = max_low_pfn; >> >> 302 } >> > >> > I don't think we ever supported DCache aliasing + highmem in >> > combination. >> >> Interesting. We are currently running 3.10.60 and apparently it seems >> to work. Are you saying it may cause any issues? So far we haven't >> seen any problems. What kind of issues it might end up into? > > Sorry, I was thinking of mainline. > > Mti-3.10 seems to have had changes which didn't make it upstream which > would have made this possible, from which commit 15de36a4c3cf > ("mm/highmem: make kmap cache coloring aware") was derived (which was > merged for v3.17, in August 2014). There were attempts to add the MIPS > support after this, but none of them made it upstream: > > https://patchwork.linux-mips.org/project/linux-mips/list/?state=*&q=fixes+for+cache+aliasing > >> >> > >> > If you want to use that memory your options are probably: >> > - increase the page size to avoid dcache aliasing. >> >> Ok thanks. I would need to experiment with this but I am bit baffled >> how its working in 3.10.60. >> Generally, is there any reference platforms based on interaptiv which >> uses highmem and dcache aliasing? I might have missed but couldn't >> find any platform which comes close in both trees. > > Its probably possible to configure malta in such a way (4k pages, big > cache, alias removal disabled in hardware, highmem). > >> >> > - OR use EVA to increase the size of lowmem, which at the moment is a >> > bit more involved. How much RAM do you have, and what does your >> > physical memory map look like? >> >> Total memory is 2GB. memory map looks like this: >> >> low mem(~66MB) : >> >> * 0x04300000 +-----------------+ >> * | Linux | >> * 0x00043000 +-----------------+ >> >> high mem (128MB): >> >> * 0x28000000 +-----------------+ >> * | linuxhi | >> * 0x20000000 +-----------------+ >> >> Rest of the blocks are reserved. > > It should be possible to use EVA to expand lowmem to cover these two > regions. Fitting in the whole 2GB would probably be a little trickier > depending on other stuff (how much IO memory is needed, IOCU in use, > etc). > > Cheers > James
