From owner-freebsd-embedded@FreeBSD.ORG Mon Dec 24 11:06:55 2007 Return-Path: Delivered-To: freebsd-embedded@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94EED16A4E8 for ; Mon, 24 Dec 2007 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7672F13C4E7 for ; Mon, 24 Dec 2007 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBOB6tn0031887 for ; Mon, 24 Dec 2007 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lBOB6srG031883 for freebsd-embedded@FreeBSD.org; Mon, 24 Dec 2007 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Dec 2007 11:06:54 GMT Message-Id: <200712241106.lBOB6srG031883@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 11:06:55 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o misc/15876 embedded [picobsd] PicoBSD message of the day problems o misc/28255 embedded [picobsd] picobsd documentation still references old . o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c f misc/52255 embedded [picobsd] picobsd build script fails under FreeBSD 5.0 o misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/101228 embedded [nanobsd] [patch] Two more entries for FlashDevice.sub 6 problems total. From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 10:36:52 2007 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF05316A417 for ; Fri, 28 Dec 2007 10:36:52 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fep01.xtra.co.nz (fep01.xtra.co.nz [210.54.141.245]) by mx1.freebsd.org (Postfix) with ESMTP id 6A14813C45B for ; Fri, 28 Dec 2007 10:36:52 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fep03.xtra.co.nz ([172.23.12.31]) by mta01.xtra.co.nz with ESMTP id <20071228100342.PPDB22521.mta01.xtra.co.nz@fep03.xtra.co.nz> for ; Fri, 28 Dec 2007 23:03:42 +1300 Received: from serv.int.fubar.geek.nz ([219.89.107.40]) by fep03.xtra.co.nz with ESMTP id <20071228100342.QCKN18083.fep03.xtra.co.nz@serv.int.fubar.geek.nz> for ; Fri, 28 Dec 2007 23:03:42 +1300 Date: Fri, 28 Dec 2007 23:03:41 +1300 From: Andrew Turner To: FreeBSD Embedded Message-ID: <20071228230341.1d78aa91@hermies.int.fubar.geek.nz> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.3; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: FreeBSD NAND driver X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 10:36:53 -0000 I'm working on porting FreeBSD to an embedded device that stores it's root file system on NAND flash. I am looking for a copy of the NAND driver John Birrell wrote if anyone has it or can point me to it. A search only found references to the existence of the driver but no pointers to where to find it. Andrew -- Andrew Turner http://fubar.geek.nz/blog/ From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 16:03:52 2007 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5074116A474 for ; Fri, 28 Dec 2007 16:03:52 +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 D770413C4EA for ; Fri, 28 Dec 2007 16:03:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSFxC4o073900; Fri, 28 Dec 2007 08:59:14 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 09:03:57 -0700 (MST) Message-Id: <20071228.090357.1649771318.imp@bsdimp.com> To: andrew@fubar.geek.nz From: "M. Warner Losh" In-Reply-To: <20071228230341.1d78aa91@hermies.int.fubar.geek.nz> References: <20071228230341.1d78aa91@hermies.int.fubar.geek.nz> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@freebsd.org Subject: Re: FreeBSD NAND driver X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 16:03:52 -0000 In message: <20071228230341.1d78aa91@hermies.int.fubar.geek.nz> Andrew Turner writes: : I'm working on porting FreeBSD to an embedded device that stores it's : root file system on NAND flash. : : I am looking for a copy of the NAND driver John Birrell wrote if anyone : has it or can point me to it. A search only found references to the : existence of the driver but no pointers to where to find it. Timing Solutions updated this driver to work better on 5.3R. However, the driver did have a lot of specific code for the i586 board that it was running on. It might make a good base for work, but if you don't have an Elan CPU, it will be a fair amount of work. Warner From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 17:10:18 2007 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C11316A419 for ; Fri, 28 Dec 2007 17:10:18 +0000 (UTC) (envelope-from olivier@gautherot.net) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id DD39013C4F5 for ; Fri, 28 Dec 2007 17:10:17 +0000 (UTC) (envelope-from olivier@gautherot.net) Received: by py-out-1112.google.com with SMTP id u77so6578070pyb.3 for ; Fri, 28 Dec 2007 09:10:14 -0800 (PST) Received: by 10.110.11.10 with SMTP id 10mr2104979tik.42.1198860132016; Fri, 28 Dec 2007 08:42:12 -0800 (PST) Received: by 10.70.53.11 with HTTP; Fri, 28 Dec 2007 08:42:11 -0800 (PST) Message-ID: Date: Fri, 28 Dec 2007 13:42:11 -0300 From: "Olivier Gautherot" To: "M. Warner Losh" , andrew@fubar.geek.nz, freebsd-embedded@freebsd.org In-Reply-To: <20071228.090357.1649771318.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071228230341.1d78aa91@hermies.int.fubar.geek.nz> <20071228.090357.1649771318.imp@bsdimp.com> Cc: Subject: Re: FreeBSD NAND driver X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 17:10:18 -0000 On 12/28/07, M. Warner Losh wrote: > In message: <20071228230341.1d78aa91@hermies.int.fubar.geek.nz> > Andrew Turner writes: > : I'm working on porting FreeBSD to an embedded device that stores it's > : root file system on NAND flash. > : > : I am looking for a copy of the NAND driver John Birrell wrote if anyone > : has it or can point me to it. A search only found references to the > : existence of the driver but no pointers to where to find it. > > Timing Solutions updated this driver to work better on 5.3R. However, > the driver did have a lot of specific code for the i586 board that > it was running on. It might make a good base for work, but if you > don't have an Elan CPU, it will be a fair amount of work. Well, I think whatever the solution is, there will be a fair amount of work anyway due to the type of bus - whether I/O based or memory-mapped. What devices do you plan to support? Cheers -- Olivier Gautherot olivier@gautherot.net Cel:+56 98 730 9361 www.gautherot.net http://www.linkedin.com/in/ogautherot From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 18:24:49 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 399C716A418 for ; Fri, 28 Dec 2007 18:24:49 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by mx1.freebsd.org (Postfix) with ESMTP id E2B9713C43E for ; Fri, 28 Dec 2007 18:24:48 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 10:24:01 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 10:10:47 -0800 Received: from mini-g4.jnpr.net (mini-g4.jnpr.net [172.24.104.164]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSIAv940852 for ; Fri, 28 Dec 2007 10:10:57 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: From: Marcel Moolenaar To: embedded@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 10:10:57 -0800 X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 18:10:47.0266 (UTC) FILETIME=[F86C0420:01C8497C] Cc: Subject: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 18:24:49 -0000 All, As part of the PowerPC e500 port we created an ocpbus (On-Chip Peripheral bus), with devices likes uart(4). This, of course, is perfectly normal. In fact, it's so normal that I wondered why we don't have a single abstract bus already. What I'm thinking about is a handshake between bus driver and device drivers that makes it possible for us to create a single (abstract) bus attachment per driver, usable whenever that particular driver is used in an embedded environment. The main part of the handshake seems to be the means for a driver to probe/match the hardware. In our implementation of ocpbus(4), we use an IVAR for the device type, as in: parent = device_get_parent(dev); error = BUS_READ_IVAR(parent, dev, OCPBUS_IVAR_DEVTYPE, &devtype); if (error) return (error); if (devtype != OCPBUS_DEVTYPE_PCIB) return (ENXIO); Since we only have 1 PCI-host controller driver to worry about, this is perfectly fine. However, if we want to generalize, then we probably need to extend the handshake to support different classes. Take for example an USB host controller. With EHCI, there's always at least 1 companion host controller (either OHCI or UHCI). Thus, checking if OCPBUS_DEVTYPE equals OCPBUS_DEVTYPE_USB (or something along those lines) is not enough. We need to know if it's an EHCI, OHCI or UHCI host controller. Anyway... Q1: Do people think it's worthwhile to pursue a generic ocpbus(4) definition? Q2: Is there a better handshake possible than IVARs? Q3: For probing, would DEVTYPE and DEVCLASS suffice or do we need something more or something else? Q4: What is minimally needed if we want to re-implement existing embedded busses using ocpbus(4)? Q5: Thoughts? Q6: Suggestions? Thanks, -- Marcel Moolenaar marcelm@juniper.net From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 18:27:53 2007 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 309A316A418 for ; Fri, 28 Dec 2007 18:27:53 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (w.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id 0736913C459 for ; Fri, 28 Dec 2007 18:27:41 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id lBSHu4Di077499; Fri, 28 Dec 2007 10:56:04 -0700 (MST) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.2/8.14.2) with ESMTP id lBSHtxiV081789; Fri, 28 Dec 2007 10:55:59 -0700 (MST) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.2/8.14.2/Submit) id lBSHtx6Y081786; Fri, 28 Dec 2007 10:55:59 -0700 (MST) (envelope-from jhein) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="lF16HUZL/7" Content-Transfer-Encoding: 7bit Message-ID: <18293.14511.208655.904627@gromit.timing.com> Date: Fri, 28 Dec 2007 10:55:59 -0700 From: John E Hein To: "M. Warner Losh" In-Reply-To: <20071228.090357.1649771318.imp@bsdimp.com> References: <20071228230341.1d78aa91@hermies.int.fubar.geek.nz> <20071228.090357.1649771318.imp@bsdimp.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: andrew@fubar.geek.nz, freebsd-embedded@freebsd.org Subject: Re: FreeBSD NAND driver X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 18:27:53 -0000 --lF16HUZL/7 Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit M. Warner Losh wrote at 09:03 -0700 on Dec 28, 2007: > In message: <20071228230341.1d78aa91@hermies.int.fubar.geek.nz> > Andrew Turner writes: > : I'm working on porting FreeBSD to an embedded device that stores it's > : root file system on NAND flash. > : > : I am looking for a copy of the NAND driver John Birrell wrote if anyone > : has it or can point me to it. A search only found references to the > : existence of the driver but no pointers to where to find it. > > Timing Solutions updated this driver to work better on 5.3R. However, > the driver did have a lot of specific code for the i586 board that > it was running on. It might make a good base for work, but if you > don't have an Elan CPU, it will be a fair amount of work. Here is the driver that we got from jb@ in early 2004. This was before Timing Solutions (Warner) made changes to work with different hardware. --lF16HUZL/7-- From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 18:46:09 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4536716A419 for ; Fri, 28 Dec 2007 18:46:09 +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 D0C6813C44B for ; Fri, 28 Dec 2007 18:46:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSIfCBq075507; Fri, 28 Dec 2007 11:41:13 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 11:45:59 -0700 (MST) Message-Id: <20071228.114559.-311937481.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 18:46:09 -0000 In message: Marcel Moolenaar writes: : All, : : As part of the PowerPC e500 port we created an ocpbus : (On-Chip Peripheral bus), with devices likes uart(4). : This, of course, is perfectly normal. In fact, it's so : normal that I wondered why we don't have a single : abstract bus already. : : What I'm thinking about is a handshake between bus : driver and device drivers that makes it possible for : us to create a single (abstract) bus attachment per : driver, usable whenever that particular driver is : used in an embedded environment. : : The main part of the handshake seems to be the means : for a driver to probe/match the hardware. In our : implementation of ocpbus(4), we use an IVAR for the : device type, as in: : : parent = device_get_parent(dev); : error = BUS_READ_IVAR(parent, dev, OCPBUS_IVAR_DEVTYPE, : &devtype); : if (error) : return (error); : if (devtype != OCPBUS_DEVTYPE_PCIB) : return (ENXIO); : : Since we only have 1 PCI-host controller driver to : worry about, this is perfectly fine. However, if we : want to generalize, then we probably need to extend : the handshake to support different classes. Take : for example an USB host controller. With EHCI, there's : always at least 1 companion host controller (either : OHCI or UHCI). Thus, checking if OCPBUS_DEVTYPE equals : OCPBUS_DEVTYPE_USB (or something along those lines) is : not enough. We need to know if it's an EHCI, OHCI or : UHCI host controller. This is why I don't think it will work. The child device shouldn't be checking to see if it is the right type or not. : Q1: Do people think it's worthwhile to pursue a generic : ocpbus(4) definition? Generally, yes. In fact, I've done a bunch of things with what I've called obio (On Board I/O) that does similar things, but relies entirely on hints to do the job. Since that's how we do things elsewhere, this seems like a reasonable approach. If we move to doing things differently, then we can talk about that. I implemented obio as a set of routines rather than as a bus itself, since doing the bus generically is going to be nearly impossible. There's too many fussy bits of logic for this SoC or that SoC that need to be in code. : Q2: Is there a better handshake possible than IVARs? Have the bus say "I have this or that on it" rather than having the drivers themselves try to match. That way lies madness, I think, since you'll soon wind up with lots of platform specific code infecting the generic device drivers. : Q3: For probing, would DEVTYPE and DEVCLASS suffice or : do we need something more or something else? Is this supposed to be a 'generic' replacement for the product/vendor stuff ala pci or something else? I'm not sure that we can uniquely do this in a generic enough way. : Q4: What is minimally needed if we want to re-implement : existing embedded busses using ocpbus(4)? The atmel at91 code is moving in this direction in p4, but uses the obio routines I wrote. : Q5: Thoughts? : Q6: Suggestions? Warner From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 19:13:07 2007 Return-Path: Delivered-To: embedded@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09A0016A41B for ; Fri, 28 Dec 2007 19:13: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 A750813C465 for ; Fri, 28 Dec 2007 19:13:06 +0000 (UTC) (envelope-from imp@BSDIMP.COM) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSJ7Q0Z075776; Fri, 28 Dec 2007 12:07:27 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 12:12:13 -0700 (MST) Message-Id: <20071228.121213.-494094613.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: <20071228.114559.-311937481.imp@bsdimp.com> References: <20071228.114559.-311937481.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@FreeBSD.ORG Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 19:13:07 -0000 In message: <20071228.114559.-311937481.imp@bsdimp.com> "M. Warner Losh" writes: : In message: : Marcel Moolenaar writes: : : All, : : : : As part of the PowerPC e500 port we created an ocpbus : : (On-Chip Peripheral bus), with devices likes uart(4). : : This, of course, is perfectly normal. In fact, it's so : : normal that I wondered why we don't have a single : : abstract bus already. : : : : What I'm thinking about is a handshake between bus : : driver and device drivers that makes it possible for : : us to create a single (abstract) bus attachment per : : driver, usable whenever that particular driver is : : used in an embedded environment. : : : : The main part of the handshake seems to be the means : : for a driver to probe/match the hardware. In our : : implementation of ocpbus(4), we use an IVAR for the : : device type, as in: : : : : parent = device_get_parent(dev); : : error = BUS_READ_IVAR(parent, dev, OCPBUS_IVAR_DEVTYPE, : : &devtype); : : if (error) : : return (error); : : if (devtype != OCPBUS_DEVTYPE_PCIB) : : return (ENXIO); : : : : Since we only have 1 PCI-host controller driver to : : worry about, this is perfectly fine. However, if we : : want to generalize, then we probably need to extend : : the handshake to support different classes. Take : : for example an USB host controller. With EHCI, there's : : always at least 1 companion host controller (either : : OHCI or UHCI). Thus, checking if OCPBUS_DEVTYPE equals : : OCPBUS_DEVTYPE_USB (or something along those lines) is : : not enough. We need to know if it's an EHCI, OHCI or : : UHCI host controller. : : This is why I don't think it will work. The child device shouldn't be : checking to see if it is the right type or not. : : : Q1: Do people think it's worthwhile to pursue a generic : : ocpbus(4) definition? : : Generally, yes. In fact, I've done a bunch of things with what I've : called obio (On Board I/O) that does similar things, but relies : entirely on hints to do the job. Since that's how we do things : elsewhere, this seems like a reasonable approach. If we move to doing : things differently, then we can talk about that. : : I implemented obio as a set of routines rather than as a bus itself, : since doing the bus generically is going to be nearly impossible. : There's too many fussy bits of logic for this SoC or that SoC that : need to be in code. : : : Q2: Is there a better handshake possible than IVARs? : : Have the bus say "I have this or that on it" rather than having the : drivers themselves try to match. That way lies madness, I think, : since you'll soon wind up with lots of platform specific code : infecting the generic device drivers. : : : Q3: For probing, would DEVTYPE and DEVCLASS suffice or : : do we need something more or something else? : : Is this supposed to be a 'generic' replacement for the product/vendor : stuff ala pci or something else? I'm not sure that we can uniquely do : this in a generic enough way. : : : Q4: What is minimally needed if we want to re-implement : : existing embedded busses using ocpbus(4)? : : The atmel at91 code is moving in this direction in p4, but uses the : obio routines I wrote. : : : Q5: Thoughts? : : Q6: Suggestions? A couple more thoughts: We can't have one generic bus for all the processors. But we maybe able to do the subclassing we do with PCI/Cardbus. We'd have to fix a couple of corner cases relating to device driver loading, but once those are fixed, we could have a generic base class. However, we're always going to need to specialize for two reasons. First, the on board devices are always attached in ways that require intimate knowledge of the board/soc. Sometimes this is which resources to give and what interrupts to use. Other times it can be what clocks to enable, or what GPIO pins are needed. Sometimes the devices in question need to do different things for different processors, even if the core of the driver is shared (like the ohci usb controller in the atmel vs in the Cirrus logic arm9). So we'll still need to have some specialization. If the ocpbus has a table of bus types, what's wrong with having it directly assign the driver when it ads its children? That would eliminate the probe part of child driver's routine, making it simpler to write. There are also some on board busses that are self enumerating (ARM defines a standard, and there's at least one similar standard used by some Broadcom MIPS chips). So any solution likely would need to take both models into account. I guess I agree with you that we need an abstraction layer, but quibble over the details. I especially object to creating an enumeration where an actual device driver name would do. Plus the problem is complicated because none of these devices is standard. Sorry if my first reply came on a little strong on the enumeration point. If there is a compelling argument for it, I'll listen, but it isn't as if we have competing drivers for devices in this domain like we did with sio vs uart. Warner From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 19:17:49 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7395716A419 for ; Fri, 28 Dec 2007 19:17:49 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by mx1.freebsd.org (Postfix) with ESMTP id 259D213C45B for ; Fri, 28 Dec 2007 19:17:49 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 11:17:15 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 11:16:39 -0800 Received: from mini-g4.jnpr.net (aparmelee-t41.jnpr.net [172.24.104.164] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSJGh955854; Fri, 28 Dec 2007 11:16:45 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.114559.-311937481.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 11:16:43 -0800 References: <20071228.114559.-311937481.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 19:16:39.0598 (UTC) FILETIME=[2C3204E0:01C84986] Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 19:17:49 -0000 On Dec 28, 2007, at 10:45 AM, M. Warner Losh wrote: > : The main part of the handshake seems to be the means > : for a driver to probe/match the hardware. In our > : implementation of ocpbus(4), we use an IVAR for the > : device type, as in: > : > : parent = device_get_parent(dev); > : error = BUS_READ_IVAR(parent, dev, OCPBUS_IVAR_DEVTYPE, > : &devtype); > : if (error) > : return (error); > : if (devtype != OCPBUS_DEVTYPE_PCIB) > : return (ENXIO); > : > : Since we only have 1 PCI-host controller driver to > : worry about, this is perfectly fine. However, if we > : want to generalize, then we probably need to extend > : the handshake to support different classes. Take > : for example an USB host controller. With EHCI, there's > : always at least 1 companion host controller (either > : OHCI or UHCI). Thus, checking if OCPBUS_DEVTYPE equals > : OCPBUS_DEVTYPE_USB (or something along those lines) is > : not enough. We need to know if it's an EHCI, OHCI or > : UHCI host controller. > > This is why I don't think it will work. The child device shouldn't be > checking to see if it is the right type or not. But that's how PCI works: the hardware has a vendor and device Id and the driver checks for combinations that it knows it can work with. Translated into IVARs, that means that there's a device tree or device list that mentions the existence of some DEVTYPE and DEVCLASS which the bus driver makes available through the IVARs and the driver checks if it's something it knows it can handle and attaches to the device of it does. > : Q1: Do people think it's worthwhile to pursue a generic > : ocpbus(4) definition? > > Generally, yes. In fact, I've done a bunch of things with what I've > called obio (On Board I/O) that does similar things, but relies > entirely on hints to do the job. Since that's how we do things > elsewhere, this seems like a reasonable approach. If we move to doing > things differently, then we can talk about that. Hints can be used to implement the device tree or device list, but is rather limited. I'd like us to implement something richer in the future. For that reason I don't want to expose hints to the driver, but rather abstract the implementation of the device tree or the device list behind IVARs. That makes it possible to implement the "bus" in many different ways without having to change the device drivers that attach to the bus. > I implemented obio as a set of routines rather than as a bus itself, > since doing the bus generically is going to be nearly impossible. > There's too many fussy bits of logic for this SoC or that SoC that > need to be in code. An abstract bus is just a means for devices to attach to. There's a bus driver component behind it, but that can be nexus(4) itself. The main purpose is to allow a single bus attachment to be used in various and many ways, so as to limit the flurry of single-use and one-off bus attachments. A single generic "bus" that does not imply anything about the underlying hardware or means of enumeration is the most flexible. > : Q2: Is there a better handshake possible than IVARs? > > Have the bus say "I have this or that on it" rather than having the > drivers themselves try to match. That way lies madness, I think, > since you'll soon wind up with lots of platform specific code > infecting the generic device drivers. Can you elaborate. I don't quite follow you. > : Q3: For probing, would DEVTYPE and DEVCLASS suffice or > : do we need something more or something else? > > Is this supposed to be a 'generic' replacement for the product/vendor > stuff ala pci or something else? I'm not sure that we can uniquely do > this in a generic enough way. Yes, it's akin to the vendor/product pair that PCI uses. As for being generic: I don't think we can account for every possible hardware upfront. What I think will work is something that can be extended. For example, for async serial hardware, DEVTYPE equals UART. For the various chips, DEVCLASS can be set accordingly. So, for standard PC hardware DEVCLASS equals NS8250. Since DEVTYPE and DEVCLASS are just numbers, we can add as many types and classes as we need. If we need to support a new network interface, we add it to DEVCLASS (DEVTYPE being NETIF or something). Existing drivers that only check DEVTYPE (which I'm sure we'll start with) will have to check DEVCLASS as well if there's going to be variation within DEVTYPE. > : Q4: What is minimally needed if we want to re-implement > : existing embedded busses using ocpbus(4)? > > The atmel at91 code is moving in this direction in p4, but uses the > obio routines I wrote. I'll take a look at obio. It seems to overlap in function with what I intend to do with ocpbus, so we may be able to turn obio into ocpbus or vice versa. -- Marcel Moolenaar marcelm@juniper.net From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 19:18:19 2007 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74A6316A418 for ; Fri, 28 Dec 2007 19:18:19 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id 4EB0E13C4D5 for ; Fri, 28 Dec 2007 19:18:18 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id CCCEF61B114; Fri, 28 Dec 2007 11:18:16 -0800 (PST) Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03853-07; Fri, 28 Dec 2007 11:18:15 -0800 (PST) Received: from iago.office.miralink.com (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id BDBD861B10A; Fri, 28 Dec 2007 11:18:15 -0800 (PST) Message-ID: <47754BF7.7000603@miralink.com> Date: Fri, 28 Dec 2007 11:18:15 -0800 From: Sean Bruno User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: John E Hein References: <20071228230341.1d78aa91@hermies.int.fubar.geek.nz> <20071228.090357.1649771318.imp@bsdimp.com> <18293.14511.208655.904627@gromit.timing.com> In-Reply-To: <18293.14511.208655.904627@gromit.timing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Dec 28 11:18:16 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 47754bf827601214584237 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.499 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, AWL=-0.000, BAYES_00=-2.599, DSPAM_HAM=-0.1] X-Spam-Score: -4.499 X-Spam-Level: Cc: andrew@fubar.geek.nz, freebsd-embedded@freebsd.org Subject: Re: FreeBSD NAND driver X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 19:18:19 -0000 John E Hein wrote: > M. Warner Losh wrote at 09:03 -0700 on Dec 28, 2007: > > In message: <20071228230341.1d78aa91@hermies.int.fubar.geek.nz> > > Andrew Turner writes: > > : I'm working on porting FreeBSD to an embedded device that stores it's > > : root file system on NAND flash. > > : > > : I am looking for a copy of the NAND driver John Birrell wrote if anyone > > : has it or can point me to it. A search only found references to the > > : existence of the driver but no pointers to where to find it. > > > > Timing Solutions updated this driver to work better on 5.3R. However, > > the driver did have a lot of specific code for the i586 board that > > it was running on. It might make a good base for work, but if you > > don't have an Elan CPU, it will be a fair amount of work. > > Here is the driver that we got from jb@ in early 2004. This was > before Timing Solutions (Warner) made changes to work with different > hardware. > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org" > It looks to me like the attachment was stripped. Can you post it somewhere web accessible? Sean From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 19:31:05 2007 Return-Path: Delivered-To: embedded@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DDB216A41B for ; Fri, 28 Dec 2007 19:31:05 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by mx1.freebsd.org (Postfix) with ESMTP id 2B93713C458 for ; Fri, 28 Dec 2007 19:31:05 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 11:30:31 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 11:30:49 -0800 Received: from mini-g4.jnpr.net (nbaseer-t43.jnpr.net [172.24.104.164] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSJUx959123; Fri, 28 Dec 2007 11:30:59 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.121213.-494094613.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 11:30:59 -0800 References: <20071228.114559.-311937481.imp@bsdimp.com> <20071228.121213.-494094613.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 19:30:49.0316 (UTC) FILETIME=[26AAB240:01C84988] Cc: embedded@FreeBSD.ORG Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 19:31:05 -0000 On Dec 28, 2007, at 11:12 AM, M. Warner Losh wrote: > If the ocpbus has a table of bus types, what's wrong with having it > directly assign the driver when it ads its children? It violates newbus in that drivers compete for a device. If the bus assigns the driver, then there's no competition possible. The fact that the bus is abstract should not mean that we should change its paradigm. > I guess I agree with you that we need an abstraction layer, but > quibble over the details. I especially object to creating an > enumeration where an actual device driver name would do. Agreed. We should not use device driver names. We could use strings instead of numbers, but other than that it's an abstract name or number that. > Plus the > problem is complicated because none of these devices is standard. > Sorry if my first reply came on a little strong on the enumeration > point. If there is a compelling argument for it, I'll listen, but it > isn't as if we have competing drivers for devices in this domain like > we did with sio vs uart. We should not abandon competition, because that would be a step away from generalization. Even though we're discussing this in the context of embedded systems, I don't see any reason why it couldn't equally apply to the LPC devices in PCs that are enumerated by ACPI... True, competition is not likely to be a often-used feature in an embedded system but modules may be and it's so much easier to deal with modules if you keep the existing paradigm and not have the bus driver assign device drivers. For in that case the bus driver need to be made aware that a new device driver was loaded and see if it's one it can assign to a device. -- Marcel Moolenaar marcelm@juniper.net From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 19:52:05 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3EFD16A417 for ; Fri, 28 Dec 2007 19:52:05 +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 44DD413C44B for ; Fri, 28 Dec 2007 19:52:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSJjWLn076231; Fri, 28 Dec 2007 12:45:33 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 12:50:20 -0700 (MST) Message-Id: <20071228.125020.-1962668065.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: References: <20071228.114559.-311937481.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 19:52:05 -0000 In message: Marcel Moolenaar writes: : : On Dec 28, 2007, at 10:45 AM, M. Warner Losh wrote: : : > : The main part of the handshake seems to be the means : > : for a driver to probe/match the hardware. In our : > : implementation of ocpbus(4), we use an IVAR for the : > : device type, as in: : > : : > : parent = device_get_parent(dev); : > : error = BUS_READ_IVAR(parent, dev, OCPBUS_IVAR_DEVTYPE, : > : &devtype); : > : if (error) : > : return (error); : > : if (devtype != OCPBUS_DEVTYPE_PCIB) : > : return (ENXIO); : > : : > : Since we only have 1 PCI-host controller driver to : > : worry about, this is perfectly fine. However, if we : > : want to generalize, then we probably need to extend : > : the handshake to support different classes. Take : > : for example an USB host controller. With EHCI, there's : > : always at least 1 companion host controller (either : > : OHCI or UHCI). Thus, checking if OCPBUS_DEVTYPE equals : > : OCPBUS_DEVTYPE_USB (or something along those lines) is : > : not enough. We need to know if it's an EHCI, OHCI or : > : UHCI host controller. : > : > This is why I don't think it will work. The child device shouldn't be : > checking to see if it is the right type or not. : : But that's how PCI works: the hardware has a vendor : and device Id and the driver checks for combinations : that it knows it can work with. Translated into IVARs, : that means that there's a device tree or device list : that mentions the existence of some DEVTYPE and DEVCLASS : which the bus driver makes available through the IVARs : and the driver checks if it's something it knows it can : handle and attaches to the device of it does. Right, but in PCI land the drivers know what devices they support and the bus has no knowledge of that. In PCI land each device has something you can query to find out what it is. In SoC land, such luxaries are the exception rather than the rule. The driver for a specific SoC would know what hardware is there. : > : Q1: Do people think it's worthwhile to pursue a generic : > : ocpbus(4) definition? : > : > Generally, yes. In fact, I've done a bunch of things with what I've : > called obio (On Board I/O) that does similar things, but relies : > entirely on hints to do the job. Since that's how we do things : > elsewhere, this seems like a reasonable approach. If we move to doing : > things differently, then we can talk about that. : : Hints can be used to implement the device tree or : device list, but is rather limited. I'd like us to : implement something richer in the future. For that : reason I don't want to expose hints to the driver, : but rather abstract the implementation of the device : tree or the device list behind IVARs. That makes it : possible to implement the "bus" in many different : ways without having to change the device drivers that : attach to the bus. But hints aren't exported to the drivers now. Having the ivars like you suggest is more invasive into the drivers. We shouldn't be designing for future, possible ideas, but rather working in the current framework. If you'd like to design a future framework and implement that then implement this, that would be one thing. Using the subclassing stuff I talked about, one can actually implement driver code that is fairly generic. However, most of the time, the generic devices are extremely limited. Usually just a 16550-like device mapped into the hardware in what usually is a unique way (4 byte aligned registers here, packed registers there, 8 byte aligned registers over there). : > I implemented obio as a set of routines rather than as a bus itself, : > since doing the bus generically is going to be nearly impossible. : > There's too many fussy bits of logic for this SoC or that SoC that : > need to be in code. : : An abstract bus is just a means for devices to attach : to. There's a bus driver component behind it, but that : can be nexus(4) itself. The main purpose is to allow a : single bus attachment to be used in various and many : ways, so as to limit the flurry of single-use and one-off : bus attachments. A single generic "bus" that does not : imply anything about the underlying hardware or means : of enumeration is the most flexible. That sounds like we should implement bio as a baseclass for other busses to derive from. That would allow a more generic way for the simple devices as well as a more complicated way for the more complicated devices (like ohci implementations, GPIO pings for this or that, etc). : > : Q2: Is there a better handshake possible than IVARs? : > : > Have the bus say "I have this or that on it" rather than having the : > drivers themselves try to match. That way lies madness, I think, : > since you'll soon wind up with lots of platform specific code : > infecting the generic device drivers. : : Can you elaborate. I don't quite follow you. I think that any enumeration of devtype/devclass will likely result in a situation that's either too generic to be useful, or is so specific that one might as well just encode the device <-> driver names and be done with it and not introduce an extra level of indirection. : > : Q3: For probing, would DEVTYPE and DEVCLASS suffice or : > : do we need something more or something else? : > : > Is this supposed to be a 'generic' replacement for the product/vendor : > stuff ala pci or something else? I'm not sure that we can uniquely do : > this in a generic enough way. : : Yes, it's akin to the vendor/product pair that PCI uses. : : As for being generic: I don't think we can account for : every possible hardware upfront. What I think will work : is something that can be extended. For example, for : async serial hardware, DEVTYPE equals UART. For the : various chips, DEVCLASS can be set accordingly. So, for : standard PC hardware DEVCLASS equals NS8250. Since : DEVTYPE and DEVCLASS are just numbers, we can add as : many types and classes as we need. If we need to support : a new network interface, we add it to DEVCLASS (DEVTYPE : being NETIF or something). I don't think there's much value in DEVTYPE in that case. UART is a useless designation if you don't know what kind of uart, and if you are told it is a NS8250, then you know you support it without having to look at DEVTYPE. NETIF is similar. And these busses usually have lots of other, auxiliary devices hanging off of them. SPI controllers, MMC/SD controllers, generic (in the hardware signal sense) synchronous serial controllers, etc. There's usually very little in common between an ATMEL SPI controller and one from Cirrus Logic. The DEVTYPE typically would be unused. And we'd have to have a seprate DEVCLASS for every type of SoC device. But we're already creating drivers for these devices, so why not use the driver name directly. There's a very strong coupling between the device and the driver in the embedded realm (and usually some 'leakage' from other devices as well, since things aren't quite as orthogonal as in the PC world). I'm trying to piece together in my mind how DEVCLASS would work for one of the Atmel processors I know so well. In it there's one device shared with the PC (an ohci that needs to have some things allocated in a slightly funky way), and then a bunch of devices that exist only in this SoC and other SoCs from Atmel (ARM7, ARM9 and AVR32): USART, MCI, TWI, SSC, etc. The USART driver is implemented using the uart framework. The other drivers are fully custom jobs that provide I2C or MMC/SD hooks for those subsystems (or just a bunch of ioctls/read/write interfaces). : Existing drivers that only check DEVTYPE (which I'm sure : we'll start with) will have to check DEVCLASS as well if : there's going to be variation within DEVTYPE. Are there existing drivers right now? FreeBSD has two models for device enumeration. One is where the parent bus decides, by whatever means, and one where the device itself has enough information to allow the driver to decide. I think that trying to shoe-horn the second model into a situation where the first model is actually better would be a disservice. We can argue about where/how to create the tables for things, but I think we'd both agree that we'd have to have some table somewhere for these devices. Or some set of tables that gets selected at runtime. : > : Q4: What is minimally needed if we want to re-implement : > : existing embedded busses using ocpbus(4)? : > : > The atmel at91 code is moving in this direction in p4, but uses the : > obio routines I wrote. : : I'll take a look at obio. It seems to overlap in function : with what I intend to do with ocpbus, so we may be able : to turn obio into ocpbus or vice versa. I think so too. The obio stuff is in the devel-arm branch in p4 (//depot/project/arm) in sys/kern/subr_obio.c It could be improved, no doubt, but does handle most of the common cases of resource allocation that were being duplicated all over the place. If we wanted to create a subclassable ocpbus out of it, that might be worthwhile. Warner From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:04:25 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7280916A41B for ; Fri, 28 Dec 2007 20:04:25 +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 12C1A13C467 for ; Fri, 28 Dec 2007 20:04:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSJwgZx076365; Fri, 28 Dec 2007 12:58:42 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 13:03:29 -0700 (MST) Message-Id: <20071228.130329.43010549.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: References: <20071228.114559.-311937481.imp@bsdimp.com> <20071228.121213.-494094613.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 20:04:25 -0000 In message: Marcel Moolenaar writes: : On Dec 28, 2007, at 11:12 AM, M. Warner Losh wrote: : : > If the ocpbus has a table of bus types, what's wrong with having it : > directly assign the driver when it ads its children? : : It violates newbus in that drivers compete for a device. : If the bus assigns the driver, then there's no competition : possible. The fact that the bus is abstract should not : mean that we should change its paradigm. No it doesn't. There's two kinds of busses in newbus. Those that self enumerate based on the hardware present (ie pccard, pci, usb, firewire) and then those that are told what's there (oldcard-style pccard, pure ISA, I2C, etc). The busses on the SoC more strongly resemble the latter than the former. The former busses already are enumerated with hints, but the actual mechanism is just a few calls that could be replaced with something better. : > I guess I agree with you that we need an abstraction layer, but : > quibble over the details. I especially object to creating an : > enumeration where an actual device driver name would do. : : Agreed. We should not use device driver names. We could use : strings instead of numbers, but other than that it's an : abstract name or number that. : : > Plus the : > problem is complicated because none of these devices is standard. : > Sorry if my first reply came on a little strong on the enumeration : > point. If there is a compelling argument for it, I'll listen, but it : > isn't as if we have competing drivers for devices in this domain like : > we did with sio vs uart. : : We should not abandon competition, because that would : be a step away from generalization. Even though we're : discussing this in the context of embedded systems, : I don't see any reason why it couldn't equally apply to : the LPC devices in PCs that are enumerated by ACPI... That's a different case. Do not confuse these cases. ACPI has a table of devices that associated resources with an ID. There's no such tables in the SoC world, typically. At most, you have a CPU ID you can read and from that know, based on a hardwired set of tables, the devices that are present. It isn't extensible in any way when a new CPU ID comes along. With ACPI you'd get new devices and you wouldn't worry. With the new CPU ID in the SoC world, you'd get nothing until you created a new table. Any construction of an artificial device ID would likely just make it harder to write drivers for these platforms. Rather than just adding a driver and something to the table (hints, say) and having it work, one would have to also allocate a new device ID (one that might conflict with others doing similar work, causing integration problems later) as well as write code to test for that ID. I guess I don't see that many SoCs that have that many devices that are shared with others. 16550-like UARTs are about the only thing that has any big amount of commonality. The rest of the devices are specific to a chip or a small family of chips. Even the 16550 uarts are wired up differently and have different access requirements. : True, competition is not likely to be a often-used : feature in an embedded system but modules may be and : it's so much easier to deal with modules if you keep : the existing paradigm and not have the bus driver : assign device drivers. For in that case the bus driver : need to be made aware that a new device driver was : loaded and see if it's one it can assign to a device. They aren't incompatible at all. The device creates a node in the new bus tree that's assigned to "at91_twi" for instance. If there's no at91_twi driver loaded, then nothing happens. If one is later loaded, at91_twi will automatically probe that device. The name is what is important. When a module that implements a device of the right name is loaded, the right things happen. OLDCARD did this for years, and I've done it more recently with I2C stuff. If you load/unload drivers like this, it just works. You don't need competition for this to work. That doesn't answer the question of 'Is competition always needed?' but that's a point we differ on. Warner From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:10:00 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19E8516A417 for ; Fri, 28 Dec 2007 20:10:00 +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 C463513C467 for ; Fri, 28 Dec 2007 20:09:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSK4NCY076423; Fri, 28 Dec 2007 13:04:24 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 13:09:11 -0700 (MST) Message-Id: <20071228.130911.84364727.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: <20071228.130329.43010549.imp@bsdimp.com> References: <20071228.121213.-494094613.imp@bsdimp.com> <20071228.130329.43010549.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 20:10:00 -0000 In message: <20071228.130329.43010549.imp@bsdimp.com> "M. Warner Losh" writes: : In message: : Marcel Moolenaar writes: : : On Dec 28, 2007, at 11:12 AM, M. Warner Losh wrote: : : : : > If the ocpbus has a table of bus types, what's wrong with having it : : > directly assign the driver when it ads its children? : : : : It violates newbus in that drivers compete for a device. : : If the bus assigns the driver, then there's no competition : : possible. The fact that the bus is abstract should not : : mean that we should change its paradigm. : : No it doesn't. There's two kinds of busses in newbus. Those that : self enumerate based on the hardware present (ie pccard, pci, usb, : firewire) and then those that are told what's there (oldcard-style : pccard, pure ISA, I2C, etc). The busses on the SoC more strongly : resemble the latter than the former. The former busses already are : enumerated with hints, but the actual mechanism is just a few calls : that could be replaced with something better. Just a correction... 'The latter busses already are already..." From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:27:46 2007 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82A4716A417 for ; Fri, 28 Dec 2007 20:27:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 3A93413C4EA for ; Fri, 28 Dec 2007 20:27:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 226427182-1834499 for multiple; Fri, 28 Dec 2007 15:13:44 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id lBSKBQqA064381; Fri, 28 Dec 2007 15:11:26 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-embedded@freebsd.org Date: Fri, 28 Dec 2007 15:00:54 -0500 User-Agent: KMail/1.9.6 References: <20071228.114559.-311937481.imp@bsdimp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712281500.55155.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 28 Dec 2007 15:11:26 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5278/Fri Dec 28 11:55:36 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Marcel Moolenaar Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 20:27:46 -0000 On Friday 28 December 2007 02:16:43 pm Marcel Moolenaar wrote: > > : Q1: Do people think it's worthwhile to pursue a generic > > : ocpbus(4) definition? > > > > Generally, yes. In fact, I've done a bunch of things with what I've > > called obio (On Board I/O) that does similar things, but relies > > entirely on hints to do the job. Since that's how we do things > > elsewhere, this seems like a reasonable approach. If we move to doing > > things differently, then we can talk about that. > > Hints can be used to implement the device tree or > device list, but is rather limited. I'd like us to > implement something richer in the future. For that > reason I don't want to expose hints to the driver, > but rather abstract the implementation of the device > tree or the device list behind IVARs. That makes it > possible to implement the "bus" in many different > ways without having to change the device drivers that > attach to the bus. So to jump in here. I've been thinking more since the last hints debacle and am thinking of replacing hints with the generic device metadata we'd discussed some at the end of the last thread: device.FOO.= where any driver or unit wiring is a new property rather than encoded into FOO's name. Thus: device.COM1.at=isa0 device.COM1.irq=4 device.COM1.port=0x3f8 device.COM1.driver=sio device.COM1.unit=0 or some such. There would be a new-bus level framework to enumerate the various devices that have properties and bus drivers would "claim" a device and bind it to a child device_t. Each bus could then expose the properties as it saw fit. For example, if you had this: device.FOO.at=pci4.5.0 device.FOO.vendor=0x5555 device.FOO.device=0x1212 then the PCI bus could use that to override what gets returned via the vendor, device, and devid IVARs used in probing. You could still implement the bus_enumerate_hinted_children() API using this alternate backend. Also, fwiw I'm thinking of having a 'device' command in the loader that is a bit of a frontend so you can do things like: 'device COM1 at isa0 irq 4 console' that might translate into setting 'at=isa0', 'irq=4', 'console=1'. I also think there might be a generic way to get at any properties associated with a device_t by doing: int property_get_str(device_t dev, const char *name, char *buf, size_t buflen); int property_get_bool(device_t dev, const char *name, int *val); int property_get_int(device_t dev, const char *name, int *val); etc. Maybe devprop_* instead, but you get the idea. -- John Baldwin From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:30:51 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D505C16A418 for ; Fri, 28 Dec 2007 20:30:51 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by mx1.freebsd.org (Postfix) with ESMTP id 8330C13C448 for ; Fri, 28 Dec 2007 20:30:51 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 12:30:32 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 12:26:56 -0800 Received: from mini-g4.jnpr.net (bobbyg-pc.jnpr.net [172.24.104.164] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSKR6971758; Fri, 28 Dec 2007 12:27:06 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: <595F307F-8FC5-48D5-A69C-84660A768F23@juniper.net> From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.125020.-1962668065.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 12:27:06 -0800 References: <20071228.114559.-311937481.imp@bsdimp.com> <20071228.125020.-1962668065.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 20:26:56.0405 (UTC) FILETIME=[FD9BB450:01C8498F] Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 20:30:51 -0000 On Dec 28, 2007, at 11:50 AM, M. Warner Losh wrote: > : Existing drivers that only check DEVTYPE (which I'm sure > : we'll start with) will have to check DEVCLASS as well if > : there's going to be variation within DEVTYPE. > > Are there existing drivers right now? The e500 port uses ocpbus(4) and if we make it generic, I can merge it into CVS independently of the e500 code itself. > FreeBSD has two models for device enumeration. One is where the > parent bus decides, by whatever means, and one where the device itself > has enough information to allow the driver to decide. I think that > trying to shoe-horn the second model into a situation where the first > model is actually better would be a disservice. When would the first be better? -- Marcel Moolenaar marcelm@juniper.net From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:31:05 2007 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED0A616A417; Fri, 28 Dec 2007 20:31:05 +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 9800B13C4DD; Fri, 28 Dec 2007 20:31:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSKP4Gx076651; Fri, 28 Dec 2007 13:25:04 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 13:29:51 -0700 (MST) Message-Id: <20071228.132951.-432836769.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200712281500.55155.jhb@freebsd.org> References: <20071228.114559.-311937481.imp@bsdimp.com> <200712281500.55155.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: marcelm@juniper.net, freebsd-embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 20:31:06 -0000 In message: <200712281500.55155.jhb@freebsd.org> John Baldwin writes: : On Friday 28 December 2007 02:16:43 pm Marcel Moolenaar wrote: : > > : Q1: Do people think it's worthwhile to pursue a generic : > > : ocpbus(4) definition? : > > : > > Generally, yes. In fact, I've done a bunch of things with what I've : > > called obio (On Board I/O) that does similar things, but relies : > > entirely on hints to do the job. Since that's how we do things : > > elsewhere, this seems like a reasonable approach. If we move to doing : > > things differently, then we can talk about that. : > : > Hints can be used to implement the device tree or : > device list, but is rather limited. I'd like us to : > implement something richer in the future. For that : > reason I don't want to expose hints to the driver, : > but rather abstract the implementation of the device : > tree or the device list behind IVARs. That makes it : > possible to implement the "bus" in many different : > ways without having to change the device drivers that : > attach to the bus. : : So to jump in here. I've been thinking more since the last hints debacle and : am thinking of replacing hints with the generic device metadata we'd : discussed some at the end of the last thread: : : device.FOO.= : : where any driver or unit wiring is a new property rather than encoded into : FOO's name. Thus: : : device.COM1.at=isa0 : device.COM1.irq=4 : device.COM1.port=0x3f8 : device.COM1.driver=sio : device.COM1.unit=0 : : or some such. How does one separate the topological information from the proscriptive information? Eg, is the irq=4 an instruction to the driver to use IRQ 4 for the device (proscriptive), or is it an instruction to the bus to help locate COM1 (topological). : There would be a new-bus level framework to enumerate the various devices that : have properties and bus drivers would "claim" a device and bind it to a child : device_t. Each bus could then expose the properties as it saw fit. For : example, if you had this: : : device.FOO.at=pci4.5.0 : device.FOO.vendor=0x5555 : device.FOO.device=0x1212 Same question here. If the first one was 'device.FOO.at=pci' then what would the other two things mean, especially if there was a driver/unit forced for this device? : then the PCI bus could use that to override what gets returned via the vendor, : device, and devid IVARs used in probing. : : You could still implement the bus_enumerate_hinted_children() API using this : alternate backend. Assuming one could clear up the ambiguity, yes. : Also, fwiw I'm thinking of having a 'device' command in the loader that is a : bit of a frontend so you can do things like: : : 'device COM1 at isa0 irq 4 console' : : that might translate into setting 'at=isa0', 'irq=4', 'console=1'. Again, the same questions: what parts of this are topological and what parts proscriptive? : I also think there might be a generic way to get at any properties associated : with a device_t by doing: : : int property_get_str(device_t dev, const char *name, char *buf, : size_t buflen); : int property_get_bool(device_t dev, const char *name, int *val); : int property_get_int(device_t dev, const char *name, int *val); : : etc. : : Maybe devprop_* instead, but you get the idea. We already have similar interfaces to get the hinted properties... What would the translation be. Also, I think that even though this is mildly relevant for the ocpbus discussion, we shouldn't let ourselves get sidetracked by it. Warner From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:43:39 2007 Return-Path: Delivered-To: embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B3CD16A417 for ; Fri, 28 Dec 2007 20:43:39 +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 A3F3C13C45A for ; Fri, 28 Dec 2007 20:43:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSKb6Ns076818; Fri, 28 Dec 2007 13:37:09 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 13:41:54 -0700 (MST) Message-Id: <20071228.134154.1136083975.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: <595F307F-8FC5-48D5-A69C-84660A768F23@juniper.net> References: <20071228.125020.-1962668065.imp@bsdimp.com> <595F307F-8FC5-48D5-A69C-84660A768F23@juniper.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@FreeBSD.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 20:43:39 -0000 In message: <595F307F-8FC5-48D5-A69C-84660A768F23@juniper.net> Marcel Moolenaar writes: : : On Dec 28, 2007, at 11:50 AM, M. Warner Losh wrote: : : > : Existing drivers that only check DEVTYPE (which I'm sure : > : we'll start with) will have to check DEVCLASS as well if : > : there's going to be variation within DEVTYPE. : > : > Are there existing drivers right now? : : The e500 port uses ocpbus(4) and if we make it generic, : I can merge it into CVS independently of the e500 code : itself. True. : > FreeBSD has two models for device enumeration. One is where the : > parent bus decides, by whatever means, and one where the device itself : > has enough information to allow the driver to decide. I think that : > trying to shoe-horn the second model into a situation where the first : > model is actually better would be a disservice. : : When would the first be better? When there's no information about the children in the children. For example, pure ISA bus one must have an external enumeration. Likewise for devices on a SPI bus, a SSC bus or an I2C bus. These "busses" are impossible to enumerate through any method other than some kind of table that's supplied externally. In these cases, you cannot probe the device at all. In many cases, one can't touch the hardware at all in a reliable way to determine if it is there or not without potentially disrupting other devices on the bus. Unlike PCI, in this domain these devices don't have a device ID. What we do with them is use the hints mechanism to wire devices on the bus to addresses on the bus (if applicable). Since this is text based on the driver name, the actual bus has no special knowledge of the devices that can be on the bus. The text name is passed through more or less directly to newbus, which does the right thing. If there's a driver of that name, then it uses it. Otherwise the device is ignored. With an enumeration like you suggest, one would need to create an enumeration for each and every one of these things, compile it into the kernel and then have some kind of translation layer that we get for free today with newbus and bus_enumerate_hinted_bus(). Warner From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:46:06 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 601AD16A46E for ; Fri, 28 Dec 2007 20:46:06 +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 0341C13C45D for ; Fri, 28 Dec 2007 20:46:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSKe9YY076872; Fri, 28 Dec 2007 13:40:09 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 13:44:57 -0700 (MST) Message-Id: <20071228.134457.-1540395924.imp@bsdimp.com> To: olivier@gautherot.net From: "M. Warner Losh" In-Reply-To: References: <20071228.130329.43010549.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org, marcelm@juniper.net Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 20:46:06 -0000 In message: "Olivier Gautherot" writes: : Hi there! : : On 12/28/07, M. Warner Losh wrote: : > In message: : > Marcel Moolenaar writes: : > : On Dec 28, 2007, at 11:12 AM, M. Warner Losh wrote: : > : : > : > If the ocpbus has a table of bus types, what's wrong with having it : > : > directly assign the driver when it ads its children? : > : : > : It violates newbus in that drivers compete for a device. : > : If the bus assigns the driver, then there's no competition : > : possible. The fact that the bus is abstract should not : > : mean that we should change its paradigm. : > : > No it doesn't. There's two kinds of busses in newbus. Those that : > self enumerate based on the hardware present (ie pccard, pci, usb, : > firewire) and then those that are told what's there (oldcard-style : > pccard, pure ISA, I2C, etc). The busses on the SoC more strongly : > resemble the latter than the former. The former busses already are : > enumerated with hints, but the actual mechanism is just a few calls : > that could be replaced with something better. : : Excuse my ignorance about obio, ocpbus and the like... : If we envisage to use a PCI-like approach to initialise the on-chip : drivers, couldn't we generate a table on a per CPUID basis? : In PCI land, the device enumerates all the functions it supports : and the kernel installs the approriate modules. In this case, we would : have a table of devices indexed by the CPUID - for instance, the : MPC5200 has 2 UARTs at addresses x and y, the MPC5512 has 3 UARTs : at addresses x, y and z, etc. These tables would be used only during : boot time and would only use up ROM space... When compiling the : kernel, we would then enable only the tables that apply (ideally, just : one - and make sure at run time that it is the correct one). : : It does not sound like rocket science to me so I guess it has been : evaluated at some point? The problem is more complicated than just UARTs. The problem is defining the enumeration itself. Each device type in these SoCs typically is a custom job, apart from a few standard things like uarts. This means that one would have to add to the enumerated type every time one ported to a new SoC. It adds an extra step. It also makes it harder to come up on a new revision of an old chip that might have the same, or very similar, attributes to the old version, but has a new CPUID. With the hinted scheme, you could at least get partial information. Basing everything on the CPUID would mean that once that changes, you go to having zero knowledge of what's on the chip. Warner From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:48:40 2007 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FCC316A417 for ; Fri, 28 Dec 2007 20:48:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 3D1D113C4D5 for ; Fri, 28 Dec 2007 20:48:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 226432420-1834499 for multiple; Fri, 28 Dec 2007 15:50:42 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id lBSKm38k064655; Fri, 28 Dec 2007 15:48:23 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Fri, 28 Dec 2007 15:46:20 -0500 User-Agent: KMail/1.9.6 References: <20071228.114559.-311937481.imp@bsdimp.com> <200712281500.55155.jhb@freebsd.org> <20071228.132951.-432836769.imp@bsdimp.com> In-Reply-To: <20071228.132951.-432836769.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712281546.21288.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 28 Dec 2007 15:48:24 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5278/Fri Dec 28 11:55:36 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: marcelm@juniper.net, freebsd-embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 20:48:40 -0000 On Friday 28 December 2007 03:29:51 pm M. Warner Losh wrote: > In message: <200712281500.55155.jhb@freebsd.org> > John Baldwin writes: > : On Friday 28 December 2007 02:16:43 pm Marcel Moolenaar wrote: > : > > : Q1: Do people think it's worthwhile to pursue a generic > : > > : ocpbus(4) definition? > : > > > : > > Generally, yes. In fact, I've done a bunch of things with what I've > : > > called obio (On Board I/O) that does similar things, but relies > : > > entirely on hints to do the job. Since that's how we do things > : > > elsewhere, this seems like a reasonable approach. If we move to doing > : > > things differently, then we can talk about that. > : > > : > Hints can be used to implement the device tree or > : > device list, but is rather limited. I'd like us to > : > implement something richer in the future. For that > : > reason I don't want to expose hints to the driver, > : > but rather abstract the implementation of the device > : > tree or the device list behind IVARs. That makes it > : > possible to implement the "bus" in many different > : > ways without having to change the device drivers that > : > attach to the bus. > : > : So to jump in here. I've been thinking more since the last hints debacle and > : am thinking of replacing hints with the generic device metadata we'd > : discussed some at the end of the last thread: > : > : device.FOO.= > : > : where any driver or unit wiring is a new property rather than encoded into > : FOO's name. Thus: > : > : device.COM1.at=isa0 > : device.COM1.irq=4 > : device.COM1.port=0x3f8 > : device.COM1.driver=sio > : device.COM1.unit=0 > : > : or some such. > > How does one separate the topological information from the > proscriptive information? Eg, is the irq=4 an instruction to the > driver to use IRQ 4 for the device (proscriptive), or is it an > instruction to the bus to help locate COM1 (topological). The bus chooses. For the isa0 case it's complex, but it would basically work the way my current hint-wiring patches work. The acpi0 (ACPI) or isa0 (non-ACPI and using PNPBIOS) busses would use the resourcse to match COM1 to an existing device if possible. isa0 then does a second pass to actually add device_t's for any "hint" devices that weren't already matched. For smarter busses like pci(4) and usb(4) the topological info would be much more restrictive. pci(4) could probably just match solely on the "at" attribute and require it to specify the bus/slot/func (and optionally domain). > : There would be a new-bus level framework to enumerate the various devices that > : have properties and bus drivers would "claim" a device and bind it to a child > : device_t. Each bus could then expose the properties as it saw fit. For > : example, if you had this: > : > : device.FOO.at=pci4.5.0 > : device.FOO.vendor=0x5555 > : device.FOO.device=0x1212 > > Same question here. If the first one was 'device.FOO.at=pci' then > what would the other two things mean, especially if there was a > driver/unit forced for this device? pci(4) wouldn't allow for just "pci", it would only match a set of properties for a device hard-wired to a specific location. > : Also, fwiw I'm thinking of having a 'device' command in the loader that is a > : bit of a frontend so you can do things like: > : > : 'device COM1 at isa0 irq 4 console' > : > : that might translate into setting 'at=isa0', 'irq=4', 'console=1'. > > Again, the same questions: what parts of this are topological and what > parts proscriptive? See above. Look at the hints wiring patch I had. Basically you are doing 's/hint.sio.0/device.COM1/'. It actually works out the same. Once you can assign named properties to devices then wiring becomes a separate property. > : I also think there might be a generic way to get at any properties associated > : with a device_t by doing: > : > : int property_get_str(device_t dev, const char *name, char *buf, > : size_t buflen); > : int property_get_bool(device_t dev, const char *name, int *val); > : int property_get_int(device_t dev, const char *name, int *val); > : > : etc. > : > : Maybe devprop_* instead, but you get the idea. > > We already have similar interfaces to get the hinted properties... > What would the translation be. This would replace hints and resource_*(). resource_*() might still hang around in some form for things that use hints w/o new-bus such as SCSI wiring. > Also, I think that even though this is mildly relevant for the ocpbus > discussion, we shouldn't let ourselves get sidetracked by it. Well, I think it is relevant to the idea of creating a set of abstract-but-not-really ivars to try to replace hints. :-P -- John Baldwin From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:56:31 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF88B16A419 for ; Fri, 28 Dec 2007 20:56:31 +0000 (UTC) (envelope-from olivier@gautherot.net) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 76F3413C469 for ; Fri, 28 Dec 2007 20:56:31 +0000 (UTC) (envelope-from olivier@gautherot.net) Received: by py-out-1112.google.com with SMTP id u77so6754605pyb.3 for ; Fri, 28 Dec 2007 12:56:30 -0800 (PST) Received: by 10.142.105.14 with SMTP id d14mr3250976wfc.67.1198873917598; Fri, 28 Dec 2007 12:31:57 -0800 (PST) Received: by 10.70.53.11 with HTTP; Fri, 28 Dec 2007 12:31:57 -0800 (PST) Message-ID: Date: Fri, 28 Dec 2007 17:31:57 -0300 From: "Olivier Gautherot" To: "M. Warner Losh" In-Reply-To: <20071228.130329.43010549.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071228.114559.-311937481.imp@bsdimp.com> <20071228.121213.-494094613.imp@bsdimp.com> <20071228.130329.43010549.imp@bsdimp.com> Cc: embedded@freebsd.org, marcelm@juniper.net Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 20:56:31 -0000 Hi there! On 12/28/07, M. Warner Losh wrote: > In message: > Marcel Moolenaar writes: > : On Dec 28, 2007, at 11:12 AM, M. Warner Losh wrote: > : > : > If the ocpbus has a table of bus types, what's wrong with having it > : > directly assign the driver when it ads its children? > : > : It violates newbus in that drivers compete for a device. > : If the bus assigns the driver, then there's no competition > : possible. The fact that the bus is abstract should not > : mean that we should change its paradigm. > > No it doesn't. There's two kinds of busses in newbus. Those that > self enumerate based on the hardware present (ie pccard, pci, usb, > firewire) and then those that are told what's there (oldcard-style > pccard, pure ISA, I2C, etc). The busses on the SoC more strongly > resemble the latter than the former. The former busses already are > enumerated with hints, but the actual mechanism is just a few calls > that could be replaced with something better. Excuse my ignorance about obio, ocpbus and the like... If we envisage to use a PCI-like approach to initialise the on-chip drivers, couldn't we generate a table on a per CPUID basis? In PCI land, the device enumerates all the functions it supports and the kernel installs the approriate modules. In this case, we would have a table of devices indexed by the CPUID - for instance, the MPC5200 has 2 UARTs at addresses x and y, the MPC5512 has 3 UARTs at addresses x, y and z, etc. These tables would be used only during boot time and would only use up ROM space... When compiling the kernel, we would then enable only the tables that apply (ideally, just one - and make sure at run time that it is the correct one). It does not sound like rocket science to me so I guess it has been evaluated at some point? My cent worth... Cheers Olivier -- Olivier Gautherot olivier@gautherot.net Cel:+56 98 730 9361 www.gautherot.net http://www.linkedin.com/in/ogautherot From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 21:00:49 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B61516A469 for ; Fri, 28 Dec 2007 21:00:49 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by mx1.freebsd.org (Postfix) with ESMTP id 16F8E13C458 for ; Fri, 28 Dec 2007 21:00:49 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 13:00:41 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Dec 2007 12:55:47 -0800 Received: from mini-g4.jnpr.net (aparmelee-t41.jnpr.net [172.24.104.164] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSKtv978045; Fri, 28 Dec 2007 12:55:57 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.130329.43010549.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 12:55:57 -0800 References: <20071228.114559.-311937481.imp@bsdimp.com> <20071228.121213.-494094613.imp@bsdimp.com> <20071228.130329.43010549.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 20:55:47.0253 (UTC) FILETIME=[05462650:01C84994] Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 21:00:49 -0000 On Dec 28, 2007, at 12:03 PM, M. Warner Losh wrote: > In message: > Marcel Moolenaar writes: > : On Dec 28, 2007, at 11:12 AM, M. Warner Losh wrote: > : > : > If the ocpbus has a table of bus types, what's wrong with having > it > : > directly assign the driver when it ads its children? > : > : It violates newbus in that drivers compete for a device. > : If the bus assigns the driver, then there's no competition > : possible. The fact that the bus is abstract should not > : mean that we should change its paradigm. > > No it doesn't. There's two kinds of busses in newbus. Those that > self enumerate based on the hardware present (ie pccard, pci, usb, > firewire) and then those that are told what's there (oldcard-style > pccard, pure ISA, I2C, etc). I don't make that distinction at all. I see a probe method that's called to match a driver to a device. Whether that probe method is called only when it's known up-front that the driver matches the device is, to me, irrelevant. All I'm trying to achieve is: 1. we can relief the SoC or bus driver from having to know about device drivers by allowing it to create wildcard children that are being probed and attached in a generic way by allowing probe methods to obtain information (in am abstract way) about the corresponding hardware so as to have everything fall into place. 2. Avoid a flurry of bus-attachments to generic drivers by providing an abstract bus to which they can attach and from which they can obtain whatever information they need to function (IVARs were suggested) so as to allow many instances of a single driver that's attached to many and varying busses. 3. Keep the separation between bus and device pure by only using a generic handshake or protocol to pass information from one to the other. This has nothing to do with the origin of the device tree (firmware, kernel or other) or whether the bus is self- enumerating or not. Any bus that's not self-enumerating is enumerable in some other shape or form, including those that need hardcoded tables in the kernel. I don't care and that's why I want it abstracted from drivers. They should not have to care either. > : > Plus the > : > problem is complicated because none of these devices is standard. > : > Sorry if my first reply came on a little strong on the enumeration > : > point. If there is a compelling argument for it, I'll listen, > but it > : > isn't as if we have competing drivers for devices in this domain > like > : > we did with sio vs uart. > : > : We should not abandon competition, because that would > : be a step away from generalization. Even though we're > : discussing this in the context of embedded systems, > : I don't see any reason why it couldn't equally apply to > : the LPC devices in PCs that are enumerated by ACPI... > > That's a different case. Do not confuse these cases. ACPI has a > table of devices that associated resources with an ID. There's no > such tables in the SoC world, typically. Yes there is. If the table is not in firmware, it typically is in the kernel. The ID may not be needed if the table references the driver directly, but other than that it's exactly the same. There's no confusion. There's simply no distinction. Somewhere it's recorded that something exists. The ocpbus(4) idea is to abstract the details of where that information comes from by making it available in a generic way. > At most, you have a CPU ID > you can read and from that know, based on a hardwired set of tables, > the devices that are present. My point exactly ;-) > It isn't extensible in any way when a > new CPU ID comes along. With ACPI you'd get new devices and you > wouldn't worry. With the new CPU ID in the SoC world, you'd get > nothing until you created a new table. It's irrelevant to the abstraction whether a new device is dynamically found or whether it needs to be added to some static table by virtue of a firmware or kernel upgrade. The ability to allow a dynamic scheme does not impact static schemes. -- Marcel Moolenaar marcelm@juniper.net From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 21:55:59 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2735116A418 for ; Fri, 28 Dec 2007 21:55:59 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by mx1.freebsd.org (Postfix) with ESMTP id DD30F13C46A for ; Fri, 28 Dec 2007 21:55:58 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 13:55:25 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Dec 2007 13:55:16 -0800 Received: from mini-g4.jnpr.net (bennitzan-t60.jnpr.net [172.24.104.164] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSLtI990614; Fri, 28 Dec 2007 13:55:18 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: <7C4C5641-EA0E-4BEA-8EEC-EEB69CDEE071@juniper.net> From: Marcel Moolenaar To: "Olivier Gautherot" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 13:55:18 -0800 References: <20071228.114559.-311937481.imp@bsdimp.com> <20071228.121213.-494094613.imp@bsdimp.com> <20071228.130329.43010549.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 21:55:16.0961 (UTC) FILETIME=[54FC5D10:01C8499C] Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 21:55:59 -0000 On Dec 28, 2007, at 12:31 PM, Olivier Gautherot wrote: >> : It violates newbus in that drivers compete for a device. >> : If the bus assigns the driver, then there's no competition >> : possible. The fact that the bus is abstract should not >> : mean that we should change its paradigm. >> >> No it doesn't. There's two kinds of busses in newbus. Those that >> self enumerate based on the hardware present (ie pccard, pci, usb, >> firewire) and then those that are told what's there (oldcard-style >> pccard, pure ISA, I2C, etc). The busses on the SoC more strongly >> resemble the latter than the former. The former busses already are >> enumerated with hints, but the actual mechanism is just a few calls >> that could be replaced with something better. > > Excuse my ignorance about obio, ocpbus and the like... > If we envisage to use a PCI-like approach to initialise the on-chip > drivers, couldn't we generate a table on a per CPUID basis? That's only part the story. There are embedded devices that aren't SoC. You can't use the CPU ID to figure out what's there in that case. You typically need to use board IDs, or SKUs for that. But other than that, yes. A description of the hardware is, when not fixed, keyed off of some easy to obtain ID or characteristic... -- Marcel Moolenaar marcelm@juniper.net From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 22:07:09 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC3FE16A417 for ; Fri, 28 Dec 2007 22:07:09 +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 8888B13C458 for ; Fri, 28 Dec 2007 22:07:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSLxstW077728; Fri, 28 Dec 2007 14:59:55 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 15:04:43 -0700 (MST) Message-Id: <20071228.150443.-924279995.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: References: <20071228.130329.43010549.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 22:07:10 -0000 In message: Marcel Moolenaar writes: : This has nothing to do with the origin of the device tree : (firmware, kernel or other) or whether the bus is self- : enumerating or not. Any bus that's not self-enumerating : is enumerable in some other shape or form, including those : that need hardcoded tables in the kernel. I don't care and : that's why I want it abstracted from drivers. They should : not have to care either. I think you and I are arguing just to argue at this point. You can achieve your goals. : > : > Plus the : > : > problem is complicated because none of these devices is standard. : > : > Sorry if my first reply came on a little strong on the enumeration : > : > point. If there is a compelling argument for it, I'll listen, : > but it : > : > isn't as if we have competing drivers for devices in this domain : > like : > : > we did with sio vs uart. : > : : > : We should not abandon competition, because that would : > : be a step away from generalization. Even though we're : > : discussing this in the context of embedded systems, : > : I don't see any reason why it couldn't equally apply to : > : the LPC devices in PCs that are enumerated by ACPI... : > : > That's a different case. Do not confuse these cases. ACPI has a : > table of devices that associated resources with an ID. There's no : > such tables in the SoC world, typically. : : Yes there is. If the table is not in firmware, it : typically is in the kernel. The ID may not be needed : if the table references the driver directly, but : other than that it's exactly the same. There's no : confusion. There's simply no distinction. Somewhere : it's recorded that something exists. The ocpbus(4) : idea is to abstract the details of where that : information comes from by making it available in a : generic way. I guess my point is that you are creating extra work here. I've tried to be nice in saying that. All we're doing is creating an extra layer of abstraction that buys us nothing. You've not articulated how this extra layer saves code, or provides a better interface to the kernel other than to say, basically, it is more like pci. Have I missed this somewhere? : > At most, you have a CPU ID : > you can read and from that know, based on a hardwired set of tables, : > the devices that are present. : : My point exactly ;-) : : > It isn't extensible in any way when a : > new CPU ID comes along. With ACPI you'd get new devices and you : > wouldn't worry. With the new CPU ID in the SoC world, you'd get : > nothing until you created a new table. : : It's irrelevant to the abstraction whether a new : device is dynamically found or whether it needs : to be added to some static table by virtue of a : firmware or kernel upgrade. The ability to allow : a dynamic scheme does not impact static schemes. What is it you are trying to say here? We're never going to get around the fact that we have to have a different bus attachment for each of the enumeration mechanisms in the kernel. ACPI is always going to be special in some way. PCI is always going to be special in some way. Even if these two differ only by the tables they have to attach a device. The opcbus is also going to be special in some way. You and I disagree about how to make it special. You are advocating, if I read your proposal correctly, creating an artificial device identifier that is one or more integers of some flavor and then using that to match in a probe routine. There's a lookup in a table and a translation to a device number, effectively. I'm advocating a translation to a string. A string that happens to be the device and, possibly, the unit number of the device. My method doesn't require the addition of enumerations to tables and the string can be passed directly to newbus. The bus layer itself doesn't need to know about anything else, and doesn't need to change, apart from a new table, when new busses are added. This has the side effect of making the probe routine always return 'matched' in some fashion. If I understand your proposed method, then we would create a new integer of some flavor assigned for each and every type of device there is. You'd have us have something like: #define DEVICE_TYPE_UART 1 #define DEVCIE_TYPE_NETIF 2 #define DEVICE_TYPE_MMCSD 3 #define DEVICE_TYPE_SYNC 4 #define DEVICE_TYPE_SPI 5 #define DEVICE_TYPE_WIRELESS 6 #define DEVICE_TYPE_OHCI 7 #define DEVICE_TYPE_PCIB 8 #define DEVICE_TYPE_UHCI 9 ... #define DEVICE_ID_16550 1 #define DEVICE_ID_ATMEL_SERIAL 2 #define DEVICE_ID_ARM_LTD_SERIAL 3 #define DEVICE_ID_CIRRUS_SERIAL 4 #define DEVICE_ID_ATMEL_SSC 5 #define DEVICE_ID_ATMEL_MCI 6 #define DEVICE_ID_ATMEL_MCI2 7 #define DEVICE_ID_ATMEL_ETHER 8 /* AT91RM9200 ethernet device */ #define DEVICE_ID_ATMEL_ETHER2 9 /* AT91SAMxxx ethernet device */ #define DEVICE_ID_ATMEL_SPI 10 #define DEVICE_ID_ATMEL_TWI 11 #define DEVICE_ID_ATMEL_RTC 12 #define DEVICE_ID_ATMEL_PMC 13 #define DEVICE_ID_ATMEL_ST 14 #define DEVICE_ID_ATMEL_SERIAL_DBGU 15 /* Special, limited func serial port */ #define DEVICE_ID_ATMEL_UDP 16 #define DEVICE_ID_ATMEL_PIO 16 #define DEVICE_ID_CIRRUS_ETHER 18 #define DEVICE_ID_CIRRUS_GPIO 19 #define DEVICE_ID_XSCALE_MMC1 20 #define DEVICE_ID_XSCALE_MMC2 21 #define DEVICE_ID_XSCALE_MMC3 22 #define DEVICE_ID_XSCALE_GPIO 23 ... Am I understanding your proposal correctly? I can't see how else it would work if this isn't the case, but if you have some clever scheme, I'd be interested. Warner From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 22:10:36 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B401216A417 for ; Fri, 28 Dec 2007 22:10:36 +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 624DD13C474 for ; Fri, 28 Dec 2007 22:10:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSM3d1l077768; Fri, 28 Dec 2007 15:03:39 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 15:08:28 -0700 (MST) Message-Id: <20071228.150828.-861033669.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: <7C4C5641-EA0E-4BEA-8EEC-EEB69CDEE071@juniper.net> References: <20071228.130329.43010549.imp@bsdimp.com> <7C4C5641-EA0E-4BEA-8EEC-EEB69CDEE071@juniper.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 22:10:36 -0000 In message: <7C4C5641-EA0E-4BEA-8EEC-EEB69CDEE071@juniper.net> Marcel Moolenaar writes: : : On Dec 28, 2007, at 12:31 PM, Olivier Gautherot wrote: : : >> : It violates newbus in that drivers compete for a device. : >> : If the bus assigns the driver, then there's no competition : >> : possible. The fact that the bus is abstract should not : >> : mean that we should change its paradigm. : >> : >> No it doesn't. There's two kinds of busses in newbus. Those that : >> self enumerate based on the hardware present (ie pccard, pci, usb, : >> firewire) and then those that are told what's there (oldcard-style : >> pccard, pure ISA, I2C, etc). The busses on the SoC more strongly : >> resemble the latter than the former. The former busses already are : >> enumerated with hints, but the actual mechanism is just a few calls : >> that could be replaced with something better. : > : > Excuse my ignorance about obio, ocpbus and the like... : > If we envisage to use a PCI-like approach to initialise the on-chip : > drivers, couldn't we generate a table on a per CPUID basis? : : That's only part the story. There are embedded devices that : aren't SoC. You can't use the CPU ID to figure out what's : there in that case. You typically need to use board IDs, or : SKUs for that. But other than that, yes. A description of : the hardware is, when not fixed, keyed off of some easy to : obtain ID or characteristic... Very true. The CPU ID is a degenerate case. In Linux, at least for arm, all boards are assigned a unique ID by the arm team and the boot loader passes this id to the kernel that then uses it to figure out which board init to call, which knows what devices are on that board. In the case of multiplexed pins, it also knows which pins are connected (usb or ethernet or GPIO), and which pins aren't and need to be turned off (or pulled high, etc). FreeBSD's arm port needs to make better use of information like this... I'm not sure how these sorts of things are done in the PowerPC world. Warner From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 22:12:39 2007 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29F7316A420; Fri, 28 Dec 2007 22:12:39 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by mx1.freebsd.org (Postfix) with ESMTP id EF33C13C4DB; Fri, 28 Dec 2007 22:12:38 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 14:12:35 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Dec 2007 13:49:50 -0800 Received: from mini-g4.jnpr.net (mini-g4.jnpr.net [172.24.104.164]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSLo0989364; Fri, 28 Dec 2007 13:50:00 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: <2ADEF6FE-DC65-489A-A948-81E1A0455CA7@juniper.net> From: Marcel Moolenaar To: John Baldwin In-Reply-To: <200712281500.55155.jhb@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 13:49:59 -0800 References: <20071228.114559.-311937481.imp@bsdimp.com> <200712281500.55155.jhb@freebsd.org> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 21:49:50.0603 (UTC) FILETIME=[927615B0:01C8499B] Cc: freebsd-embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 22:12:39 -0000 On Dec 28, 2007, at 12:00 PM, John Baldwin wrote: >> Hints can be used to implement the device tree or >> device list, but is rather limited. I'd like us to >> implement something richer in the future. For that >> reason I don't want to expose hints to the driver, >> but rather abstract the implementation of the device >> tree or the device list behind IVARs. That makes it >> possible to implement the "bus" in many different >> ways without having to change the device drivers that >> attach to the bus. > > So to jump in here. I've been thinking more since the last hints > debacle and > am thinking of replacing hints with the generic device metadata we'd > discussed some at the end of the last thread: > > device.FOO.= > > where any driver or unit wiring is a new property rather than > encoded into > FOO's name. Thus: > > device.COM1.at=isa0 > device.COM1.irq=4 > device.COM1.port=0x3f8 > device.COM1.driver=sio > device.COM1.unit=0 > > or some such. Just a comment: there's a lot of value in taking a look at language and DB theory. Both syntax and semantics can be very important properties in the applicability and success of the new description. Yes, we may want to be able to compile it into some binary form for embedding it into the kernel... For example: busses may nest and may need to be described. This is especially true in the embedded space. The e500 has a local bus within the CCSR, which may contain i2c busses for example. Using the hints-way of describing hardware is just not going to fly in that case, because you're still keying off of device names and unit numbers. Let that be a consequence of the metadata, not an integral part of... (device.COM1.* does exactly that). FYI, -- Marcel Moolenaar marcelm@juniper.net From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 22:14:13 2007 Return-Path: Delivered-To: embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 950B616A419 for ; Fri, 28 Dec 2007 22:14:13 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by mx1.freebsd.org (Postfix) with ESMTP id 73CCA13C45A for ; Fri, 28 Dec 2007 22:14:13 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 14:14:12 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 14:12:07 -0800 Received: from mini-g4.jnpr.net (mini-g4.jnpr.net [172.24.104.164]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSMCH994420; Fri, 28 Dec 2007 14:12:17 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: <1EDE7CF9-586A-41CE-9B05-1E4A6431653D@juniper.net> From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.134154.1136083975.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 14:12:17 -0800 References: <20071228.125020.-1962668065.imp@bsdimp.com> <595F307F-8FC5-48D5-A69C-84660A768F23@juniper.net> <20071228.134154.1136083975.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 22:12:07.0210 (UTC) FILETIME=[AF2420A0:01C8499E] Cc: embedded@FreeBSD.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 22:14:13 -0000 On Dec 28, 2007, at 12:41 PM, M. Warner Losh wrote: > : > FreeBSD has two models for device enumeration. One is where the > : > parent bus decides, by whatever means, and one where the device > itself > : > has enough information to allow the driver to decide. I think > that > : > trying to shoe-horn the second model into a situation where the > first > : > model is actually better would be a disservice. > : > : When would the first be better? > > When there's no information about the children in the children. When is there information about the children in the children? Put differently: the only thing a PCI device driver knows is that if the vendor is X and the device is Y, it can be used with this driver. That's circumstantial. The same kind of circumstantial information can be synthesized for any and all busses that need external enumeration. It's merely a way of consuming the information. I propose that device drivers are the ultimate authority on wether they attach or not. Not the busses. > Unlike PCI, in this domain these devices don't have a device ID. True. We synthesize IDs for drivers to match against. Those IDs have nothing to do with hardware. It's just an agreement between the abstract bus driver and the device driver so that the bus knows how to flag a child for use by said driver. It's just an indirection. > With an enumeration like you suggest, one would need to create an > enumeration for each and every one of these things, compile it into > the kernel and then have some kind of translation layer that we get > for free today with newbus and bus_enumerate_hinted_bus(). I think you misunderstand the concept. -- Marcel Moolenaar marcelm@juniper.net From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 22:31:59 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFE4916A419 for ; Fri, 28 Dec 2007 22:31:58 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by mx1.freebsd.org (Postfix) with ESMTP id C343813C447 for ; Fri, 28 Dec 2007 22:31:58 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 14:31:56 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 14:30:30 -0800 Received: from mini-g4.jnpr.net (mini-g4.jnpr.net [172.24.104.164]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSMUf998170; Fri, 28 Dec 2007 14:30:41 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net> From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.150443.-924279995.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 14:30:40 -0800 References: <20071228.130329.43010549.imp@bsdimp.com> <20071228.150443.-924279995.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 22:30:30.0620 (UTC) FILETIME=[40D321C0:01C849A1] Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 22:31:59 -0000 On Dec 28, 2007, at 2:04 PM, M. Warner Losh wrote: > We're never going to get around the fact that we have to have a > different bus attachment for each of the enumeration mechanisms in the > kernel. Euh... the whole point of our discussion is exactly about creating an abstraction layer that hides the details of the enumeration mechanism from the driver so that you can in fact have a single bus attachment. ocpbus(4) is inherently useless if we still need to create different bus attachments for different, bus similar, busses. While I don't intend ocpbus(4) to be the one and only bus attachment, it should at least unify busses and/or configurations that aren't self-enumerating. > If I understand your proposed method, then we would create a new > integer of some flavor assigned for each and every type of device > there is. You'd have us have something like: > > #define DEVICE_TYPE_UART 1 > #define DEVCIE_TYPE_NETIF 2 > #define DEVICE_TYPE_MMCSD 3 > #define DEVICE_TYPE_SYNC 4 > #define DEVICE_TYPE_SPI 5 > #define DEVICE_TYPE_WIRELESS 6 > #define DEVICE_TYPE_OHCI 7 > #define DEVICE_TYPE_PCIB 8 > #define DEVICE_TYPE_UHCI 9 > ... > > #define DEVICE_ID_16550 1 > #define DEVICE_ID_ATMEL_SERIAL 2 > #define DEVICE_ID_ARM_LTD_SERIAL 3 > #define DEVICE_ID_CIRRUS_SERIAL 4 > #define DEVICE_ID_ATMEL_SSC 5 > #define DEVICE_ID_ATMEL_MCI 6 > #define DEVICE_ID_ATMEL_MCI2 7 > #define DEVICE_ID_ATMEL_ETHER 8 /* AT91RM9200 ethernet device */ > #define DEVICE_ID_ATMEL_ETHER2 9 /* AT91SAMxxx ethernet device */ > #define DEVICE_ID_ATMEL_SPI 10 > #define DEVICE_ID_ATMEL_TWI 11 > #define DEVICE_ID_ATMEL_RTC 12 > #define DEVICE_ID_ATMEL_PMC 13 > #define DEVICE_ID_ATMEL_ST 14 > #define DEVICE_ID_ATMEL_SERIAL_DBGU 15 /* Special, limited func > serial port */ > #define DEVICE_ID_ATMEL_UDP 16 > #define DEVICE_ID_ATMEL_PIO 16 > #define DEVICE_ID_CIRRUS_ETHER 18 > #define DEVICE_ID_CIRRUS_GPIO 19 > #define DEVICE_ID_XSCALE_MMC1 20 > #define DEVICE_ID_XSCALE_MMC2 21 > #define DEVICE_ID_XSCALE_MMC3 22 > #define DEVICE_ID_XSCALE_GPIO 23 > ... > > Am I understanding your proposal correctly? I can't see how else it > would work if this isn't the case, but if you have some clever scheme, > I'd be interested. No, this is more or less the gist of it. The type and id can be chosen in any way we like, including using the type as the id. The abstract bus driver does not need to know anything other than maybe translate a table into a newbus hierarchy and using the type/id combination to flag a child. Any newbus node that implements the ocpbus handshake is then automatically an ocpbus driver even though there's no mention of how it obtains the device information. As I said before: it's about avoiding the flurry of bus attachments, not about dictating how devices are enumerated. -- Marcel Moolenaar marcelm@juniper.net From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 22:43:12 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0801416A469 for ; Fri, 28 Dec 2007 22:43:12 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by mx1.freebsd.org (Postfix) with ESMTP id DB79313C4E7 for ; Fri, 28 Dec 2007 22:43:11 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 14:43:00 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Dec 2007 14:42:48 -0800 Received: from mini-g4.jnpr.net (aparmelee-t41.jnpr.net [172.24.104.164] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSMgw900914; Fri, 28 Dec 2007 14:42:58 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: <9355ADCA-B61C-4515-AEA4-CFA96A12AF0B@juniper.net> From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.150828.-861033669.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 14:42:58 -0800 References: <20071228.130329.43010549.imp@bsdimp.com> <7C4C5641-EA0E-4BEA-8EEC-EEB69CDEE071@juniper.net> <20071228.150828.-861033669.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 22:42:48.0596 (UTC) FILETIME=[F8B15540:01C849A2] Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 22:43:12 -0000 On Dec 28, 2007, at 2:08 PM, M. Warner Losh wrote: > : > Excuse my ignorance about obio, ocpbus and the like... > : > If we envisage to use a PCI-like approach to initialise the on- > chip > : > drivers, couldn't we generate a table on a per CPUID basis? > : > : That's only part the story. There are embedded devices that > : aren't SoC. You can't use the CPU ID to figure out what's > : there in that case. You typically need to use board IDs, or > : SKUs for that. But other than that, yes. A description of > : the hardware is, when not fixed, keyed off of some easy to > : obtain ID or characteristic... > > Very true. The CPU ID is a degenerate case. In Linux, at least for > arm, all boards are assigned a unique ID by the arm team and the boot > loader passes this id to the kernel that then uses it to figure out > which board init to call, which knows what devices are on that board. > In the case of multiplexed pins, it also knows which pins are > connected (usb or ethernet or GPIO), and which pins aren't and need to > be turned off (or pulled high, etc). FreeBSD's arm port needs to make > better use of information like this... > > I'm not sure how these sorts of things are done in the PowerPC world. At this time the only example is e500 and my experience here at Juniper. The on-chip peripherals can be enumerated based on the CPU ID, but whatever is underneath the local bus or attached to the i2c controllers (whether with our without multiplexers) is entirely board specific. Our tables even contain PCI resource assignments and interrupt routing for PCI devices. This because there's no firmware that assigns resources to PCI devices. We need to do that in the kernel itself... In other words: PowerPC is not SoC, but can be. There is more than one bus that needs to be enumerated and each of these may need a different set of tables, independently of the others. Tables may need to describe PCI busses as well so that the kernel knows how to set up the I/O windows and to program the hardware so that memory accesses are forwarded to the right device (DRAM, PCI or local bus). -- Marcel Moolenaar marcelm@juniper.net From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 23:34:18 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F1CD16A417 for ; Fri, 28 Dec 2007 23:34:18 +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 779A413C43E for ; Fri, 28 Dec 2007 23:34:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSNS7dk078503; Fri, 28 Dec 2007 16:28:07 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 16:32:57 -0700 (MST) Message-Id: <20071228.163257.756911359.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net> References: <20071228.150443.-924279995.imp@bsdimp.com> <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 23:34:18 -0000 In message: <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net> Marcel Moolenaar writes: : On Dec 28, 2007, at 2:04 PM, M. Warner Losh wrote: : : > We're never going to get around the fact that we have to have a : > different bus attachment for each of the enumeration mechanisms in the : > kernel. : : Euh... the whole point of our discussion is exactly about creating : an abstraction layer that hides the details of the enumeration : mechanism from the driver so that you can in fact have a single bus : attachment. : : ocpbus(4) is inherently useless if we still need to create different : bus attachments for different, bus similar, busses. While I don't : intend ocpbus(4) to be the one and only bus attachment, it should at : least unify busses and/or configurations that aren't self-enumerating. I think that's a noble goal. However, I think that it might be an unreachable goal. Maybe we should talk about how we're going to deal with the following situations that come up in the ARM port. That might help see how close we can come to this ideal. Maybe I'm just too jaded by my experience so far and you've discovered a cool way around this problem. The usb driver on atmel needs to manipulate the clock generator when it is attached to generate the 48MHz needed for the USB devices. However, when the driver isn't present in the kernel, the right thing to do is to keep this clock off because it uses power. How could this be done generically? On the xscale port, there's support for the compact flash that lives on many of them. There's a number of chip-specific and board-specific hacks that must happen in order for the generic driver to work. On the mips platform there are at least two flavors of 16550-like uarts present. One requires 32-bit access that's shifted 3 and the other 64-bit access that's shifted 4. The SPI, and MMC drivers need to interact with the chip selects the chip offers. The manner of these interactions varies based on the underlying SoC. Right now, all of these situations are dealt with by having a bit of code in a specific attachment cope. : > If I understand your proposed method, then we would create a new : > integer of some flavor assigned for each and every type of device : > there is. You'd have us have something like: : > : > #define DEVICE_TYPE_UART 1 : > #define DEVCIE_TYPE_NETIF 2 : > #define DEVICE_TYPE_MMCSD 3 : > #define DEVICE_TYPE_SYNC 4 : > #define DEVICE_TYPE_SPI 5 : > #define DEVICE_TYPE_WIRELESS 6 : > #define DEVICE_TYPE_OHCI 7 : > #define DEVICE_TYPE_PCIB 8 : > #define DEVICE_TYPE_UHCI 9 : > ... : > : > #define DEVICE_ID_16550 1 : > #define DEVICE_ID_ATMEL_SERIAL 2 : > #define DEVICE_ID_ARM_LTD_SERIAL 3 : > #define DEVICE_ID_CIRRUS_SERIAL 4 : > #define DEVICE_ID_ATMEL_SSC 5 : > #define DEVICE_ID_ATMEL_MCI 6 : > #define DEVICE_ID_ATMEL_MCI2 7 : > #define DEVICE_ID_ATMEL_ETHER 8 /* AT91RM9200 ethernet device */ : > #define DEVICE_ID_ATMEL_ETHER2 9 /* AT91SAMxxx ethernet device */ : > #define DEVICE_ID_ATMEL_SPI 10 : > #define DEVICE_ID_ATMEL_TWI 11 : > #define DEVICE_ID_ATMEL_RTC 12 : > #define DEVICE_ID_ATMEL_PMC 13 : > #define DEVICE_ID_ATMEL_ST 14 : > #define DEVICE_ID_ATMEL_SERIAL_DBGU 15 /* Special, limited func : > serial port */ : > #define DEVICE_ID_ATMEL_UDP 16 : > #define DEVICE_ID_ATMEL_PIO 16 : > #define DEVICE_ID_CIRRUS_ETHER 18 : > #define DEVICE_ID_CIRRUS_GPIO 19 : > #define DEVICE_ID_XSCALE_MMC1 20 : > #define DEVICE_ID_XSCALE_MMC2 21 : > #define DEVICE_ID_XSCALE_MMC3 22 : > #define DEVICE_ID_XSCALE_GPIO 23 : > ... : > : > Am I understanding your proposal correctly? I can't see how else it : > would work if this isn't the case, but if you have some clever scheme, : > I'd be interested. : : No, this is more or less the gist of it. The type and id : can be chosen in any way we like, including using the type : as the id. The abstract bus driver does not need to know : anything other than maybe translate a table into a newbus : hierarchy and using the type/id combination to flag a : child. How does this abstract driver know about the children to add? Or rather, how were you envisioning it getting the table it needed? : Any newbus node that implements the ocpbus handshake is : then automatically an ocpbus driver even though there's : no mention of how it obtains the device information. As : I said before: it's about avoiding the flurry of bus : attachments, not about dictating how devices are : enumerated. I agree that's a noble goal, and maybe we can avoid it in many cases, but not in all cases. I just don't think having a large enumeration table to make this work is worth the effort of maintaining it. When you go to add a new ocpbus driver, you need to touch additional places than the direct method. Now, apart from enumeration, I think that having a good, well known protocol would be good. I'm still a little unclear how one would communicate some of the stuff to the drivers, but I'm doing a p4 sync right now to get the e500 branch so I can take a look at what's there. Warner From owner-freebsd-embedded@FreeBSD.ORG Sat Dec 29 00:59:31 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E819C16A419 for ; Sat, 29 Dec 2007 00:59:31 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by mx1.freebsd.org (Postfix) with ESMTP id B141813C447 for ; Sat, 29 Dec 2007 00:59:31 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 16:59:25 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 16:58:46 -0800 Received: from mini-g4.jnpr.net (bobbyg-pc.jnpr.net [172.24.104.164] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBT0wt928494; Fri, 28 Dec 2007 16:58:57 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: <1B0F37B8-D492-4E15-82A8-704243E67E90@juniper.net> From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.163257.756911359.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 16:58:55 -0800 References: <20071228.150443.-924279995.imp@bsdimp.com> <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net> <20071228.163257.756911359.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 29 Dec 2007 00:58:46.0857 (UTC) FILETIME=[F7652B90:01C849B5] Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2007 00:59:32 -0000 On Dec 28, 2007, at 3:32 PM, M. Warner Losh wrote: > The usb driver on atmel needs to manipulate the clock generator when > it is attached to generate the 48MHz needed for the USB devices. > However, when the driver isn't present in the kernel, the right thing > to do is to keep this clock off because it uses power. How could this > be done generically? The first important part here is whether the USB driver needs to know about the generator. For uart(4) the ocpbus handshake already includes an IVAR for the clock, so let's reuse that for USB. When the clock IVAR doesn't exist, the USB driver does not need to worry about the clock (default). If the clock IVAR exists, it returns something that tells the USB driver to program the generator. What that something is, depends on whether the generator has a driver attached to it, or whether the clock is more platform specific than USB host controller specific. Let's assume the generator has a driver attached to it. The clock IVAR can then return the device_t of that driver and by means of a well-defined handshake (say a KOBJ I/F) the USB driver can tell the CG driver to enable the clock. If there's no driver attached to the generator, then the ocpbus attachment can pass resource information to the USB driver by way of a second RID. This then is used by the USB driver (ocpbus specific code) to program the generator. Of course, when the generator is within the USB resource range, it can be done from within the ocpbus attach function with the one resource assigned to the device. The IVAR then simply enables some code or another. Another way is have a "global" platform function for this that is called from the ocpbus attach function. That function can be a stub on platforms that have the same USB driver, but that do not have the generator. > On the xscale port, there's support for the compact flash that lives > on many of them. There's a number of chip-specific and board-specific > hacks that must happen in order for the generic driver to work. This may be done using KOBJ interfaces. I wrote a CFI driver and you can abstract the differences using KOBJ methods while still having a single driver. This is much akin to uart(4). > On the mips platform there are at least two flavors of 16550-like > uarts present. One requires 32-bit access that's shifted 3 and the > other 64-bit access that's shifted 4. Register shifting is already present in the uart(4) driver and information about it comes from the bus attachment. This does not mean that the uart(4) driver does 32- or 64-bit I/O. It always does 8-bit I/O. It's probably not a good idea to add support for 32-bit or 64-bit I/O to uart(4), unless we handle it as a separate hardware driver (the ns8250 is defined to use 8-bit I/O, so if that's not possible, it's not a ns8250 class UART). It's likely to be a platform or bus property, so it can all be handled naturally with the bus access functions. (i.e. implement the 1-byte access functions using 32- or 64-bit loads/stores). > The SPI, and MMC drivers need to interact with the chip selects the > chip offers. The manner of these interactions varies based on the > underlying SoC. Either special drivers or otherwise a KOBJ interface to abstract it and use the ocpbus' DEVCLASS to select the KOBJ class (like uart(4)). > Right now, all of these situations are dealt with by having a bit of > code in a specific attachment cope. Right. All these bits of code can be triggered by information that comes from the bus. The uart(4) register shift comes from the bus (when uart(4) is a child of puc(4) or scc(4)) or is hardcoded (sparc64 ebus or sbus). It's easy to expose that information through a single ocpbus handshake that includes information about the clock and register shift for UARTs. > : > Am I understanding your proposal correctly? I can't see how > else it > : > would work if this isn't the case, but if you have some clever > scheme, > : > I'd be interested. > : > : No, this is more or less the gist of it. The type and id > : can be chosen in any way we like, including using the type > : as the id. The abstract bus driver does not need to know > : anything other than maybe translate a table into a newbus > : hierarchy and using the type/id combination to flag a > : child. > > How does this abstract driver know about the children to add? Or > rather, how were you envisioning it getting the table it needed? That's not part of the ocpbus definition. It only defines the handshake between a bus and the bus attachment. In some cases you can put it all in nexus. In other cases you create a new bus driver that implements the handshake and has its own way of enumerating devices. > : Any newbus node that implements the ocpbus handshake is > : then automatically an ocpbus driver even though there's > : no mention of how it obtains the device information. As > : I said before: it's about avoiding the flurry of bus > : attachments, not about dictating how devices are > : enumerated. > > I agree that's a noble goal, and maybe we can avoid it in many cases, > but not in all cases. I just don't think having a large enumeration > table to make this work is worth the effort of maintaining it. When > you go to add a new ocpbus driver, you need to touch additional places > than the direct method. How so? > Now, apart from enumeration, I think that having a good, well known > protocol would be good. I'm still a little unclear how one would > communicate some of the stuff to the drivers, but I'm doing a p4 sync > right now to get the e500 branch so I can take a look at what's there. For uart(4) we currently have: static int uart_ocp_probe(device_t dev) { device_t parent; struct uart_softc *sc; uintptr_t clock, devtype; int error; parent = device_get_parent(dev); error = BUS_READ_IVAR(parent, dev, OCPBUS_IVAR_DEVTYPE, &devtype); if (error) return (error); if (devtype != OCPBUS_DEVTYPE_UART) return (ENXIO); sc = device_get_softc(dev); sc->sc_class = &uart_ns8250_class; /*1*/ if (BUS_READ_IVAR(parent, dev, OCPBUS_IVAR_CLOCK, &clock)) clock = 0; return (uart_bus_probe(dev, 0, clock, 0, 0)); /*2*/ } At /*1*/ we can add support for a DEVCLASS to handle non-ns8250 UARTs and at /*2*/ we can add support for REGSHIFT. All based on demand and all well-defined so that it's easy to replace an existing driver with another. -- Marcel Moolenaar marcelm@juniper.net From owner-freebsd-embedded@FreeBSD.ORG Sat Dec 29 01:04:13 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D64116A417 for ; Sat, 29 Dec 2007 01:04:13 +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 045B513C4D5 for ; Sat, 29 Dec 2007 01:04:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBT0wAL9079350; Fri, 28 Dec 2007 17:58:10 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 18:03:00 -0700 (MST) Message-Id: <20071228.180300.-432832706.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: <20071228.163257.756911359.imp@bsdimp.com> References: <20071228.150443.-924279995.imp@bsdimp.com> <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net> <20071228.163257.756911359.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2007 01:04:13 -0000 In message: <20071228.163257.756911359.imp@bsdimp.com> "M. Warner Losh" writes: : No, this is more or less the gist of it. The type and id : can be chosen in any way we like, including using the type : as the id. I just went out to shovel the drive way (a hazard of living in Colorado) and the above stuck in my head. One could also make the type/id a string and then the probe routines become something like: static int at91_ssc_probe(device_t dev) { if (strcmpy(device_get_name(dev), ocpbus_get_devname(dev)) != 0) return (ENXIO); device_set_descr(dev, "SSC"); return (0); /* or some other negative value */ } without the need to have the actual enumeration... This would be more complicated than setting the name when the child was added, but it would have the advantage of being overrideable if necessary. I'm just worried that the file defining an enum would soon become a big source of integration failures when code designed for these devices is integrated back into the tree. Maintaining big lists in the tree is something that newbus was designed to avoid. The artificial IDs seem to be reintroducing that, which is why I've had the negative reaction that I've had to it. Warner From owner-freebsd-embedded@FreeBSD.ORG Sat Dec 29 01:22:12 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F94416A418 for ; Sat, 29 Dec 2007 01:22:12 +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 A51F013C442 for ; Sat, 29 Dec 2007 01:22:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBT1ElxP079529; Fri, 28 Dec 2007 18:14:48 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 18:19:39 -0700 (MST) Message-Id: <20071228.181939.-957829045.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: <1B0F37B8-D492-4E15-82A8-704243E67E90@juniper.net> References: <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net> <20071228.163257.756911359.imp@bsdimp.com> <1B0F37B8-D492-4E15-82A8-704243E67E90@juniper.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2007 01:22:12 -0000 In message: <1B0F37B8-D492-4E15-82A8-704243E67E90@juniper.net> Marcel Moolenaar writes: : On Dec 28, 2007, at 3:32 PM, M. Warner Losh wrote: : : > The usb driver on atmel needs to manipulate the clock generator when : > it is attached to generate the 48MHz needed for the USB devices. : > However, when the driver isn't present in the kernel, the right thing : > to do is to keep this clock off because it uses power. How could this : > be done generically? : : The first important part here is whether the USB driver needs : to know about the generator. For uart(4) the ocpbus handshake : already includes an IVAR for the clock, so let's reuse that : for USB. When the clock IVAR doesn't exist, the USB driver does : not need to worry about the clock (default). If the clock IVAR : exists, it returns something that tells the USB driver to : program the generator. The usb host adapter drivers could care less about the generator, or if other platform specific things need to happen. It is setup such that the bus specific attachment routines do whatever dirtywork is necessary to get the resources allocated and the chip setup in specific ways. Putting a lot of this into one attachment likely will lead to lots of hacks for each platform infecting the 'generic' opcbus attachment. : What that something is, depends on whether the generator has a : driver attached to it, or whether the clock is more platform : specific than USB host controller specific. : : Let's assume the generator has a driver attached to it. The : clock IVAR can then return the device_t of that driver and by : means of a well-defined handshake (say a KOBJ I/F) the USB : driver can tell the CG driver to enable the clock. Can we come up with an interface that covers all the possible arrangements of this sort of thing? Would the specific ocpbus implementation need to provide it? Would it go up to the nexus? There's quite a bit of variation in what is needed for usb. It varies from setting up clocks (which might be something we could make relatively generic), to setting GPIOs to enable power on the connector. : If there's no driver attached to the generator, then the : ocpbus attachment can pass resource information to the USB : driver by way of a second RID. This then is used by the : USB driver (ocpbus specific code) to program the generator. : : Of course, when the generator is within the USB resource : range, it can be done from within the ocpbus attach function : with the one resource assigned to the device. The IVAR then : simply enables some code or another. The generator isn't within the usb range It is in another logical part of the chip. : Another way is have a "global" platform function for this : that is called from the ocpbus attach function. That function : can be a stub on platforms that have the same USB driver, but : that do not have the generator. All these ad-hoc solutions seem to me to make writing the attachments harder. I don't think they are something that can be made generic. : > On the xscale port, there's support for the compact flash that lives : > on many of them. There's a number of chip-specific and board-specific : > hacks that must happen in order for the generic driver to work. : : This may be done using KOBJ interfaces. : : I wrote a CFI driver and you can abstract the differences : using KOBJ methods while still having a single driver. : This is much akin to uart(4). I guess what's at the other end of the kobj that worries me. : > On the mips platform there are at least two flavors of 16550-like : > uarts present. One requires 32-bit access that's shifted 3 and the : > other 64-bit access that's shifted 4. : : Register shifting is already present in the uart(4) driver : and information about it comes from the bus attachment. This : does not mean that the uart(4) driver does 32- or 64-bit : I/O. It always does 8-bit I/O. It's probably not a good idea : to add support for 32-bit or 64-bit I/O to uart(4), unless : we handle it as a separate hardware driver (the ns8250 is : defined to use 8-bit I/O, so if that's not possible, it's : not a ns8250 class UART). : It's likely to be a platform or bus property, so it can all : be handled naturally with the bus access functions. (i.e. : implement the 1-byte access functions using 32- or 64-bit : loads/stores). how does the generic bus know how to set these device specific flags? : > The SPI, and MMC drivers need to interact with the chip selects the : > chip offers. The manner of these interactions varies based on the : > underlying SoC. : : Either special drivers or otherwise a KOBJ interface to : abstract it and use the ocpbus' DEVCLASS to select the : KOBJ class (like uart(4)). I'm not sure this is reasonable. Maybe we should code up something to see exactly how hard it would be. This sounds like a lot of extra work for not a lot of benefit. : > Right now, all of these situations are dealt with by having a bit of : > code in a specific attachment cope. : : Right. All these bits of code can be triggered by : information that comes from the bus. The uart(4) register : shift comes from the bus (when uart(4) is a child of : puc(4) or scc(4)) or is hardcoded (sparc64 ebus or sbus). : : It's easy to expose that information through a single : ocpbus handshake that includes information about the : clock and register shift for UARTs. How does ocpbus know about these things if it is generic? : > : > Am I understanding your proposal correctly? I can't see how : > else it : > : > would work if this isn't the case, but if you have some clever : > scheme, : > : > I'd be interested. : > : : > : No, this is more or less the gist of it. The type and id : > : can be chosen in any way we like, including using the type : > : as the id. The abstract bus driver does not need to know : > : anything other than maybe translate a table into a newbus : > : hierarchy and using the type/id combination to flag a : > : child. : > : > How does this abstract driver know about the children to add? Or : > rather, how were you envisioning it getting the table it needed? : : That's not part of the ocpbus definition. It only defines : the handshake between a bus and the bus attachment. In some : cases you can put it all in nexus. In other cases you create : a new bus driver that implements the handshake and has its : own way of enumerating devices. I'd imagine that typically you'd need to have it not be in nexus based on my experience with arm. : > : Any newbus node that implements the ocpbus handshake is : > : then automatically an ocpbus driver even though there's : > : no mention of how it obtains the device information. As : > : I said before: it's about avoiding the flurry of bus : > : attachments, not about dictating how devices are : > : enumerated. : > : > I agree that's a noble goal, and maybe we can avoid it in many cases, : > but not in all cases. I just don't think having a large enumeration : > table to make this work is worth the effort of maintaining it. When : > you go to add a new ocpbus driver, you need to touch additional places : > than the direct method. : : How so? If you had a string that's the device to attach in the table, then you wouldn't have to edit ocpbusvar.h, or whatever file defined the enumeration, every time you added new devices that could attach to ocpbus. : > Now, apart from enumeration, I think that having a good, well known : > protocol would be good. I'm still a little unclear how one would : > communicate some of the stuff to the drivers, but I'm doing a p4 sync : > right now to get the e500 branch so I can take a look at what's there. : : For uart(4) we currently have: : : static int : uart_ocp_probe(device_t dev) : { : device_t parent; : struct uart_softc *sc; : uintptr_t clock, devtype; : int error; : : parent = device_get_parent(dev); : : error = BUS_READ_IVAR(parent, dev, OCPBUS_IVAR_DEVTYPE, &devtype); : if (error) : return (error); : if (devtype != OCPBUS_DEVTYPE_UART) : return (ENXIO); : : sc = device_get_softc(dev); : sc->sc_class = &uart_ns8250_class; /*1*/ : : if (BUS_READ_IVAR(parent, dev, OCPBUS_IVAR_CLOCK, &clock)) : clock = 0; : return (uart_bus_probe(dev, 0, clock, 0, 0)); /*2*/ : } : : At /*1*/ we can add support for a DEVCLASS to handle non-ns8250 : UARTs and at /*2*/ we can add support for REGSHIFT. All based : on demand and all well-defined so that it's easy to replace an : existing driver with another. This side of things isn't too horrible, but the sending side is what I worry about. How does the ocpbus know about these details and remain generic? Warner From owner-freebsd-embedded@FreeBSD.ORG Sat Dec 29 01:50:16 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE68216A41A for ; Sat, 29 Dec 2007 01:50:16 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by mx1.freebsd.org (Postfix) with ESMTP id BE4FD13C4E9 for ; Sat, 29 Dec 2007 01:50:16 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 17:50:09 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Dec 2007 17:47:01 -0800 Received: from mini-g4.jnpr.net (aparmelee-t41.jnpr.net [172.24.104.164] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBT1lC937266; Fri, 28 Dec 2007 17:47:12 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: <6712844B-1863-4316-9BEE-E43E9BE232A8@juniper.net> From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.181939.-957829045.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 17:47:11 -0800 References: <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net> <20071228.163257.756911359.imp@bsdimp.com> <1B0F37B8-D492-4E15-82A8-704243E67E90@juniper.net> <20071228.181939.-957829045.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 29 Dec 2007 01:47:01.0421 (UTC) FILETIME=[B4B095D0:01C849BC] Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2007 01:50:17 -0000 On Dec 28, 2007, at 5:19 PM, M. Warner Losh wrote: > : > Right now, all of these situations are dealt with by having a > bit of > : > code in a specific attachment cope. > : > : Right. All these bits of code can be triggered by > : information that comes from the bus. The uart(4) register > : shift comes from the bus (when uart(4) is a child of > : puc(4) or scc(4)) or is hardcoded (sparc64 ebus or sbus). > : > : It's easy to expose that information through a single > : ocpbus handshake that includes information about the > : clock and register shift for UARTs. > > How does ocpbus know about these things if it is generic? The ocpbus handshake is generic, the code that implements the handshake is specific. What I'm trying to achieve is not a single generic bus implementation. I'm trying to achieve a single generic handshake that platform specific bus drivers can implement so that we can re-use bus attachments. Thus, if uart(4) has an ocpbus bus attachment, it will expect a couple of IVARs. Any SoC that has a ns8250 can implementation those IVARs and have uart(4) attach with the ocpbus attachment. No need to also create a new bus attachment. Look at puc(4) and scc(4). Both expose an abstract bus and both have separate bus attachments for uart(4). It would be nice if we can stop the growth of bus attachments (especially for uart(4)). > : > I agree that's a noble goal, and maybe we can avoid it in many > cases, > : > but not in all cases. I just don't think having a large > enumeration > : > table to make this work is worth the effort of maintaining it. > When > : > you go to add a new ocpbus driver, you need to touch additional > places > : > than the direct method. > : > : How so? > > If you had a string that's the device to attach in the table, then you > wouldn't have to edit ocpbusvar.h, or whatever file defined the > enumeration, every time you added new devices that could attach to > ocpbus. True. There will be a single header that defines the magic constants and that header needs updating whenever we need to add a magic constant. > This side of things isn't too horrible, but the sending side is what I > worry about. How does the ocpbus know about these details and remain > generic? The bus implementation is not necessarily generic. When we have a new and improved way to describe the hardware, we may be able to come up with a generic ocpbus that parses the description and constructs the newbus tree. Without that, I presume that we have separate drivers for the busses that implement the generic handshake. -- Marcel Moolenaar marcelm@juniper.net From owner-freebsd-embedded@FreeBSD.ORG Sat Dec 29 02:21:58 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCD8E16A417 for ; Sat, 29 Dec 2007 02:21:58 +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 713AB13C442 for ; Sat, 29 Dec 2007 02:21:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBT2GNtr080010; Fri, 28 Dec 2007 19:16:24 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 19:21:15 -0700 (MST) Message-Id: <20071228.192115.783710089.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: <6712844B-1863-4316-9BEE-E43E9BE232A8@juniper.net> References: <1B0F37B8-D492-4E15-82A8-704243E67E90@juniper.net> <20071228.181939.-957829045.imp@bsdimp.com> <6712844B-1863-4316-9BEE-E43E9BE232A8@juniper.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2007 02:21:58 -0000 In message: <6712844B-1863-4316-9BEE-E43E9BE232A8@juniper.net> Marcel Moolenaar writes: : : On Dec 28, 2007, at 5:19 PM, M. Warner Losh wrote: : : > : > Right now, all of these situations are dealt with by having a : > bit of : > : > code in a specific attachment cope. : > : : > : Right. All these bits of code can be triggered by : > : information that comes from the bus. The uart(4) register : > : shift comes from the bus (when uart(4) is a child of : > : puc(4) or scc(4)) or is hardcoded (sparc64 ebus or sbus). : > : : > : It's easy to expose that information through a single : > : ocpbus handshake that includes information about the : > : clock and register shift for UARTs. : > : > How does ocpbus know about these things if it is generic? : : The ocpbus handshake is generic, the code that implements : the handshake is specific. What I'm trying to achieve is : not a single generic bus implementation. I'm trying to : achieve a single generic handshake that platform specific : bus drivers can implement so that we can re-use bus : attachments. That's a good goal... But I see difficulties in realizing it based on other design choices... : Thus, if uart(4) has an ocpbus bus attachment, it will : expect a couple of IVARs. Any SoC that has a ns8250 can : implementation those IVARs and have uart(4) attach with : the ocpbus attachment. No need to also create a new : bus attachment. Look at puc(4) and scc(4). Both expose : an abstract bus and both have separate bus attachments : for uart(4). It would be nice if we can stop the growth : of bus attachments (especially for uart(4)). I'm not sure how much you can do about that. You'll run into problems doing that. If you have a 'generic' attachment for uart, then you'll have code that looks like: switch (class) { case NS8250: sc->sc_class = &uart_ns8250_class; break; case AT91: sc->sc_class = &at91_usart_class; break; case CIRRUS: sc->sc_class = &uart_cirrus_class; break; case ARMIP: sc->sc_class = &uart_armip_class; break; ... } which drags in a bunch of unwanted code. The ARMIP only exists on one of our mips ports, while the cirrus and at91 ports typically don't have ns8250. So short of having a bunch of ifdefs, I'm not sure how you'd solve this problem. : > : > I agree that's a noble goal, and maybe we can avoid it in many : > cases, : > : > but not in all cases. I just don't think having a large : > enumeration : > : > table to make this work is worth the effort of maintaining it. : > When : > : > you go to add a new ocpbus driver, you need to touch additional : > places : > : > than the direct method. : > : : > : How so? : > : > If you had a string that's the device to attach in the table, then you : > wouldn't have to edit ocpbusvar.h, or whatever file defined the : > enumeration, every time you added new devices that could attach to : > ocpbus. : : True. There will be a single header that defines the magic : constants and that header needs updating whenever we need : to add a magic constant. Right. For me, this is a needless file that will be a cause of integration problems. This is my biggest complaint: we're reintroducing a file that lists all possible devices. : > This side of things isn't too horrible, but the sending side is what I : > worry about. How does the ocpbus know about these details and remain : > generic? : : The bus implementation is not necessarily generic. When : we have a new and improved way to describe the hardware, : we may be able to come up with a generic ocpbus that : parses the description and constructs the newbus tree. : Without that, I presume that we have separate drivers : for the busses that implement the generic handshake. Right. So we're back to the bus subclassing to make everything work... Which is fine... Warner From owner-freebsd-embedded@FreeBSD.ORG Sat Dec 29 19:30:31 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EB9216A417 for ; Sat, 29 Dec 2007 19:30:31 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by mx1.freebsd.org (Postfix) with ESMTP id DB06913C43E for ; Sat, 29 Dec 2007 19:30:30 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Sat, 29 Dec 2007 11:30:26 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Dec 2007 11:29:36 -0800 Received: from securepptp008.static.jnpr.net (securepptp008.static.jnpr.net [172.24.253.8]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBTJTZ989105; Sat, 29 Dec 2007 11:29:35 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.192115.783710089.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Sat, 29 Dec 2007 11:29:35 -0800 References: <1B0F37B8-D492-4E15-82A8-704243E67E90@juniper.net> <20071228.181939.-957829045.imp@bsdimp.com> <6712844B-1863-4316-9BEE-E43E9BE232A8@juniper.net> <20071228.192115.783710089.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 29 Dec 2007 19:29:36.0242 (UTC) FILETIME=[25863D20:01C84A51] Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2007 19:30:31 -0000 On Dec 28, 2007, at 6:21 PM, M. Warner Losh wrote: > : Thus, if uart(4) has an ocpbus bus attachment, it will > : expect a couple of IVARs. Any SoC that has a ns8250 can > : implementation those IVARs and have uart(4) attach with > : the ocpbus attachment. No need to also create a new > : bus attachment. Look at puc(4) and scc(4). Both expose > : an abstract bus and both have separate bus attachments > : for uart(4). It would be nice if we can stop the growth > : of bus attachments (especially for uart(4)). > > I'm not sure how much you can do about that. You'll run into problems > doing that. If you have a 'generic' attachment for uart, then you'll > have code that looks like: > > switch (class) { > case NS8250: sc->sc_class = &uart_ns8250_class; break; > case AT91: sc->sc_class = &at91_usart_class; break; > case CIRRUS: sc->sc_class = &uart_cirrus_class; break; > case ARMIP: sc->sc_class = &uart_armip_class; break; > ... > } > > which drags in a bunch of unwanted code. The ARMIP only exists on one > of our mips ports, while the cirrus and at91 ports typically don't > have ns8250. Ah, but that is easy to handle with weak references. If the symbol you reference (like above) is not compiled-in, you get a NULL value. So, you check the IVAR to get the class, use a weak reference to get the address of the uart class structure and if that's NULL, you know you can't attach. The only additional code is the case statement in the switch (like above), but nothing else. That can't be too bad? No ifdefs in sight either... > : > : > I agree that's a noble goal, and maybe we can avoid it in many > : > cases, > : > : > but not in all cases. I just don't think having a large > : > enumeration > : > : > table to make this work is worth the effort of maintaining it. > : > When > : > : > you go to add a new ocpbus driver, you need to touch > additional > : > places > : > : > than the direct method. > : > : > : > : How so? > : > > : > If you had a string that's the device to attach in the table, > then you > : > wouldn't have to edit ocpbusvar.h, or whatever file defined the > : > enumeration, every time you added new devices that could attach to > : > ocpbus. > : > : True. There will be a single header that defines the magic > : constants and that header needs updating whenever we need > : to add a magic constant. > > Right. For me, this is a needless file that will be a cause of > integration problems. This is my biggest complaint: we're > reintroducing a file that lists all possible devices. Granted. Since the big win is in re-using common code, any driver that's specific to a platform is not going to benefit from this. So, what if we put only the MI drivers in there (i.e. uart and maybe a handful of others) and simply reserve a range for MD drivers or platform specific drivers. We don't list all possible drivers; only those that share the bus attachment across platforms and CPU models. Would that still be useful, or do we limit the scope too much then? -- Marcel Moolenaar marcelm@juniper.net From owner-freebsd-embedded@FreeBSD.ORG Sat Dec 29 22:37:38 2007 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2A5316A417 for ; Sat, 29 Dec 2007 22:37:38 +0000 (UTC) (envelope-from portcitycs@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id 2C0C913C458 for ; Sat, 29 Dec 2007 22:37:38 +0000 (UTC) (envelope-from portcitycs@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so4422289rvb.43 for ; Sat, 29 Dec 2007 14:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=lw57FiBhnlZK/cKqhvvbfEfpgj7Gy7vJXGUntrGEm68=; b=lr0jGbmWfmYRCkMgpZAMe8V+W3GaXI2corFf8Xb2BEE5zjtGYw46ircYgfwHSxJUL+lWo46KX5mrDSGzlS+kNe+LgBkSWtOcrQLxwbosA5boeS1BR6teGi7WQ+odlaM06GLmqvjA9gvIDQc+5jVXTj1AuIKL9mrQi+4idiTGQg4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=A6hf35d7anMrqZnY8RTIrJyyg9wIZEy0Cx6PreZnx+pW6BNN1P38NYvzEYsFq1thWAnXjZV3/JcvDxLtWgIg9Yrn+SlJDXkX9uywiQTtIIFjtahagG+ZDPt9PUrev+XjApJEvMOmiXHdjkMZwafJhQ8NRpB0Tf+blWeGGJ1HATA= Received: by 10.142.47.6 with SMTP id u6mr3405920wfu.29.1198967857427; Sat, 29 Dec 2007 14:37:37 -0800 (PST) Received: by 10.142.238.2 with HTTP; Sat, 29 Dec 2007 14:37:37 -0800 (PST) Message-ID: <5a1835cd0712291437sda4682bw340a33d2823e642@mail.gmail.com> Date: Sat, 29 Dec 2007 17:37:37 -0500 From: "Lyle Scott III" To: freebsd-embedded@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Still can not boot NanoBSD on Alix board.. X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2007 22:37:38 -0000 I posted here a few weeks ago about not being able to boot NanoBSD on my Alix board. I can boot TinyBSD just fine, though. (http://kerneltrap.org/mailarchive/freebsd-embeded/2007/12/9/485165) I tried to follow everyone's suggestions, but still couldn't manage to get it booted on my Alix3c2. Any other suggestions? I am also now writing to the CF card through IDE instead of the USB readered I had. Is there something I am missing? Any nanobsd image i burn works great on my Soekris boards. Also, i notice the NanoBSD throws in a boot loader and TinyBSD does not. I have tried messing with the boot0cfg options in the actual /usr/src/tools/tools/nanobsd/nanobsd.sh script to treat it like TinyBSD, but to no avail. -- Lyle Scott, III http://www.lylescott.ws