[Top] [All Lists]

Few questions about porting Linux to SMP86xx boards

Subject: Few questions about porting Linux to SMP86xx boards
From: Oleg Kolosov <>
Date: Mon, 02 Feb 2015 01:46:25 +0300
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=gUDTWELGKiF/FX3bwIvXw5iQ42QflplFVN7O5kLl3Bs=; b=MsTpNMk3Z50CP4COZoxVJuYOIaSlfsxS9llNBa0XBWt5cO3INdwWIQpmgv9QqQoD/o W37qZyJZkCBhwGp5xFpGECEr2MemfO0rSu7icUq9CSp/n4wSZ0f0MgU8b/4+lxzYUEg3 53r9XA2m56ecEFtWcO9edhPgCq0c/OfyX3TD9PxlvYYW3EbZya0IXDg5SOdmCqEvyMvH GtMet56s+47PqzSdwPSEon240aZVvxNMWyKVdHAK9hWxbMwkf7/pW7FXY/FZxAENhi/7 FBMjKyHl92M+/XLFMWv5Ec6xO11J6EWQWetX+Q2ml1fkJYfwFq+MACZPMlFSt6v9WLZn DGcg==
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;
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
Hello MIPS gurus!

I'm adding support for Sigma Designs SMP8652/SMP8654 (Tango3 family,
MIPS 24kf CPU) to newer kernel. I've selectively adapted patches from (the latest officially available for us) to the latest mips
3.18 stable branch and things seem to work (it boots, runs simple test
programs), but there are few questions which I was not able to resolve
yet with my limited experience:

1. They (Sigma Designs) have overridden __fast_iob which is identical to
the default one except for one line:

    : "m" (*(int *)CKSEG1)

is replaced with:

    : "m" (*(int *)(CKSEG1+CPU_REMAP_SPACE))

where CPU_REMAP_SPACE=0x4000000 is a compile time constant for Tango3
and also called KERNEL_START_ADDRESS in Makefiles. The same value is
also written to ebase:


in traps.c:per_cpu_trap_init()

while writing ebase is really necessary for the kernel to boot, I've not
found any negative effects of not applying __fast_iob patch. What is it
supposed to do?

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?

3. In c-r4k.c:r4k_cache_init() they assign:

flush_icache_page = r4k_flush_icache_page;


static void r4k_flush_icache_page(struct vm_area_struct *vma,
                                  struct page *page)
    r4k_flush_icache_range((unsigned long)page_address(page),
        (unsigned long)page_address(page) + PAGE_SIZE);

thus overriding default empty flush_icache_page.

By digging the archives I've found some talks about removing
flush_icache_page. Various sources says it should not be necessary.
Maybe this is board-specific workaround?


I would really appreciate some explanations on what these changes
supposed to solve or pointers to some background info to better
understand what I'm actually doing. The main concern is that not
properly applying the changes might break something subtly, and, on the
contrary, applying everything might conflict with some fixes in newer
kernel and break something subtly - the sadness.

Thanks a lot!

Regards, Oleg
Art System

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