From owner-freebsd-mips@FreeBSD.ORG Mon Mar 15 00:23:44 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8644106564A for ; Mon, 15 Mar 2010 00:23:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9EBE78FC0A for ; Mon, 15 Mar 2010 00:23:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o2F0IpdD099269 for ; Sun, 14 Mar 2010 18:18:51 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 14 Mar 2010 18:19:02 -0600 (MDT) Message-Id: <20100314.181902.67053632336017068.imp@bsdimp.com> To: mips@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Request for review: AR71XX config cleanup X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 00:23:45 -0000 Greetings, I've done a quick stab at cleaning up the AR71XX config file. The problem with it is that isn't for the AR71XX, but really for the RouterStation Pro for Ubiquiti. Every time I build my normal ROUTER-STATION board, I forget to put the hints back and it won't boot. So, I've created a std.ar71xx. This is the standard config file for all ar71xx boards. You can then specialize it to reflect the population of your specific board. I've also separated the hints that are relevant to the Atheros SoC from those that are relevant only to a specific board. There's a std.ar71xx.hints. The patches for this are at http://people.freebsd.org/~imp/ar71xx-config.diff to illustrate all the details. In general, I think this looks like a good design pattern for phasing out DEFAULTS on the other architectures as well. But before I expand it to them, I'd like to get the mipsy world hammered out. Comments? Warner From owner-freebsd-mips@FreeBSD.ORG Mon Mar 15 09:46:30 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AFB7106564A for ; Mon, 15 Mar 2010 09:46:30 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 034C88FC0A for ; Mon, 15 Mar 2010 09:46:29 +0000 (UTC) Received: by bwz8 with SMTP id 8so2732971bwz.3 for ; Mon, 15 Mar 2010 02:46:29 -0700 (PDT) Received: by 10.204.3.10 with SMTP id 10mr776267bkl.35.1268644752810; Mon, 15 Mar 2010 02:19:12 -0700 (PDT) Received: from localhost (219-136-94-178.pool.ukrtel.net [178.94.136.219]) by mx.google.com with ESMTPS id 15sm2628794bwz.0.2010.03.15.02.19.09 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Mar 2010 02:19:10 -0700 (PDT) Date: Mon, 15 Mar 2010 11:17:56 +0200 From: Alex RAY To: "M. Warner Losh" Message-Id: <20100315111756.05fd5805.ray@ddteam.net> In-Reply-To: <20100314.181902.67053632336017068.imp@bsdimp.com> References: <20100314.181902.67053632336017068.imp@bsdimp.com> Organization: DDTeam.net X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mips@freebsd.org Subject: Re: Request for review: AR71XX config cleanup X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 09:46:30 -0000 On Sun, 14 Mar 2010 18:19:02 -0600 (MDT) "M. Warner Losh" wrote: > Greetings, > > I've done a quick stab at cleaning up the AR71XX config file. The > problem with it is that isn't for the AR71XX, but really for the > RouterStation Pro for Ubiquiti. Every time I build my normal > ROUTER-STATION board, I forget to put the hints back and it won't > boot. > > So, I've created a std.ar71xx. This is the standard config file for > all ar71xx boards. You can then specialize it to reflect the > population of your specific board. I've also separated the hints that > are relevant to the Atheros SoC from those that are relevant only to a > specific board. There's a std.ar71xx.hints. > > The patches for this are at > http://people.freebsd.org/~imp/ar71xx-config.diff to illustrate all > the details. > > In general, I think this looks like a good design pattern for phasing > out DEFAULTS on the other architectures as well. But before I expand > it to them, I'd like to get the mipsy world hammered out. > > Comments? > > Warner > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" Hi Warner, Maybe umass and SCSI modules relocate from the std files to config files? -- Alex RAY From owner-freebsd-mips@FreeBSD.ORG Mon Mar 15 12:26:42 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24FBF106566C for ; Mon, 15 Mar 2010 12:26:42 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yw0-f204.google.com (mail-yw0-f204.google.com [209.85.211.204]) by mx1.freebsd.org (Postfix) with ESMTP id CEA778FC1B for ; Mon, 15 Mar 2010 12:26:41 +0000 (UTC) Received: by ywh42 with SMTP id 42so1527223ywh.7 for ; Mon, 15 Mar 2010 05:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=zeAuZeMS/8+fMDcs3oU1oeYT9PiFyXjn1d4UQ/OZQug=; b=nX/BInyjOh277eGXRd2knSfdDfs1wQnewguKKOx1racT4zkLEUPhVkdM409iAC/WLx o3bgFc2wezzEoEF9okKkDJTteZM+LENwlAKKoGUJkNg65FPrGp9u5lsxfW/f7GepjcK0 qsU87sM5/3NhdL8aF8JtFdVA14/PA3iuue3Dk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=euZmG39VAtxezX8xrV75Rxj8rHUngDs4F9Ly+CnTcZRcZRkd/Vps73glw+6hBu1Cpd zadwYt5mYNZT0Eo4ChaGm2AFD2TD+MQfOYJNVURUjQw1t7XYF4IucNPn6bHr3w+Vd+Pe Mv+MS1gP/j5tEo0c75f35He/6jNw6MeX6zAI8= Received: by 10.101.109.20 with SMTP id l20mr2841643anm.37.1268654449906; Mon, 15 Mar 2010 05:00:49 -0700 (PDT) Received: from [192.168.0.86] ([187.39.15.241]) by mx.google.com with ESMTPS id 7sm1405373yxg.68.2010.03.15.05.00.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Mar 2010 05:00:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Luiz Otavio O Souza In-Reply-To: <20100315111756.05fd5805.ray@ddteam.net> Date: Mon, 15 Mar 2010 09:00:46 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100314.181902.67053632336017068.imp@bsdimp.com> <20100315111756.05fd5805.ray@ddteam.net> To: Alex RAY X-Mailer: Apple Mail (2.1077) Cc: mips@freebsd.org Subject: Re: Request for review: AR71XX config cleanup X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 12:26:42 -0000 On Mar 15, 2010, at 6:17 AM, Alex RAY wrote: > On Sun, 14 Mar 2010 18:19:02 -0600 (MDT) > "M. Warner Losh" wrote: >=20 >> Greetings, >>=20 >> I've done a quick stab at cleaning up the AR71XX config file. The >> problem with it is that isn't for the AR71XX, but really for the >> RouterStation Pro for Ubiquiti. Every time I build my normal >> ROUTER-STATION board, I forget to put the hints back and it won't >> boot. >>=20 >> So, I've created a std.ar71xx. This is the standard config file for >> all ar71xx boards. You can then specialize it to reflect the >> population of your specific board. I've also separated the hints = that >> are relevant to the Atheros SoC from those that are relevant only to = a >> specific board. There's a std.ar71xx.hints. >>=20 >> The patches for this are at >> http://people.freebsd.org/~imp/ar71xx-config.diff to illustrate all >> the details. >>=20 >> In general, I think this looks like a good design pattern for phasing >> out DEFAULTS on the other architectures as well. But before I expand >> it to them, I'd like to get the mipsy world hammered out. >>=20 >> Comments? >>=20 >> Warner >> _______________________________________________ >> freebsd-mips@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-mips >> To unsubscribe, send any mail to = "freebsd-mips-unsubscribe@freebsd.org" >=20 >=20 > Hi Warner, >=20 > Maybe umass and SCSI modules relocate from the std files to config = files? There are a few models that don't have USB or PCI at all, so it would be = cool if we can keep std.ar71xx with basic devices only. Please consider the following patch (full files, not really a patch): http://loos.no-ip.org:280/ar71xx.config Thanks, Luiz= From owner-freebsd-mips@FreeBSD.ORG Mon Mar 15 13:52:53 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18A4F106566C for ; Mon, 15 Mar 2010 13:52:53 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-qy0-f190.google.com (mail-qy0-f190.google.com [209.85.221.190]) by mx1.freebsd.org (Postfix) with ESMTP id C00228FC08 for ; Mon, 15 Mar 2010 13:52:52 +0000 (UTC) Received: by qyk28 with SMTP id 28so2720294qyk.14 for ; Mon, 15 Mar 2010 06:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=EPlt5l6rWc88MuB23Zc5cdOC0Jqv2umVFcCHubyYpnU=; b=jNsPit2Ox0fEQ148a5Ybxhf6E3f2YV3VvozHB5A7C7NX2jTX7PpN9Mkm8gBkbxH/jT /HqunMPS3eJS9rkCLEYX06y47O3CiHZEEteJVTNwIX6zadmkzHX0L762grbPfMB6vOQR kprnxxC6wRktawXrjw0WjuiSYK0OdGQ40FJNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VfJS/ziCfOQm8Ihc+ugiOaM52GODL5ft3xrXxTMTE2onMFAimvB6c3P7Rvm7enEEXc lFkxV12CaggnHWdIWGmMxSoLMIXvUVO2NWHSyTnK+BcngmFEAq5rB0im34XMdlqHSEGC z9DqfTFkBo9Bx0roQkBrq1PnIZl4qSraxZkgM= Received: by 10.224.17.232 with SMTP id t40mr1553772qaa.47.1268659403892; Mon, 15 Mar 2010 06:23:23 -0700 (PDT) Received: from beastie.micom.mng.net ([202.179.21.142]) by mx.google.com with ESMTPS id 20sm3179142qyk.0.2010.03.15.06.23.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Mar 2010 06:23:21 -0700 (PDT) Message-ID: <4B9E34AE.9060301@gmail.com> Date: Mon, 15 Mar 2010 21:22:54 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.23 (X11/20091011) MIME-Version: 1.0 To: "M. Warner Losh" References: <20100314.181902.67053632336017068.imp@bsdimp.com> In-Reply-To: <20100314.181902.67053632336017068.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mips@freebsd.org Subject: Re: Request for review: AR71XX config cleanup X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 13:52:53 -0000 M. Warner Losh wrote: > Greetings, > > I've done a quick stab at cleaning up the AR71XX config file. The > problem with it is that isn't for the AR71XX, but really for the > RouterStation Pro for Ubiquiti. Every time I build my normal > ROUTER-STATION board, I forget to put the hints back and it won't > boot. > > So, I've created a std.ar71xx. This is the standard config file for > all ar71xx boards. You can then specialize it to reflect the > population of your specific board. I've also separated the hints that > are relevant to the Atheros SoC from those that are relevant only to a > specific board. There's a std.ar71xx.hints. > > The patches for this are at > http://people.freebsd.org/~imp/ar71xx-config.diff to illustrate all > the details. > > In general, I think this looks like a good design pattern for phasing > out DEFAULTS on the other architectures as well. But before I expand > it to them, I'd like to get the mipsy world hammered out. > > Comments? > Maybe it is not that important, but I see some naming differences in filenames and in comments like ROUTER-STATION, RouterStation, ROUTERSTATION, RSPRO etc. Maybe it can be RouterStation in comments and RS and RSPRO as config filenames. Please ignore if I'm wrong here. thanks, Ganbold > Warner > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > > -- I am firm. You are obstinate. He is a pig-headed fool. -- Katharine Whitehorn From owner-freebsd-mips@FreeBSD.ORG Mon Mar 15 14:30:31 2010 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D3FB106566B for ; Mon, 15 Mar 2010 14:30:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3E5E88FC19 for ; Mon, 15 Mar 2010 14:30:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o2FENNoG008533; Mon, 15 Mar 2010 08:23:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 15 Mar 2010 08:23:34 -0600 (MDT) Message-Id: <20100315.082334.1032464807170521414.imp@bsdimp.com> To: ray@ddteam.net From: "M. Warner Losh" In-Reply-To: <20100315111756.05fd5805.ray@ddteam.net> References: <20100314.181902.67053632336017068.imp@bsdimp.com> <20100315111756.05fd5805.ray@ddteam.net> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mips@FreeBSD.org Subject: Re: Request for review: AR71XX config cleanup X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:30:31 -0000 In message: <20100315111756.05fd5805.ray@ddteam.net> Alex RAY writes: : Maybe umass and SCSI modules relocate from the std files to config files? I'm a little on the fence here. std.foo is supposed to have all the things that are in GENERIC. In fact, I see sys/i386/GENERIC eventually being: ident GENERIC include "std.i386" So, if we view it from that point of view, it becomes clear that we want to include the usb/scsi stuff in std.ar71xx. They are easy enough to omit if you had a system without usb: include "std.ar71xx" nodevice usb nodevice umass nodevice scbus nodevice da wouldn't be a horrible burden on people. But then again, USB on x86 includes everything, whereas I've only include umass. If I'm going to subset, why this subset. How would others know what the right subset would be for their boards, etc. So that's why I'm on the fence. Once you start getting into the "this is sensible" game, then you have to start making seasoned judgements. Without a better definition of what a 'generic' kernel should have, or shouldn't have, I'm not sure there's a better way. Warner From owner-freebsd-mips@FreeBSD.ORG Mon Mar 15 14:40:07 2010 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ECC2106564A for ; Mon, 15 Mar 2010 14:40:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0B7FC8FC18 for ; Mon, 15 Mar 2010 14:40:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o2FETLjf008630; Mon, 15 Mar 2010 08:29:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 15 Mar 2010 08:29:32 -0600 (MDT) Message-Id: <20100315.082932.635883863650633831.imp@bsdimp.com> To: ganbold@gmail.com From: "M. Warner Losh" In-Reply-To: <4B9E34AE.9060301@gmail.com> References: <20100314.181902.67053632336017068.imp@bsdimp.com> <4B9E34AE.9060301@gmail.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mips@FreeBSD.org Subject: Re: Request for review: AR71XX config cleanup X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:40:07 -0000 In message: <4B9E34AE.9060301@gmail.com> Ganbold writes: : M. Warner Losh wrote: : > Greetings, : > : > I've done a quick stab at cleaning up the AR71XX config file. The : > problem with it is that isn't for the AR71XX, but really for the : > RouterStation Pro for Ubiquiti. Every time I build my normal : > ROUTER-STATION board, I forget to put the hints back and it won't : > boot. : > : > So, I've created a std.ar71xx. This is the standard config file for : > all ar71xx boards. You can then specialize it to reflect the : > population of your specific board. I've also separated the hints that : > are relevant to the Atheros SoC from those that are relevant only to a : > specific board. There's a std.ar71xx.hints. : > : > The patches for this are at : > http://people.freebsd.org/~imp/ar71xx-config.diff to illustrate all : > the details. : > : > In general, I think this looks like a good design pattern for phasing : > out DEFAULTS on the other architectures as well. But before I expand : > it to them, I'd like to get the mipsy world hammered out. : > : > Comments? : > : : Maybe it is not that important, but I see some naming differences in : filenames and in comments like ROUTER-STATION, RouterStation, : ROUTERSTATION, RSPRO etc. : Maybe it can be RouterStation in comments and RS and RSPRO as config : filenames. : Please ignore if I'm wrong here. I thought RS was too short, and ROUTERSTATIONPRO to be too long. I should also find the official capitialization. It is ROUTER-STATION on the actual board. Warner From owner-freebsd-mips@FreeBSD.ORG Mon Mar 15 14:41:22 2010 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A3BA106564A for ; Mon, 15 Mar 2010 14:41:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 487058FC14 for ; Mon, 15 Mar 2010 14:41:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o2FEQP8x008559; Mon, 15 Mar 2010 08:26:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 15 Mar 2010 08:26:37 -0600 (MDT) Message-Id: <20100315.082637.989915960068724581.imp@bsdimp.com> To: lists.br@gmail.com From: "M. Warner Losh" In-Reply-To: References: <20100314.181902.67053632336017068.imp@bsdimp.com> <20100315111756.05fd5805.ray@ddteam.net> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ray@ddteam.net, mips@FreeBSD.org Subject: Re: Request for review: AR71XX config cleanup X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:41:22 -0000 In message: Luiz Otavio O Souza writes: : There are a few models that don't have USB or PCI at all, so it : would be cool if we can keep std.ar71xx with basic devices only. This is a judgement call. Maybe without usb, but I can't see not putting pci into the std.ar71xx. It is easy enough to remove and is going to be needed by the vast majority of people. USB is a tougher call, since it will be needed by a more interesting subset. : Please consider the following patch (full files, not really a patch): : : http://loos.no-ip.org:280/ar71xx.config But this still has the ath driver in it, which only attaches on pci bus. Warner From owner-freebsd-mips@FreeBSD.ORG Mon Mar 15 18:06:34 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF1F31065673 for ; Mon, 15 Mar 2010 18:06:34 +0000 (UTC) (envelope-from returns@c.ss36.on9mail.com) Received: from c.ss36.on9mail.com (c.ss36.on9mail.com [209.144.27.61]) by mx1.freebsd.org (Postfix) with ESMTP id 9539C8FC0A for ; Mon, 15 Mar 2010 18:06:34 +0000 (UTC) Received: by c.ss36.on9mail.com (Postfix, from userid 0) id E785F5815E2; Mon, 15 Mar 2010 12:48:42 -0500 (CDT) To: freebsd-mips@freebsd.org Message-ID: <1268675322_SectionID-501087_HitID-1268672224201_SiteID-43865_EmailID-102469373_DB-1_SID-0@ss36.on9mail.com> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ss36.on9mail.com; i=@ss36.on9mail.com; q=dns/txt; s=gmmailerd; t=1268675310; h=From; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; b=XEcpEb0JK+FDkX6QFrI3orssd6UCiAYdaWHIG+y0hhlEGXF1JVE/UnFQ9cjhWQDKPN5NFLAzKM35UQSG4582UD7DMuNz9kaZQEzjNF6+2a/wes4KfTpE3ixXaxQNLggzRP7vQw0VbbD3bab8/KVbnoIR+m3mLWmjl0APRijcUUo= From: "Mike Hammond" Mime-Version: 1.0 Date: Mon, 15 Mar 2010 12:48:42 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: If you have a hardwood floor, times have changed. X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 18:06:34 -0000 =20 Happy New Years! www.FloorGuardian.com = January 2010 =EF=BF=BD =20 We protect your floors while the others just cover it! We offer floo= r protection.=EF=BF=BD You have invested serious money in your gym floors a= nd we offer serious protection.=EF=BF=BD We protect your floor for the dama= ge that tables, chairs and heels can inflict.=EF=BF=BD Installs in about an= hour for my gyms.=EF=BF=BD Come in 9 colors but we can also Pantone match = if needed.=EF=BF=BD Not one of those tacky tarp systems, Floor Guardian is = a velcro'd seamed, carpet based, 6' wide roll product that is easily rolled= and carted under all doorways and stored on end.=EF=BF=BD No lifting as wi= th tiles, and none of the tape waste or trip hazards of a tarp and way more= elegant in looks.=EF=BF=BD As an example a=EF=BF=BD 70'x96' gym would have= 16 rolls and the storage would be 32"x108" of floor space.=20 =EF=BF=BDWe also will take your tarp system as a trade = in- We clean them and then donate them to your choice of=EF=BF=BD a Boys an= d Girls Club.=EF=BF=BD Turn your Gym or Hall into more than just an athletic s= pace, use it for receptions, rehearsals, recitals, graduations, PTA meeting= s, fund raisers and registrations. Reduce the need to refinish, while warmi= ng and quieting down the room.=EF=BF=BD Have recess insides on rainy days!= =EF=BF=BD Kids love it.=EF=BF=BD 7 year full warranty. So tough, you can cl= ean it with regular bleach.=EF=BF=BD Hundreds of schools for the past 20 ye= ars have been protecting their floors using Floor Guardian without 1 compla= int.=EF=BF=BD We have the referrals to back it up.=EF=BF=BD Click here for = a free sample and brochure. =EF=BF=BD Please visit our website or call for = more info.=20 =20 =20 =20 =20 =20 =20 web - www.FloorGuardian.com =EF=BF=BD=EF=BF=BD|=EF=BF= =BD=EF=BF=BD Product Sample - Free Sample=EF=BF=BD |=EF=BF=BD=EF=BF=BD tel = - 206-255-1491=20 =20 =20 =20 =20 =0AMessage sent by: Floor Guardian, 4841 California Ave SW, Seattle, 9= 8166-4329, United States=0A=0ATo unsubscribe, click the link below.=0Ahttp:= //c.ss36.on9mail.com/RWCode/subscribe.asp?SID=3D0&SiteID=3D43865&Email=3Dfr= eebsd-mips@freebsd.org&HitID=3D1268672224201 From owner-freebsd-mips@FreeBSD.ORG Mon Mar 15 21:23:40 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42C671065672 for ; Mon, 15 Mar 2010 21:23:40 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id D0D848FC19 for ; Mon, 15 Mar 2010 21:23:39 +0000 (UTC) Received: by bwz8 with SMTP id 8so3382915bwz.3 for ; Mon, 15 Mar 2010 14:23:38 -0700 (PDT) Received: by 10.204.20.77 with SMTP id e13mr3334049bkb.163.1268688218139; Mon, 15 Mar 2010 14:23:38 -0700 (PDT) Received: from localhost (240-142-132-95.pool.ukrtel.net [95.132.142.240]) by mx.google.com with ESMTPS id 16sm3165428bwz.1.2010.03.15.14.23.35 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Mar 2010 14:23:36 -0700 (PDT) Date: Mon, 15 Mar 2010 23:22:20 +0200 From: Alex RAY To: "M. Warner Losh" Message-Id: <20100315232220.7242063e.ray@ddteam.net> In-Reply-To: <20100315.082334.1032464807170521414.imp@bsdimp.com> References: <20100314.181902.67053632336017068.imp@bsdimp.com> <20100315111756.05fd5805.ray@ddteam.net> <20100315.082334.1032464807170521414.imp@bsdimp.com> Organization: DDTeam.net X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mips@FreeBSD.org Subject: Re: Request for review: AR71XX config cleanup X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 21:23:40 -0000 On Mon, 15 Mar 2010 08:23:34 -0600 (MDT) "M. Warner Losh" wrote: > In message: <20100315111756.05fd5805.ray@ddteam.net> > Alex RAY writes: > : Maybe umass and SCSI modules relocate from the std files to config files? > > I'm a little on the fence here. > > std.foo is supposed to have all the things that are in GENERIC. In > fact, I see sys/i386/GENERIC eventually being: > > ident GENERIC > include "std.i386" > > So, if we view it from that point of view, it becomes clear that we > want to include the usb/scsi stuff in std.ar71xx. They are easy > enough to omit if you had a system without usb: > > include "std.ar71xx" > nodevice usb > nodevice umass > nodevice scbus > nodevice da > > wouldn't be a horrible burden on people. > > But then again, USB on x86 includes everything, whereas I've only > include umass. If I'm going to subset, why this subset. How would > others know what the right subset would be for their boards, etc. > > So that's why I'm on the fence. Once you start getting into the "this > is sensible" game, then you have to start making seasoned judgements. > Without a better definition of what a 'generic' kernel should have, > or shouldn't have, I'm not sure there's a better way. > > Warner I think it should do two types of config, one for SoC, the second for the boards on it. First - just SoC can (in my BCM5354 cc, bfe, usb, wifi) Second - what board need GPIOs (btn, LED, etc), flash partitions mapping etc. Then std files hold SoC family defaults. (BCM5354, BCM4704 and BCM5836 very similar, so share one std file ) like so: mips/conf/D-LINK_DIR-320 (include mips/conf/BCM5454) mips/conf/ASUS_WRGXXXX (include mips/conf/BCM5354) mips/conf/BCM5354 (include mips/bcm47xx/std.bcm) . . . - Alex RAY From owner-freebsd-mips@FreeBSD.ORG Tue Mar 16 01:35:22 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10FAC1065670 for ; Tue, 16 Mar 2010 01:35:22 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-px0-f200.google.com (mail-px0-f200.google.com [209.85.216.200]) by mx1.freebsd.org (Postfix) with ESMTP id D9B638FC13 for ; Tue, 16 Mar 2010 01:35:21 +0000 (UTC) Received: by pxi38 with SMTP id 38so1352403pxi.27 for ; Mon, 15 Mar 2010 18:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=U0DcPi8Rj4RKLtgd0+ud0MHw7a9HCV1TmAXT4gR/aoA=; b=i8nAsIDMRWd892wORzm5Xx/A9lyE+Y+y3eXTMAWKjx5FL1fn84BwHWbQtJMdvEgA/V OrQZ0qQ2FoPwmMyr2m3lOg1zw2f8VqsfITyBeSReZVXrHEguH8D1HosNguX69Atgm+qs x9wGsXN+HGkEX9pYDTrsDUcSck+a/9kdab7EE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=BtY0+6SIOIXxKAy+Pmc1CJmZWRQu8G7OlEBditPZYhjsonlhBdfTokcC4VXdwLSVmq 94tl108oVrz79o56VHTxwgx1nQ8R1kkMy7p7vW7UXX4fI21d2DjE/aHPoqliO8ncg+oN Q1NNz9BJqO/tKrl6E746Y7rvEG/7yGcsSJTqQ= MIME-Version: 1.0 Received: by 10.142.247.1 with SMTP id u1mr1860854wfh.92.1268703321227; Mon, 15 Mar 2010 18:35:21 -0700 (PDT) Date: Mon, 15 Mar 2010 18:35:21 -0700 Message-ID: From: Neel Natu To: freebsd-mips@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: PATCH: enable use of memory beyond kseg0 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 01:35:22 -0000 Hi, This patch enables use of physical memory that is beyond the direct mapped kseg0 region. The basic idea is to use KVA from the kseg2 region for mapping page table pages that lie beyond the direct mapped region. The TLB miss handler can now recursively fault into the TLB invalid handler if it dereferences a kseg2 page table page address that is not in the TLB. The TLB invalid handler had to be extensively modified but in the end came out much cleaner. I have tested this on a uni and multi-processor Sibyte with 1GB of memory. It would be useful if this patch had some independent testing as well. Please review. http://people.freebsd.org/~neel/mips_beyond_kseg.diff best Neel Index: sys/mips/include/db_machdep.h =================================================================== --- sys/mips/include/db_machdep.h (revision 205197) +++ sys/mips/include/db_machdep.h (working copy) @@ -92,7 +92,6 @@ #define DB_SMALL_VALUE_MIN (-0x400001) int db_inst_type(int); -void db_dump_tlb(int, int); db_addr_t branch_taken(int inst, db_addr_t pc); void stacktrace_subr(register_t pc, register_t sp, register_t ra, int (*)(const char *, ...)); int kdbpeek(int *); Index: sys/mips/include/trap.h =================================================================== --- sys/mips/include/trap.h (revision 205197) +++ sys/mips/include/trap.h (working copy) @@ -111,11 +111,10 @@ void MipsFPTrap(u_int, u_int, u_int); void MipsKernGenException(void); void MipsKernIntr(void); -void MipsKernTLBInvalidException(void); +void MipsTLBInvalidException(void); void MipsTLBMissException(void); void MipsUserGenException(void); void MipsUserIntr(void); -void MipsUserTLBInvalidException(void); u_int trap(struct trapframe *); Index: sys/mips/mips/db_trace.c =================================================================== --- sys/mips/mips/db_trace.c (revision 205197) +++ sys/mips/mips/db_trace.c (working copy) @@ -162,13 +162,10 @@ subr = (uintptr_t)MipsUserGenException; else if (pcBetween(MipsKernIntr, MipsUserIntr)) subr = (uintptr_t)MipsKernIntr; - else if (pcBetween(MipsUserIntr, MipsKernTLBInvalidException)) + else if (pcBetween(MipsUserIntr, MipsTLBInvalidException)) subr = (uintptr_t)MipsUserIntr; - else if (pcBetween(MipsKernTLBInvalidException, - MipsUserTLBInvalidException)) - subr = (uintptr_t)MipsKernTLBInvalidException; - else if (pcBetween(MipsUserTLBInvalidException, MipsTLBMissException)) - subr = (uintptr_t)MipsUserTLBInvalidException; + else if (pcBetween(MipsTLBInvalidException, MipsTLBMissException)) + subr = (uintptr_t)MipsTLBInvalidException; else if (pcBetween(fork_trampoline, savectx)) subr = (uintptr_t)fork_trampoline; else if (pcBetween(savectx, mips_cpu_throw)) Index: sys/mips/mips/exception.S =================================================================== --- sys/mips/mips/exception.S (revision 205197) +++ sys/mips/mips/exception.S (working copy) @@ -264,13 +264,13 @@ mfc0 a0, COP_0_STATUS_REG ;\ li a2, (MIPS_SR_KX | MIPS_SR_SX | MIPS_SR_UX) ; \ or a0, a0, a2 ; \ - li a2, ~(MIPS_SR_INT_IE|MIPS_SR_EXL) ; \ + li a2, ~(MIPS_SR_INT_IE | MIPS_SR_EXL | SR_KSU_USER) ; \ and a0, a0, a2 ; \ mtc0 a0, COP_0_STATUS_REG #else #define CLEAR_STATUS \ mfc0 a0, COP_0_STATUS_REG ;\ - li a2, ~(MIPS_SR_INT_IE|MIPS_SR_EXL) ; \ + li a2, ~(MIPS_SR_INT_IE | MIPS_SR_EXL | SR_KSU_USER) ; \ and a0, a0, a2 ; \ mtc0 a0, COP_0_STATUS_REG #endif @@ -827,178 +827,169 @@ .set at END(MipsUserIntr) -NLEAF(MipsKernTLBInvalidException) - .set noat - mfc0 k0, COP_0_BAD_VADDR # get the fault address +NLEAF(MipsTLBInvalidException) + .set push + .set noat + .set noreorder - + mfc0 k0, COP_0_BAD_VADDR li k1, VM_MAXUSER_ADDRESS sltu k1, k0, k1 - beqz k1, 1f + bnez k1, 1f nop - GET_CPU_PCPU(k1) - lw k1, PC_SEGBASE(k1) # works for single cpu???? - beqz k1, _C_LABEL(MipsKernGenException) # seg tab is null - nop + + /* badvaddr = kernel address */ + lui k1, %hi(_C_LABEL(kernel_segmap)) b 2f - nop + lw k1, %lo(_C_LABEL(kernel_segmap))(k1) + 1: - li k1, (VM_MAX_KERNEL_ADDRESS) - bgez k0, _C_LABEL(MipsKernGenException) # full trap processing - sltu k1, k1, k0 # check fault address against - bnez k1, _C_LABEL(MipsKernGenException) # kernel_segmap upper bound - lui k1, %hi(_C_LABEL(kernel_segmap)) # k1=hi of segbase - lw k1, %lo(_C_LABEL(kernel_segmap))(k1) # k1=segment tab base - beqz k1, _C_LABEL(MipsKernGenException) # seg tab is null + /* badvaddr = user address */ + GET_CPU_PCPU(k1) + lw k1, PC_SEGBASE(k1) + 2: - srl k0, 20 # k0=seg offset (almost) - andi k0, k0, 0xffc # k0=seg offset (mask 0x3) -#xxx mips64 unsafe? - addu k1, k0, k1 # k1=seg entry address - lw k1, 0(k1) # k1=seg entry - mfc0 k0, COP_0_BAD_VADDR # k0=bad address (again) - beq k1, zero, _C_LABEL(MipsKernGenException) # ==0 -- no page table - srl k0, k0, PGSHIFT-2 - andi k0, k0, 0xffc # compute offset from index - tlbp # Probe the invalid entry -#xxx mips64 unsafe? + beqz k1, 3f /* invalid page directory pointer */ + nop + + srl k0, SEGSHIFT - 2 + andi k0, 0xffc addu k1, k1, k0 - and k0, k0, 4 # check even/odd page - nop # required for QED 5230 - bne k0, zero, KernTLBIOdd + lw k1, 0(k1) + beqz k1, 3f /* invalid page table page pointer */ nop - mfc0 k0, COP_0_TLB_INDEX + mfc0 k0, COP_0_BAD_VADDR + srl k0, PGSHIFT - 2 + andi k0, 0xffc + addu k1, k1, k0 + + lw k0, 0(k1) + andi k0, PTE_V + beqz k0, 3f /* invalid page table entry */ nop - bltz k0, sys_stk_chk - sltiu k0, k0, VMWIRED_ENTRIES # index below wired entries? - bne k0, zero, sys_stk_chk - lw k0, 0(k1) # get PTE entry + andi k0, k1, 4 + bnez k0, odd_page + nop - _SLL k0, k0, WIRED_SHIFT # get rid of "wired" bit +even_page: + lw k0, 0(k1) + _SLL k0, k0, WIRED_SHIFT _SRL k0, k0, WIRED_SHIFT - _MTC0 k0, COP_0_TLB_LO0 # load PTE entry - and k0, k0, PTE_V # check for valid entry - nop # required for QED5230 - beq k0, zero, _C_LABEL(MipsKernGenException) # PTE invalid - lw k0, 4(k1) # get odd PTE entry + _MTC0 k0, COP_0_TLB_LO0 + + lw k0, 4(k1) _SLL k0, k0, WIRED_SHIFT _SRL k0, k0, WIRED_SHIFT - _MTC0 k0, COP_0_TLB_LO1 # load PTE entry - HAZARD_DELAY - tlbwi # write TLB - HAZARD_DELAY - eret + _MTC0 k0, COP_0_TLB_LO1 -KernTLBIOdd: - mfc0 k0, COP_0_TLB_INDEX + b tlb_insert_entry nop - bltz k0, sys_stk_chk - sltiu k0, k0, VMWIRED_ENTRIES # index below wired entries? - bne k0, zero, sys_stk_chk - lw k0, 0(k1) # get PTE entry - - _SLL k0, k0, WIRED_SHIFT # get rid of wired bit +odd_page: + lw k0, 0(k1) + _SLL k0, k0, WIRED_SHIFT _SRL k0, k0, WIRED_SHIFT - _MTC0 k0, COP_0_TLB_LO1 # save PTE entry - and k0, k0, PTE_V # check for valid entry - nop # required for QED5230 - beq k0, zero, _C_LABEL(MipsKernGenException) # PTE invalid - lw k0, -4(k1) # get even PTE entry + _MTC0 k0, COP_0_TLB_LO1 + + lw k0, -4(k1) _SLL k0, k0, WIRED_SHIFT _SRL k0, k0, WIRED_SHIFT - _MTC0 k0, COP_0_TLB_LO0 # save PTE entry + _MTC0 k0, COP_0_TLB_LO0 + +tlb_insert_entry: + tlbp HAZARD_DELAY - tlbwi # update TLB + mfc0 k0, COP_0_TLB_INDEX HAZARD_DELAY + bltz k0, tlb_insert_random + nop + tlbwi eret + ssnop - .set at -END(MipsKernTLBInvalidException) +tlb_insert_random: + tlbwr + eret + ssnop - -NLEAF(MipsUserTLBInvalidException) - .set noat - mfc0 k0, COP_0_BAD_VADDR # get the fault address - - li k1, VM_MAXUSER_ADDRESS - sltu k1, k0, k1 - beqz k1, _C_LABEL(MipsUserGenException) +3: + /* + * Branch to the comprehensive exception processing. + */ + mfc0 k1, COP_0_STATUS_REG + andi k1, k1, SR_KSU_USER + bnez k1, _C_LABEL(MipsUserGenException) nop + + /* + * Check for kernel stack overflow. + */ GET_CPU_PCPU(k1) - lw k1, PC_SEGBASE(k1) # works for single cpu???? - beqz k1, _C_LABEL(MipsUserGenException) # seg tab is null + lw k0, PC_CURTHREAD(k1) + lw k0, TD_REALKSTACK(k0) + sltu k0, k0, sp + bnez k0, _C_LABEL(MipsKernGenException) nop -2: - srl k0, 20 # k0=seg offset (almost) - andi k0, k0, 0xffc # k0=seg offset (mask 0x3) -#xxx mips64 unsafe? - addu k1, k0, k1 # k1=seg entry address - lw k1, 0(k1) # k1=seg entry - mfc0 k0, COP_0_BAD_VADDR # k0=bad address (again) - beq k1, zero, _C_LABEL(MipsUserGenException) # ==0 -- no page table - srl k0, k0, PGSHIFT-2 - andi k0, k0, 0xffc # compute offset from index - tlbp # Probe the invalid entry -#xxx mips64 unsafe? - addu k1, k1, k0 - and k0, k0, 4 # check even/odd page - nop # required for QED 5230 - bne k0, zero, UserTLBIOdd - nop - mfc0 k0, COP_0_TLB_INDEX - nop - bltz k0, _C_LABEL(MipsUserGenException) + /* + * Kernel stack overflow. + * + * Move to a valid stack before we call panic. We use the boot stack + * for this purpose. + */ + GET_CPU_PCPU(k1) + lw k1, PC_CPUID(k1) + sll k1, k1, PAGE_SHIFT + 1 - sltiu k0, k0, VMWIRED_ENTRIES # index below wired entries? - bne k0, zero, _C_LABEL(MipsUserGenException) - lw k0, 0(k1) # get PTE entry + PTR_LA k0, _C_LABEL(pcpu_space) + addiu k0, (NBPG * 2) + addu k0, k0, k1 - _SLL k0, k0, WIRED_SHIFT # get rid of "wired" bit - _SRL k0, k0, WIRED_SHIFT - _MTC0 k0, COP_0_TLB_LO0 # load PTE entry - and k0, k0, PTE_V # check for valid entry - nop # required for QED5230 - beq k0, zero, _C_LABEL(MipsUserGenException) # PTE invalid - lw k0, 4(k1) # get odd PTE entry - _SLL k0, k0, WIRED_SHIFT - _SRL k0, k0, WIRED_SHIFT - _MTC0 k0, COP_0_TLB_LO1 # load PTE entry - HAZARD_DELAY - tlbwi # write TLB - HAZARD_DELAY - eret + /* + * Stash the original value of 'sp' so we can update trapframe later. + * We assume that SAVE_CPU does not trash 'k1'. + */ + move k1, sp -UserTLBIOdd: - mfc0 k0, COP_0_TLB_INDEX - nop - bltz k0, _C_LABEL(MipsUserGenException) - sltiu k0, k0, VMWIRED_ENTRIES # index below wired entries? + move sp, k0 + subu sp, sp, KERN_EXC_FRAME_SIZE - bne k0, zero, _C_LABEL(MipsUserGenException) - lw k0, 0(k1) # get PTE entry + move k0, ra + move ra, zero + sw ra, CALLFRAME_RA(sp) /* stop the ddb backtrace right here */ + sw zero, CALLFRAME_SP(sp) + move ra, k0 - _SLL k0, k0, WIRED_SHIFT # get rid of wired bit - _SRL k0, k0, WIRED_SHIFT - _MTC0 k0, COP_0_TLB_LO1 # save PTE entry - and k0, k0, PTE_V # check for valid entry - nop # required for QED5230 - beq k0, zero, _C_LABEL(MipsUserGenException) # PTE invalid - lw k0, -4(k1) # get even PTE entry - _SLL k0, k0, WIRED_SHIFT - _SRL k0, k0, WIRED_SHIFT - _MTC0 k0, COP_0_TLB_LO0 # save PTE entry - HAZARD_DELAY - tlbwi # update TLB - HAZARD_DELAY - eret + SAVE_CPU - .set at -END(MipsUserTLBInvalidException) + /* + * Now restore the value of 'sp' at the time of the tlb exception in + * the trapframe. + */ + SAVE_REG(k1, SP, sp) + /* + * Squelch any more overflow checks by setting the stack base to 0. + */ + GET_CPU_PCPU(k1) + lw k0, PC_CURTHREAD(k1) + sw zero, TD_REALKSTACK(k0) + + move a1, a0 + PANIC("kernel stack overflow - trapframe at %p") + + /* + * This nop is necessary so that the 'ra' remains within the bounds + * of this handler. Otherwise the ddb backtrace code will think that + * the panic() was called from MipsTLBMissException. + */ + nop + + .set pop +END(MipsTLBInvalidException) + /*---------------------------------------------------------------------------- * * MipsTLBMissException -- @@ -1048,68 +1039,6 @@ tlbwr # write to tlb HAZARD_DELAY eret # return from exception - -sys_stk_chk: - GET_CPU_PCPU(k0) - lw k0, PC_CURTHREAD(k0) - lw k0, TD_REALKSTACK(k0) - sltu k0, sp, k0 # check for stack overflow - beqz k0, _C_LABEL(MipsKernGenException) # not stack overflow - nop - -# stack overflow - PTR_LA a0, _C_LABEL(_start) - CALLFRAME_SIZ - 8 # set sp to a valid place - sw sp, 24(a0) - move sp, a0 - PTR_LA a0, 1f - mfc0 a2, COP_0_STATUS_REG - mfc0 a3, COP_0_CAUSE_REG - _MFC0 a1, COP_0_EXC_PC - sw a2, 16(sp) - sw a3, 20(sp) - move a2, ra - PTR_LA k0, _C_LABEL(printf) - jalr k0 - mfc0 a3, COP_0_BAD_VADDR - - PTR_LA sp, _C_LABEL(_start) - CALLFRAME_SIZ # set sp to a valid place - -#if !defined(SMP) && defined(DDB) - PTR_LA a0, 2f - PTR_LA k0, _C_LABEL(trapDump) - jalr k0 - nop - - li a0, 0 - lw a1, _C_LABEL(num_tlbentries) - PTR_LA k0, _C_LABEL(db_dump_tlb) - jalr k0 - addu a1, -1 - -3: - b 3b - nop -#endif - - PANIC("kernel stack overflow") - - .data - .globl lastktlbmiss -lastktlbmiss: - .word 0 -lastktlbmisspc: - .word 0 -lastutlbmiss: - .word 0 -lastutlbmisspc: - .word 0 - -1: - .asciiz "ktlbmiss: PC %x RA %x ADR %x\nSR %x CR %x SP %x\n" -2: - .asciiz "stack ovf" - .text - .set at END(MipsTLBMissException) Index: sys/mips/mips/pmap.c =================================================================== --- sys/mips/mips/pmap.c (revision 205197) +++ sys/mips/mips/pmap.c (working copy) @@ -949,10 +949,21 @@ static int _pmap_unwire_pte_hold(pmap_t pmap, vm_page_t m) { + vm_offset_t pteva; /* * unmap the page table page */ + pteva = (vm_offset_t)pmap->pm_segtab[m->pindex]; + if (pteva >= VM_MIN_KERNEL_ADDRESS) { + pmap_kremove(pteva); + kmem_free(kernel_map, pteva, PAGE_SIZE); + } else { + KASSERT(MIPS_IS_KSEG0_ADDR(pteva), + ("_pmap_unwire_pte_hold: 0x%0lx is not in kseg0", + (long)pteva)); + } + pmap->pm_segtab[m->pindex] = 0; --pmap->pm_stats.resident_count; @@ -997,7 +1008,7 @@ mpte = pmap->pm_ptphint; } else { pteva = *pmap_pde(pmap, va); - mpte = PHYS_TO_VM_PAGE(MIPS_KSEG0_TO_PHYS(pteva)); + mpte = PHYS_TO_VM_PAGE(vtophys(pteva)); pmap->pm_ptphint = mpte; } } @@ -1029,6 +1040,8 @@ int pmap_pinit(pmap_t pmap) { + vm_offset_t ptdva; + vm_paddr_t ptdpa; vm_page_t ptdpg; int i; int req; @@ -1050,8 +1063,17 @@ ptdpg->valid = VM_PAGE_BITS_ALL; - pmap->pm_segtab = (pd_entry_t *) - MIPS_PHYS_TO_KSEG0(VM_PAGE_TO_PHYS(ptdpg)); + ptdpa = VM_PAGE_TO_PHYS(ptdpg); + if (ptdpa < MIPS_KSEG0_LARGEST_PHYS) { + ptdva = MIPS_PHYS_TO_KSEG0(ptdpa); + } else { + ptdva = kmem_alloc_nofault(kernel_map, PAGE_SIZE); + if (ptdva == 0) + panic("pmap_pinit: unable to allocate kva"); + pmap_kenter(ptdva, ptdpa); + } + + pmap->pm_segtab = (pd_entry_t *)ptdva; if ((ptdpg->flags & PG_ZERO) == 0) bzero(pmap->pm_segtab, PAGE_SIZE); @@ -1118,7 +1140,15 @@ pmap->pm_stats.resident_count++; ptepa = VM_PAGE_TO_PHYS(m); - pteva = MIPS_PHYS_TO_KSEG0(ptepa); + if (ptepa < MIPS_KSEG0_LARGEST_PHYS) { + pteva = MIPS_PHYS_TO_KSEG0(ptepa); + } else { + pteva = kmem_alloc_nofault(kernel_map, PAGE_SIZE); + if (pteva == 0) + panic("_pmap_allocpte: unable to allocate kva"); + pmap_kenter(pteva, ptepa); + } + pmap->pm_segtab[ptepindex] = (pd_entry_t)pteva; /* @@ -1172,7 +1202,7 @@ (pmap->pm_ptphint->pindex == ptepindex)) { m = pmap->pm_ptphint; } else { - m = PHYS_TO_VM_PAGE(MIPS_KSEG0_TO_PHYS(pteva)); + m = PHYS_TO_VM_PAGE(vtophys(pteva)); pmap->pm_ptphint = m; } m->wire_count++; @@ -1212,13 +1242,24 @@ void pmap_release(pmap_t pmap) { + vm_offset_t ptdva; vm_page_t ptdpg; KASSERT(pmap->pm_stats.resident_count == 0, ("pmap_release: pmap resident count %ld != 0", pmap->pm_stats.resident_count)); - ptdpg = PHYS_TO_VM_PAGE(MIPS_KSEG0_TO_PHYS(pmap->pm_segtab)); + ptdva = (vm_offset_t)pmap->pm_segtab; + ptdpg = PHYS_TO_VM_PAGE(vtophys(ptdva)); + + if (ptdva >= VM_MIN_KERNEL_ADDRESS) { + pmap_kremove(ptdva); + kmem_free(kernel_map, ptdva, PAGE_SIZE); + } else { + KASSERT(MIPS_IS_KSEG0_ADDR(ptdva), + ("pmap_release: 0x%0lx is not in kseg0", (long)ptdva)); + } + ptdpg->wire_count--; atomic_subtract_int(&cnt.v_wire_count, 1); vm_page_free_zero(ptdpg); @@ -2030,7 +2071,7 @@ (pmap->pm_ptphint->pindex == ptepindex)) { mpte = pmap->pm_ptphint; } else { - mpte = PHYS_TO_VM_PAGE(MIPS_KSEG0_TO_PHYS(pteva)); + mpte = PHYS_TO_VM_PAGE(vtophys(pteva)); pmap->pm_ptphint = mpte; } mpte->wire_count++; @@ -3171,18 +3212,6 @@ pmap->pm_asid[PCPU_GET(cpuid)].gen = PCPU_GET(asid_generation); PCPU_SET(next_asid, PCPU_GET(next_asid) + 1); } - -#ifdef DEBUG - if (pmapdebug & (PDB_FOLLOW | PDB_TLBPID)) { - if (curproc) - printf("pmap_asid_alloc: curproc %d '%s' ", - curproc->p_pid, curproc->p_comm); - else - printf("pmap_asid_alloc: curproc "); - printf("segtab %p asid %d\n", pmap->pm_segtab, - pmap->pm_asid[PCPU_GET(cpuid)].asid); - } -#endif } int @@ -3251,43 +3280,7 @@ PHYS_TO_VM_PAGE(pa)->md.pv_flags |= (PV_TABLE_REF | PV_TABLE_MOD); } -#include - /* - * Dump the translation buffer (TLB) in readable form. - */ - -void -db_dump_tlb(int first, int last) -{ - struct tlb tlb; - int tlbno; - - tlbno = first; - - while (tlbno <= last) { - MachTLBRead(tlbno, &tlb); - if (tlb.tlb_lo0 & PTE_V || tlb.tlb_lo1 & PTE_V) { - printf("TLB %2d vad 0x%08x ", tlbno, (tlb.tlb_hi & 0xffffff00)); - } else { - printf("TLB*%2d vad 0x%08x ", tlbno, (tlb.tlb_hi & 0xffffff00)); - } - printf("0=0x%08x ", pfn_to_vad(tlb.tlb_lo0)); - printf("%c", tlb.tlb_lo0 & PTE_M ? 'M' : ' '); - printf("%c", tlb.tlb_lo0 & PTE_G ? 'G' : ' '); - printf(" atr %x ", (tlb.tlb_lo0 >> 3) & 7); - printf("1=0x%08x ", pfn_to_vad(tlb.tlb_lo1)); - printf("%c", tlb.tlb_lo1 & PTE_M ? 'M' : ' '); - printf("%c", tlb.tlb_lo1 & PTE_G ? 'G' : ' '); - printf(" atr %x ", (tlb.tlb_lo1 >> 3) & 7); - printf(" sz=%x pid=%x\n", tlb.tlb_mask, - (tlb.tlb_hi & 0x000000ff) - ); - tlbno++; - } -} - -/* * Routine: pmap_kextract * Function: * Extract the physical page address associated Index: sys/mips/mips/trap.c =================================================================== --- sys/mips/mips/trap.c (revision 205197) +++ sys/mips/mips/trap.c (working copy) @@ -118,8 +118,8 @@ */ MipsKernIntr, /* external interrupt */ MipsKernGenException, /* TLB modification */ - MipsKernTLBInvalidException, /* TLB miss (load or instr. fetch) */ - MipsKernTLBInvalidException, /* TLB miss (store) */ + MipsTLBInvalidException,/* TLB miss (load or instr. fetch) */ + MipsTLBInvalidException,/* TLB miss (store) */ MipsKernGenException, /* address error (load or I-fetch) */ MipsKernGenException, /* address error (store) */ MipsKernGenException, /* bus error (I-fetch) */ @@ -153,8 +153,8 @@ */ MipsUserIntr, /* 0 */ MipsUserGenException, /* 1 */ - MipsUserTLBInvalidException, /* 2 */ - MipsUserTLBInvalidException, /* 3 */ + MipsTLBInvalidException,/* 2 */ + MipsTLBInvalidException,/* 3 */ MipsUserGenException, /* 4 */ MipsUserGenException, /* 5 */ MipsUserGenException, /* 6 */ From owner-freebsd-mips@FreeBSD.ORG Fri Mar 19 12:18:56 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E473106564A for ; Fri, 19 Mar 2010 12:18:56 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3525D8FC20 for ; Fri, 19 Mar 2010 12:18:55 +0000 (UTC) Received: by pwj4 with SMTP id 4so2460063pwj.13 for ; Fri, 19 Mar 2010 05:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=i0UFztXI63VL8ybAxRs9JtF3XTRRiw1/p7D/72QnRbw=; b=Pv6jhx2hLqc4HAhjrY2Ji+2269IYHl5VyP65lWDSr+T7FK1wRM5vs7lD6issOuhH+T kkmxAzYlEA3dNq2YhGs4tc0DzwywSsSys/sSX9SLs5bsY6Iboa5dKyGO5DM294ocwlUI xVv0xYk+FtutUZCRRfTcge9slAyOtKW9uNmvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PUjreNvUp293egcVvj6Gl7ClRFJftaMfL2fo6xnFTscRwq9VLxuKwNgRIjGZhN887T GUC+N0tlJ4L/RuZES87viK4X+ZBX0Ju3a8vSosGD2/4efYnx1JnBSpG3vMbgLjsE9B4k kE7GhMDQuoII62Piek+Bp0MoQGs4MNmGykxns= MIME-Version: 1.0 Received: by 10.141.213.21 with SMTP id p21mr2909648rvq.103.1269001134422; Fri, 19 Mar 2010 05:18:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Mar 2010 17:48:54 +0530 Message-ID: <98a59be81003190518h32b118d3t79927954c92f933a@mail.gmail.com> From: "C. Jayachandran" To: Neel Natu Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: PATCH: enable use of memory beyond kseg0 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 12:18:56 -0000 On Tue, Mar 16, 2010 at 7:05 AM, Neel Natu wrote: > This patch enables use of physical memory that is beyond the direct > mapped kseg0 region. > > The basic idea is to use KVA from the kseg2 region for mapping page > table pages that lie beyond the direct mapped region. > > The TLB miss handler can now recursively fault into the TLB invalid > handler if it dereferences a kseg2 page table page address that is not > in the TLB. The TLB invalid handler had to be extensively modified but > in the end came out much cleaner. > > I have tested this on a uni and multi-processor Sibyte with 1GB of > memory. It would be useful if this patch had some independent testing > as well. > > Please review. > > http://people.freebsd.org/~neel/mips_beyond_kseg.diff This fixes the crash I was seeing during 'make -j16 buildworld' on XLR. The buildworld completed after running about 6 hours over NFS mounted src and obj dir, so the patch looks good. I haven't done any performance comparisons yet. JC. From owner-freebsd-mips@FreeBSD.ORG Fri Mar 19 18:48:59 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C5C71065670 for ; Fri, 19 Mar 2010 18:48:59 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 426A38FC1A for ; Fri, 19 Mar 2010 18:48:59 +0000 (UTC) Received: by pvc7 with SMTP id 7so510932pvc.13 for ; Fri, 19 Mar 2010 11:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rcwuw2Hpvj/Llx9cHUUWCE/pTXA3dsVxusb0iuQZk4o=; b=gtjy5YF8M3H6tcW5BSki1FYB6ssIwyC8c/P+V/WGaimEGf5kvSisc1WR1Xdxyz6ZWj VHUPgn/706hKnSBx/gqwpzprlaapuIWXLZi+eKkpktAFSQDSkliSV/+hatJkpVVPnmXx QhCvbhk9KgpW82PvKvgqRiZeg0+z4X/Rx54QA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vPynqC77Th5uw1SfpXJsOXgpeh/Hh1nfHyCMl6zhC9DiV+eeFhuY66qVnMog9kgj+0 PC57KOPYu/gsLAkhp3jjPDmtv2piqdf+YHhoDuge034GKQGg3KPkMBi6TsydvJ+Bvzl6 DI98ZD52o8T4bKYTDHffKcMIU6VvXpMkK/i8w= MIME-Version: 1.0 Received: by 10.142.60.21 with SMTP id i21mr547037wfa.132.1269024538756; Fri, 19 Mar 2010 11:48:58 -0700 (PDT) In-Reply-To: <98a59be81003190518h32b118d3t79927954c92f933a@mail.gmail.com> References: <98a59be81003190518h32b118d3t79927954c92f933a@mail.gmail.com> Date: Fri, 19 Mar 2010 11:48:58 -0700 Message-ID: From: Neel Natu To: "C. Jayachandran" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: PATCH: enable use of memory beyond kseg0 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 18:48:59 -0000 Hi JC, On Fri, Mar 19, 2010 at 5:18 AM, C. Jayachandran wrote: > On Tue, Mar 16, 2010 at 7:05 AM, Neel Natu wrote: >> This patch enables use of physical memory that is beyond the direct >> mapped kseg0 region. >> >> The basic idea is to use KVA from the kseg2 region for mapping page >> table pages that lie beyond the direct mapped region. >> >> The TLB miss handler can now recursively fault into the TLB invalid >> handler if it dereferences a kseg2 page table page address that is not >> in the TLB. The TLB invalid handler had to be extensively modified but >> in the end came out much cleaner. >> >> I have tested this on a uni and multi-processor Sibyte with 1GB of >> memory. It would be useful if this patch had some independent testing >> as well. >> >> Please review. >> >> http://people.freebsd.org/~neel/mips_beyond_kseg.diff > > This fixes the crash I was seeing during 'make -j16 buildworld' on > XLR. The buildworld completed after running about 6 hours over NFS > mounted src and obj dir, so the patch looks good. I haven't done any > performance comparisons yet. > Thanks a lot for taking the time and effort to test this - much appreciated. best Neel > JC. > From owner-freebsd-mips@FreeBSD.ORG Fri Mar 19 19:48:19 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B387106566B for ; Fri, 19 Mar 2010 19:48:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id EB1F88FC12 for ; Fri, 19 Mar 2010 19:48:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o2JJi67R082720; Fri, 19 Mar 2010 13:44:06 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 19 Mar 2010 13:44:24 -0600 (MDT) Message-Id: <20100319.134424.200754750132956859.imp@bsdimp.com> To: neelnatu@gmail.com From: "M. Warner Losh" In-Reply-To: References: <98a59be81003190518h32b118d3t79927954c92f933a@mail.gmail.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: PATCH: enable use of memory beyond kseg0 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 19:48:19 -0000 In message: Neel Natu writes: : Hi JC, : : On Fri, Mar 19, 2010 at 5:18 AM, C. Jayachandran : wrote: : > On Tue, Mar 16, 2010 at 7:05 AM, Neel Natu wrote: : >> This patch enables use of physical memory that is beyond the direct : >> mapped kseg0 region. : >> : >> The basic idea is to use KVA from the kseg2 region for mapping page : >> table pages that lie beyond the direct mapped region. : >> : >> The TLB miss handler can now recursively fault into the TLB invalid : >> handler if it dereferences a kseg2 page table page address that is not : >> in the TLB. The TLB invalid handler had to be extensively modified but : >> in the end came out much cleaner. : >> : >> I have tested this on a uni and multi-processor Sibyte with 1GB of : >> memory. It would be useful if this patch had some independent testing : >> as well. : >> : >> Please review. : >> : >> http://people.freebsd.org/~neel/mips_beyond_kseg.diff : > : > This fixes the crash I was seeing during 'make -j16 buildworld' on : > XLR. The buildworld completed after running about 6 hours over NFS : > mounted src and obj dir, so the patch looks good. I haven't done any : > performance comparisons yet. : > : : Thanks a lot for taking the time and effort to test this - much appreciated. I think you can go ahead and commit it. My eyeball review makes me think it will work. I've not had a chance to try them out on my Octeon board, but don't let my lack of time hold this up now that we know it helps XLR. Warner