From: Oleg Kolosov <bazurbat@gmail.com>
To: linux-mips@linux-mips.org
Subject: Few questions about porting Linux to SMP86xx boards
Date: Mon, 02 Feb 2015 01:46:25 +0300 [thread overview]
Message-ID: <54CEACC1.1040701@gmail.com> (raw)
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
2.6.32.15 (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:
ebase = KSEG0ADDR(CPU_REMAP_SPACE);
write_c0_ebase(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;
where:
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
next reply other threads:[~2015-02-01 22:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-01 22:46 Oleg Kolosov [this message]
2015-02-01 23:55 ` Few questions about porting Linux to SMP86xx boards Kevin Cernekee
2015-02-02 18:09 ` Måns Rullgård
2015-02-03 0:35 ` Oleg Kolosov
2015-02-03 11:39 ` Maciej W. Rozycki
2015-02-03 14:28 ` Kevin Cernekee
2015-02-03 15:08 ` Måns Rullgård
2015-02-03 16:40 ` Kevin Cernekee
2015-02-05 13:37 ` Maciej W. Rozycki
2015-02-02 15:19 ` Steven J. Hill
2015-02-02 15:19 ` Steven J. Hill
2015-02-02 17:56 ` Måns Rullgård
2015-02-02 17:56 ` Måns Rullgård
2015-02-03 0:17 ` Oleg Kolosov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54CEACC1.1040701@gmail.com \
--to=bazurbat@gmail.com \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.