From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Jan 2008 16:35:47 +0000 (GMT) Received: from wa-out-1112.google.com ([209.85.146.182]:15128 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20032276AbYAHQfi (ORCPT ); Tue, 8 Jan 2008 16:35:38 +0000 Received: by wa-out-1112.google.com with SMTP id m16so12130548waf.20 for ; Tue, 08 Jan 2008 08:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:mime-version:content-type:x-mailer:thread-index:x-mimeole:message-id; bh=PELyFxm5PzJ8bpyBey4ewQLTaqF2L2dyzKngfH4i5zU=; b=oVwHwUOqHnHvqilEYPPCFAJp8Gwy60Ll+Im5Q7jDJoFrfXIRl9tgV1rEqUwUWygglYrTKdR0NBQ/CutRLXR5oE1BTn636XbRDKtww+iT12I9LZDmoWrdWCup6juqEvuvVaYk83IVTSkn0oU8KPwg/9h80Gg+xVxi+JBfHTjFurc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:mime-version:content-type:x-mailer:thread-index:x-mimeole:message-id; b=Zzi7Mhr9JczG7ahWmPXq13c/C0Zjzg91sCcSg9RW2RHenNBdAUsBG8ohyLRpf/IaF6Me4abT0VkNGYWU5n2R2kmKDbjgLxTEzatv5WhimpWBAKhfbMPph2fGhrj0Cv8Zllszpfsvfsh/fGsdz4DspRHt/w1VHXKkvVrZZbnOa3k= Received: by 10.115.74.1 with SMTP id b1mr455677wal.93.1199810131289; Tue, 08 Jan 2008 08:35:31 -0800 (PST) Received: from WWW8E1E968C4DF ( [124.78.172.63]) by mx.google.com with ESMTPS id m28sm33925040poh.7.2008.01.08.08.35.29 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Jan 2008 08:35:30 -0800 (PST) From: "lovecentry" To: Subject: kseg1 uncache access issue Date: Wed, 9 Jan 2008 00:35:06 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C85257.7C6BA180" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AchSFGznFIKi14IwSXqLn9eejUkhaA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Message-ID: <4783a652.1cef600a.2530.fffffe31@mx.google.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17954 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lovecentry@gmail.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C85257.7C6BA180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi As we know in mips achitecture if current pc falls into kseg1 segment, any memory reference will bypass cache and fetch directly from dram. But for some prcoessor such like mips R10K it has off chip L2 cache. I haven't found any available path which can access dram directly. All memory reference need pass through L2 cache. Does it mean any memory reference in kseg1 will be fetch from L2 cache rather than dram for such system? How does such system design when system software need access kseg1 region? Further more, Kseg2 is used to do memory map for those peripheral so Is there has a particular circuit that routes those access to the appropriate destination. Any suggestion is highly appreciate!!! Tony ------=_NextPart_000_0004_01C85257.7C6BA180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi<= /span>

As we know in = mips achitecture if current pc falls into kseg1 segment, any memory reference = will bypass cache and fetch directly from dram. But for some prcoessor such = like mips R10K it has off chip L2 cache. I haven't found any available path = which can access dram directly. All memory reference need pass through L2 = cache. Does it mean any memory reference in kseg1 will be fetch from L2 cache rather = than dram for such system? How does such system design when system software = need access kseg1 region? Further more, Kseg2 is used to do memory map for = those peripheral so Is there has a particular circuit that routes those access to the = appropriate destination.

Any = suggestion is highly appreciate!!!

Tony

------=_NextPart_000_0004_01C85257.7C6BA180-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Jan 2008 17:03:44 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:3811 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20032498AbYAHRDf (ORCPT ); Tue, 8 Jan 2008 17:03:35 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1JCHrR-000468-00; Tue, 08 Jan 2008 18:03:33 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 62A5AC2F21; Tue, 8 Jan 2008 18:02:06 +0100 (CET) Date: Tue, 8 Jan 2008 18:02:06 +0100 To: lovecentry Cc: linux-mips@linux-mips.org Subject: Re: kseg1 uncache access issue Message-ID: <20080108170206.GA8777@alpha.franken.de> References: <4783a652.1cef600a.2530.fffffe31@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4783a652.1cef600a.2530.fffffe31@mx.google.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17955 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips On Wed, Jan 09, 2008 at 12:35:06AM +0800, lovecentry wrote: > As we know in mips achitecture if current pc falls into kseg1 segment, any > memory reference will bypass cache and fetch directly from dram. But for > some prcoessor such like mips R10K it has off chip L2 cache. I haven't found why do you think so ? R10k L2 cache controller is inside CPU and any access with uncached attribute will go directly to memory. The only systems, where this might be different are systems with caches unknown to the cpu. But even those usually obey that uncached accesses are going directly to memory. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Jan 2008 18:59:12 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:62621 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20033046AbYAHS7K (ORCPT ); Tue, 8 Jan 2008 18:59:10 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id m08Ix3qP024035; Tue, 8 Jan 2008 18:59:03 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id m08Ix3Aw024034; Tue, 8 Jan 2008 18:59:03 GMT Date: Tue, 8 Jan 2008 18:59:03 +0000 From: Ralf Baechle To: Thomas Bogendoerfer Cc: lovecentry , linux-mips@linux-mips.org Subject: Re: kseg1 uncache access issue Message-ID: <20080108185903.GC30643@linux-mips.org> References: <4783a652.1cef600a.2530.fffffe31@mx.google.com> <20080108170206.GA8777@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080108170206.GA8777@alpha.franken.de> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17956 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Jan 08, 2008 at 06:02:06PM +0100, Thomas Bogendoerfer wrote: > On Wed, Jan 09, 2008 at 12:35:06AM +0800, lovecentry wrote: > > As we know in mips achitecture if current pc falls into kseg1 segment, any > > memory reference will bypass cache and fetch directly from dram. But for > > some prcoessor such like mips R10K it has off chip L2 cache. I haven't found > > why do you think so ? R10k L2 cache controller is inside CPU and any > access with uncached attribute will go directly to memory. The only > systems, where this might be different are systems with caches unknown > to the cpu. But even those usually obey that uncached accesses are > going directly to memory. It should also be mentioned that some R10000 machines do odd stuff with uncached addresses. IP27 class machines reuse the entire physical address space several times to map different things. The selection of the four uncached address spaces id done by the uncached attribute which is specified either in the TLB or or as as bit 59..60 of a virtual address in XKPHYS. The memory controller of the Indigo 2 R10000 needs to be switched to a special slower mode to allow uncached accesses first. Ralf From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Jan 2008 13:20:58 +0000 (GMT) Received: from rv-out-0910.google.com ([209.85.198.189]:54689 "EHLO rv-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20027159AbYAINUt convert rfc822-to-8bit (ORCPT ); Wed, 9 Jan 2008 13:20:49 +0000 Received: by rv-out-0910.google.com with SMTP id l15so207089rvb.24 for ; Wed, 09 Jan 2008 05:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:in-reply-to:x-mimeole:message-id; bh=V+JzzzEek+/DjBHUQE3kvJRBoXnwXf5JiYv/bjZH1WE=; b=UX7kgTBnF7JLvMHpDW7JyojlfFAP6yxC2s1cVUEkJ2sey7XsXfXxjsPnFRBWZ8s8eoH6ZHDBbQZ9VkeNN+jDWQtK/z4Cr+WpGAjmZKyo40gcn5yJCmpvGIEyDT8WDd0S8fLC5R/32yjb/mjt7CX8XqT5kJ5ZJA09u8jBcOgGF4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:in-reply-to:x-mimeole:message-id; b=PZsX1HAuQZceRSm2NCEj3I8O4v1WV/ox3OZKXGQbyk3E4Ckye9PJ8IiZdqUh6mlpvYghWCCymUbHpYh/5ZmeVaoFlWCxhvaejAqfDRtmMh1u7eBcz/RUCt04Zj4UTptdWNzbrUV5xzeiMCFpskjCMHzNl5vdXX98pEdmCWjGLBU= Received: by 10.140.136.1 with SMTP id j1mr382261rvd.233.1199884840544; Wed, 09 Jan 2008 05:20:40 -0800 (PST) Received: from WWW8E1E968C4DF ( [124.78.166.39]) by mx.google.com with ESMTPS id g6sm2073119rvb.25.2008.01.09.05.20.37 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Jan 2008 05:20:40 -0800 (PST) From: "lovecentry" To: "'Ralf Baechle'" , "'Thomas Bogendoerfer'" Cc: Subject: =?gb2312?B?tPC4tDoga3NlZzEgdW5jYWNoZSBhY2Nlc3MgaXNzdWU=?= Date: Wed, 9 Jan 2008 21:20:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8BIT X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AchSKI7rL0sXndvHR1mocjxvBlInKgAmcRGQ In-Reply-To: <20080108185903.GC30643@linux-mips.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Message-ID: <4784ca28.06538c0a.5e01.10f5@mx.google.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17961 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lovecentry@gmail.com Precedence: bulk X-list: linux-mips Hi gents Thanks for your reply. Now I try to implement MIPS R10000 microprcoessor simulation with C language, so many issues still puzzle me although I have read MIPS R10000 Microprocessor paper introduced by Yeager 1996 more than ten times since last year. As Thomas said, R10K will access directly to dram for those uncached load/store operations. Which path in the MIPS R10k makes it available? Is system interface does that stuff? I found it has uncached buffer. Another issue arises, as system brings up the PC will be assigned to 0xbfc00000 and it need to fetch instructions from dram directly rather than dram then put first four instructions into decode/remap unit, but from the MIPS R10000 diagram decode/remap unit only get instructions from ICACHE. How MIPS R10000 handle this case? Tony -----邮件原件----- 发件人: Ralf Baechle [mailto:ralf@linux-mips.org] 发送时间: 2008年1月9日 2:59 收件人: Thomas Bogendoerfer 抄送: lovecentry; linux-mips@linux-mips.org 主题: Re: kseg1 uncache access issue On Tue, Jan 08, 2008 at 06:02:06PM +0100, Thomas Bogendoerfer wrote: > On Wed, Jan 09, 2008 at 12:35:06AM +0800, lovecentry wrote: > > As we know in mips achitecture if current pc falls into kseg1 segment, any > > memory reference will bypass cache and fetch directly from dram. But for > > some prcoessor such like mips R10K it has off chip L2 cache. I haven't found > > why do you think so ? R10k L2 cache controller is inside CPU and any > access with uncached attribute will go directly to memory. The only > systems, where this might be different are systems with caches unknown > to the cpu. But even those usually obey that uncached accesses are > going directly to memory. It should also be mentioned that some R10000 machines do odd stuff with uncached addresses. IP27 class machines reuse the entire physical address space several times to map different things. The selection of the four uncached address spaces id done by the uncached attribute which is specified either in the TLB or or as as bit 59..60 of a virtual address in XKPHYS. The memory controller of the Indigo 2 R10000 needs to be switched to a special slower mode to allow uncached accesses first. Ralf From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wa-out-1112.google.com ([209.85.146.182]:15128 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20032276AbYAHQfi (ORCPT ); Tue, 8 Jan 2008 16:35:38 +0000 Received: by wa-out-1112.google.com with SMTP id m16so12130548waf.20 for ; Tue, 08 Jan 2008 08:35:37 -0800 (PST) From: "lovecentry" Subject: kseg1 uncache access issue Date: Wed, 9 Jan 2008 00:35:06 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C85257.7C6BA180" Message-ID: <4783a652.1cef600a.2530.fffffe31@mx.google.com> Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org To: linux-mips@linux-mips.org Message-ID: <20080108163506.Q3Uxt8afbtK6WJ8MdpGXf5h3br5wNjmyhRptnn-8p3w@z> This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C85257.7C6BA180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi As we know in mips achitecture if current pc falls into kseg1 segment, any memory reference will bypass cache and fetch directly from dram. But for some prcoessor such like mips R10K it has off chip L2 cache. I haven't found any available path which can access dram directly. All memory reference need pass through L2 cache. Does it mean any memory reference in kseg1 will be fetch from L2 cache rather than dram for such system? How does such system design when system software need access kseg1 region? Further more, Kseg2 is used to do memory map for those peripheral so Is there has a particular circuit that routes those access to the appropriate destination. Any suggestion is highly appreciate!!! Tony ------=_NextPart_000_0004_01C85257.7C6BA180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi<= /span>

Any = suggestion is highly appreciate!!!

Tony

------=_NextPart_000_0004_01C85257.7C6BA180-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rv-out-0910.google.com ([209.85.198.189]:54689 "EHLO rv-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20027159AbYAINUt convert rfc822-to-8bit (ORCPT ); Wed, 9 Jan 2008 13:20:49 +0000 Received: by rv-out-0910.google.com with SMTP id l15so207089rvb.24 for ; Wed, 09 Jan 2008 05:20:40 -0800 (PST) From: "lovecentry" Subject: =?gb2312?B?tPC4tDoga3NlZzEgdW5jYWNoZSBhY2Nlc3MgaXNzdWU=?= Date: Wed, 9 Jan 2008 21:20:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8BIT In-Reply-To: <20080108185903.GC30643@linux-mips.org> Message-ID: <4784ca28.06538c0a.5e01.10f5@mx.google.com> Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org To: 'Ralf Baechle' , 'Thomas Bogendoerfer' Cc: linux-mips@linux-mips.org Message-ID: <20080109132011.VNniBqf_aWqh1EpLcH2V-OEMK6PQh4tyh97NSJCi6YM@z> Hi gents Thanks for your reply. Now I try to implement MIPS R10000 microprcoessor simulation with C language, so many issues still puzzle me although I have read MIPS R10000 Microprocessor paper introduced by Yeager 1996 more than ten times since last year. As Thomas said, R10K will access directly to dram for those uncached load/store operations. Which path in the MIPS R10k makes it available? Is system interface does that stuff? I found it has uncached buffer. Another issue arises, as system brings up the PC will be assigned to 0xbfc00000 and it need to fetch instructions from dram directly rather than dram then put first four instructions into decode/remap unit, but from the MIPS R10000 diagram decode/remap unit only get instructions from ICACHE. How MIPS R10000 handle this case? Tony -----邮件原件----- 发件人: Ralf Baechle [mailto:ralf@linux-mips.org] 发送时间: 2008年1月9日 2:59 收件人: Thomas Bogendoerfer 抄送: lovecentry; linux-mips@linux-mips.org 主题: Re: kseg1 uncache access issue On Tue, Jan 08, 2008 at 06:02:06PM +0100, Thomas Bogendoerfer wrote: > On Wed, Jan 09, 2008 at 12:35:06AM +0800, lovecentry wrote: > > As we know in mips achitecture if current pc falls into kseg1 segment, any > > memory reference will bypass cache and fetch directly from dram. But for > > some prcoessor such like mips R10K it has off chip L2 cache. I haven't found > > why do you think so ? R10k L2 cache controller is inside CPU and any > access with uncached attribute will go directly to memory. The only > systems, where this might be different are systems with caches unknown > to the cpu. But even those usually obey that uncached accesses are > going directly to memory. It should also be mentioned that some R10000 machines do odd stuff with uncached addresses. IP27 class machines reuse the entire physical address space several times to map different things. The selection of the four uncached address spaces id done by the uncached attribute which is specified either in the TLB or or as as bit 59..60 of a virtual address in XKPHYS. The memory controller of the Indigo 2 R10000 needs to be switched to a special slower mode to allow uncached accesses first. Ralf