| To: | Chad Reese <kreese@caviumnetworks.com>, linux-mips@linux-mips.org |
|---|---|
| Subject: | Re: [PATCH 11/36] MIPSR2 ebase isn't just CAC_BASE |
| From: | Brian Foster <brian.foster@innova-card.com> |
| Date: | Wed, 29 Oct 2008 08:38:01 +0100 |
| Cc: | "Maciej W. Rozycki" <macro@linux-mips.org>, Ralf Baechle <ralf@linux-mips.org>, David Daney <ddaney@caviumnetworks.com>, Tomaso Paoletti <tpaoletti@caviumnetworks.com> |
| Dkim-signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:sender; bh=7wH9VwzxdHDuwBOA2sclJh5R+Bn59EpeTeL7CDqQZQg=; b=LQHSR23gPpMBBLx3wE7kZ1JrpjkIcyIeT7SFDTINkfHduSGx7Cj8mPdH8JKHJ6Lero fQTV40tKyKD0tmosEJhD87qcnRU5uoWCCbR05XU3iaIgfYtMoavyQIDTtI/8oiohq6mC 7Ee/UmEdnRtR/4RFXJjYPqBhrXYt4ZLhiUDQk= |
| Domainkey-signature: | a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=GkVRwHuAnX1cSnfMcJfYhFOc35oOeTs46hUQbrD2Xa+ygvqCnrFj9yssl5oWqYebI2 x+Vyxtgy4sxvAQRepRv52k+MLjoi4hupDoWUbx91oyORu0MoT/cYPzPWuz2K72X567Xk bFGwuzZX2TASKgoTsmaFxUc6/V8LKuPr32U3E= |
| In-reply-to: | <49073A38.3070808@caviumnetworks.com> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <1225152181-3221-2-git-send-email-ddaney@caviumnetworks.com> <alpine.LFD.1.10.0810281604250.27396@ftp.linux-mips.org> <49073A38.3070808@caviumnetworks.com> |
| Reply-to: | Brian Foster <brian.foster@innova-card.com> |
| Sender: | linux-mips-bounce@linux-mips.org |
| User-agent: | KMail/1.9.6 (enterprise 0.20070907.709405) |
On Tuesday 28 October 2008 17:13:44 Chad Reese wrote:
> Maciej W. Rozycki wrote:
> > On Tue, 28 Oct 2008, Ralf Baechle wrote:
> >> Another thing I noticed is that we don't use write_c0_ebase(), so the
> >> firmware better setup this correctly or we crash and burn. We better
> >> should initialize that right ...
> >
> > Well, your version still does not do it...
>
> From an Octeon perspective, we'd prefer that the kernel not touch ebase
> as we set it in the bootloader. The bootloader sets the proper value
> based on the number of kernels being loaded and which cores the kernel
> is loaded on. This allows some interesting things, like running 16
> kernels each on a different CPU. Although 16 kernels is just a toy
> project, we have a number of customers that run two kernels. They choose
> which cores the kernels run on dynamically at boot time.
Our system (4KSd-based) also has the bootloader setting EBASE,
so like Chad, I'd prefer it if the kernel doesn't (always?) do
it, please. (We're not doing anything tricky like what Chad
mentions, it's just that on the SoC in question, it's perhaps
the easiest way of handling the situation.)
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
|
| Previous by Date: | Re: [PATCH 02/36] Add Cavium OCTEON files to arch/mips/include/asm/mach-cavium-octeon, Ralf Baechle |
|---|---|
| Next by Date: | Re: [PATCH 15/36] Probe for Cavium OCTEON CPUs., Ralf Baechle |
| Previous by Thread: | Re: [PATCH 11/36] MIPSR2 ebase isn't just CAC_BASE, Maciej W. Rozycki |
| Next by Thread: | Re: [PATCH 11/36] MIPSR2 ebase isn't just CAC_BASE, Ralf Baechle |
| Indexes: | [Date] [Thread] [Top] [All Lists] |