From: Ralf Baechle <ralf@linux-mips.org>
To: moreau francis <francis_moreau2000@yahoo.fr>
Cc: linux-mips@linux-mips.org
Subject: Re: Kernel located in KSEG2 or KSEG3.
Date: Wed, 15 Dec 2004 14:38:51 +0100 [thread overview]
Message-ID: <20041215133851.GD27935@linux-mips.org> (raw)
In-Reply-To: <20041213181252.23074.qmail@web25104.mail.ukl.yahoo.com>
On Mon, Dec 13, 2004 at 07:12:52PM +0100, moreau francis wrote:
> To learn on Linux kernel, I've decided to port it on
> particular board with (very) limited resources and
> based with a 4KC processor core. As far I see, I need
> at least a couple of mega bytes of memory to achieve
> my goal.
> Unfortunately the only way to get this amount of mem
> is
> to execute linux in memory that can only be accessed
> through KSEG2 and KSEG3 !
>
> Here is my board's mapping:
>
> Physical Memory Map:
>
> start size type
> -----------------------------
> 0x20000000 - 8MB - SDRAM
> 0x30000000 - 16MB - FLASH
> 0x40000000 - 16MB - FLASH
> 0x50000000 - 2MB - SRAM
>
>
> I looked into the memory init code and I don't think
> that it's possible to run linux in a segment different
> from KSEG0. Am I wrong ?
It's not. The 4kc processor when running with the BEV bit in the status
register cleared will try to find it's exception vectors at address
KSEG0, so there would have to be *some* code mapped there. With BEV=1
exception vectors would be located in the firmware as pointed out by
Steve in his answer. Firmware means something like flashmemory and running
uncached, so will be prohibitivly slow. I just can't believe a system to
be that missdesigned!
> I've noticed a CONFIG_MAPPED_KERNEL macro but it seems
> that it's only used to replicate kernel from mapped
> memory to KSEG0...
That's correct. CONFIG_MAPPED_KERNEL was written to support large ccNUMA
systems (large meaning two or three digit numbers of processors) where
preferably each node should run it's own copy of the OS kernel. It's
a missdesigned, therefore ineffective implementation that was also only
working because of some assumption on the way gcc generates tools.
Ralf
next prev parent reply other threads:[~2004-12-15 13:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-13 18:12 Kernel located in KSEG2 or KSEG3 moreau francis
2004-12-13 19:04 ` sjhill
2004-12-14 10:03 ` moreau francis
2004-12-15 13:38 ` Ralf Baechle [this message]
2004-12-16 15:05 ` moreau francis
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=20041215133851.GD27935@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=francis_moreau2000@yahoo.fr \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox