From owner-freebsd-embedded@FreeBSD.ORG Tue Jan 1 01:50:02 2008 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 4276116A468; Tue, 1 Jan 2008 01:50:02 +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 E201113C458; Tue, 1 Jan 2008 01:50:01 +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 m011nvrj020056; Mon, 31 Dec 2007 18:49:57 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 31 Dec 2007 18:49:53 -0700 (MST) Message-Id: <20071231.184953.1708679834.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200712311606.25424.jhb@freebsd.org> References: <200712281500.55155.jhb@freebsd.org> <2ADEF6FE-DC65-489A-A948-81E1A0455CA7@juniper.net> <200712311606.25424.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: Tue, 01 Jan 2008 01:50:02 -0000 In message: <200712311606.25424.jhb@freebsd.org> John Baldwin writes: : On Friday 28 December 2007 04:49:59 pm Marcel Moolenaar wrote: : > : > 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). Actually, the hints way of describing the hardware like the e500 has is working today in the at91 port. We do exactly this to describe what iic devices are on the bus, what spi items are on the spi bus, etc. While it would be nice to have an extra layer of indirection there, I don't see what it buys us in the general case. The iic bus is in turn on the twi device which is on the atmelbus which is on the nexus. The nesting is already supported. : Redo the 'at' hints like this (pci was already this way in the existing hint : wiring stuff anyway, i.e. it's _not_ a new-bus device name in 'at'). I'll : use all-caps to make it stand out: : : device.COM1.at=ISA : : device.USBA.at=PCI0:4:0 // domain 0 is implicit if not specified : : device.FOO.at=BAR : : Bus drivers would be responsible for parsing the 'at' and deciding whether or : not to "claim" a set of device properties. They may then either bind those : properties to an existing device enumerated elsewhere (ACPI/PNPBIOS/PCI) : based on 1 or more property values or create a new device entirely described : by the property values. You could even support something like this: : : device.BAR.at=PCI0.13.0 : : device.FOO.at=BAR:42 : : If you wanted if the driver for 'BAR' (or a child device that was a bus if the : PCI device_t is not a bus itself) by letting the driver for BAR query : it's "property name" and use that when evaluating "at". : : Some other possible locations (which is what "at" is in this context): : : device.COM1.at=ACPI:_SB_.PCI0.LPC0.COMA : : (and possibly it could take the short name as well:) : : device.COM1.at=ACPI:COMA If Marcel really objects to hints, this isn't going to be much better. It appears to be as expressive as hints with one extra layer of indirection. I'm not sure I see what that buys us, frankly. If you really want to support nesting, without complexity getting in the way, you'll likely need to have a better language to describe things. Something like: nexus 0 { atmelbus 0 { at91_twi 0 { iicbus * { icee 0 { addr = 0x80; } icee 1 { addr = 0x90; } icee 2 { addr = 0xa0; } icee 3 { addr = 0xb0; } } } at91_spi 0 { spibus * { at45d 0 { select = 0; } } } } } and have that be translated to something the kernel can easily parse. Warner From owner-freebsd-embedded@FreeBSD.ORG Tue Jan 1 20:33:55 2008 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 0C5FC16A419 for ; Tue, 1 Jan 2008 20:33:55 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.77]) by mx1.freebsd.org (Postfix) with ESMTP id E9B4513C447 for ; Tue, 1 Jan 2008 20:33:54 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp006-s [10.150.69.69]) by smtpoutm.mac.com (Xserve/smtpout014/MantshX 4.0) with ESMTP id m01K9qcM005228; Tue, 1 Jan 2008 12:09:52 -0800 (PST) Received: from [192.168.1.100] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/asmtp006/MantshX 4.0) with ESMTP id m01K9owR017311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Jan 2008 12:09:50 -0800 (PST) Message-Id: From: Marcel Moolenaar To: John Baldwin In-Reply-To: <200712311606.25424.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: Tue, 1 Jan 2008 12:09:50 -0800 References: <200712281500.55155.jhb@freebsd.org> <2ADEF6FE-DC65-489A-A948-81E1A0455CA7@juniper.net> <200712311606.25424.jhb@freebsd.org> X-Mailer: Apple Mail (2.915) 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: Tue, 01 Jan 2008 20:33:55 -0000 On Dec 31, 2007, at 1:06 PM, John Baldwin wrote: >> 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). > > Redo the 'at' hints like this (pci was already this way in the > existing hint > wiring stuff anyway, i.e. it's _not_ a new-bus device name in > 'at'). I'll > use all-caps to make it stand out: While I think that's a good thing, the confusion to the user when it comes to the unit number is already present. People already assume that if they have hint.sio.0.at="isa" that they expect to see device sio0. I fear that it's exactly the same with "device.COM1.at=ISA. If the 1 on COM1 is just a means to distinguish multiple COM devices, then it's much better to use a more structural approach, eliminate the unit and instead key-off of something that's truly identifying. In other words: hints historically mix the hardware description with the assignment of the driver and the unit number. Your proposal has the same flaws. The whole thing is just awkward for the user and impossible to implement unambiguously. > Bus drivers would be responsible for parsing the 'at' and deciding > whether or > not to "claim" a set of device properties. They may then either bind > those > properties to an existing device enumerated elsewhere (ACPI/PNPBIOS/ > PCI) > based on 1 or more property values or create a new device entirely > described > by the property values. This is the part I don't like. There's no clear definition of who or what is in control. In other words: how do we distinguish a description that is to amend or correct from a description that is to define a new device. That's the fundamental problem. In RDB terms: We're still combining unrelated pieces of information in a single table. It has problems. We already have them and we will not resolve them if we don't fix the fundamental problems. Seriously: you need multiple independent descriptions or tables. You need one to enumerate hardware -- a table that describes hardware not already described and ideally usable across OSes (just so that it's clear that there are no FreeBSD specifics embedded). You need another tabke to assign hardware to drivers (i.e. wiring) -- a table that's processed by the newbus architecture and bus drivers so that the wildcard nodes created as the result of enumerating the hardware are mapped to devclasses and are assigned unit numbers. You need a third table for driver- specific information -- a table that is consumed by drivers and which comtains flags, options or directives to the driver so that it can work with the hardware in question. With ACPI optional and describing the LPC bus, we probably want to be able to describe the LPC bus in case we don't use ACPI. This means we need some way to make hardware descriptions optional or to active descriptions conditionally. This is also a feature we can use to support SoCs: we enable hardware descriptions based on some CPU ID, board ID or through some other means. Let's just fix this right... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-embedded@FreeBSD.ORG Tue Jan 1 20:58:57 2008 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 48EC416A418; Tue, 1 Jan 2008 20:58:57 +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 0340C13C45B; Tue, 1 Jan 2008 20:58:56 +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 m01KwGAv037426; Tue, 1 Jan 2008 13:58:16 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 01 Jan 2008 13:58:25 -0700 (MST) Message-Id: <20080101.135825.1943337000.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <2ADEF6FE-DC65-489A-A948-81E1A0455CA7@juniper.net> <200712311606.25424.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: 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: Tue, 01 Jan 2008 20:58:57 -0000 In message: Marcel Moolenaar writes: : Let's just fix this right... In many ways, you are complaining about the same thing that I've struggled with. Sometimes, hint.sio.0.addr=0x3e8 means 'bind whichever of the enumerated COM ports lives at 3e8 to sio0' (eg, cross binding of a device enumerated by other means to a driver/unit) and sometimes it means 'you have a COM port whose resource starts at 0x3e8'. If you have trouble reading the difference between those two statements, it is the difference between binding a known device node (known through looking at an BIOS provided table) and the OS providing that entire table. I disagree with you that it is a fundamental flaw in the system, but am always open to better suggestions at how to implement this stuff. The hints were my first, best guess, and they have served us well. We are at the point now where we must expand them either as John has outlined, or we need to scrap them entirely in favor of something better. What we cannot do is let the promise of something better that isn't really being worked on stop us from expanding what we have. Do you have something specific in mind that we can start working on some kind of design document against? It is OK if that's a series of conversations, but we have to get off the inflection point we're at now: No, you can't expand what's there, and there's no clearly articulated 'something better'. So if you could take a few minutes and write up a straw-man proposal for what you see as doing it right, I think that would get us toward a solution... Warner From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 00:11:43 2008 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 0C63916A417; Wed, 2 Jan 2008 00:11:43 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id E76FE13C45B; Wed, 2 Jan 2008 00:11:42 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp009-s [10.150.69.72]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id m020BXUF006129; Tue, 1 Jan 2008 16:11:33 -0800 (PST) Received: from [192.168.1.100] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/asmtp009/MantshX 4.0) with ESMTP id m020BUvG000161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Jan 2008 16:11:31 -0800 (PST) Message-Id: <19740DB1-E759-4A61-8E1F-33AEAE74631E@mac.com> From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20080101.135825.1943337000.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: Tue, 1 Jan 2008 16:11:30 -0800 References: <2ADEF6FE-DC65-489A-A948-81E1A0455CA7@juniper.net> <200712311606.25424.jhb@freebsd.org> <20080101.135825.1943337000.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) 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: Wed, 02 Jan 2008 00:11:43 -0000 On Jan 1, 2008, at 12:58 PM, M. Warner Losh wrote: > In message: > Marcel Moolenaar writes: > : Let's just fix this right... > > In many ways, you are complaining about the same thing that I've > struggled with. Sometimes, hint.sio.0.addr=0x3e8 means 'bind > whichever of the enumerated COM ports lives at 3e8 to sio0' (eg, cross > binding of a device enumerated by other means to a driver/unit) and > sometimes it means 'you have a COM port whose resource starts at > 0x3e8'. Yes. We're going to use hints for too many things without making sure that a certain statement, assertion or rule is unambiguous. > I disagree with you that it is a fundamental flaw in the system, but > am always open to better suggestions at how to implement this stuff. > The hints were my first, best guess, and they have served us well. Yes, but... In the beginning, hints were used to let drivers know where to look for hardware. They were hints to the drivers so that drivers knew where to probe. Possibly before probing a fixed list of I/O ports where the ISA card could be configured to reside. The key point of that statement is that the drivers were already there. They were compiled-in by virtue of the kernel configuration that already included bus attachment information and resource lists. The hints didn't cause the instantiation of a driver! This is not what's happening now. Hints cause driver instantiations and as such are much more significant than originally designed. They stopped being hints and turned into something much less well- defined. > We > are at the point now where we must expand them either as John has > outlined, or we need to scrap them entirely in favor of something > better. What we cannot do is let the promise of something better that > isn't really being worked on stop us from expanding what we have. It has nothing to do with the promise of something better. It has everything to do with understanding of the problems. Put differently: extending what you have because you don't want to put in the effort of understanding the problem and working out how such could be solved is ultimately worse, because you end up with something that's not broken enough to fix but which will always cause you problems -- problems you can only accept because the alternative was not even considered. > Do you have something specific in mind that we can start working on > some kind of design document against? I don't have a design document, but I have mentioned in various emails what I think we should be doing. Unless there's sufficient agreement on the rough course of action will I be working on details. > It is OK if that's a series of > conversations, but we have to get off the inflection point we're at > now: No, you can't expand what's there, and there's no clearly > articulated 'something better'. I have been conversing. I have been expression my point of view. What I have not seen, until now, is an actual statement of intend to just look at it from a different angle and see if we can come up with some set of requirements. Everything so far has been pivoting around hints. We have them and we're extending them. What about letting the discussion pivot around the problems we're trying to solve and once we have that fleshed out see if and how we can use hints before we realize that it's better to start from scratch? > So if you could take a few minutes and write up a straw-man proposal > for what you see as doing it right, I think that would get us toward a > solution... As said previously in many of the emails on the subject: We need to seperate out the different uses or needs and come up with a layered solution of some sorts: The lowest layer is enumeration of the hardware. This, typically, is a combination of hardware self-enumeration, firmware-based enumeration or pure software-based enumeration (i.e. the proverbial hardcoded tables). On top of the hardware layer we have the newbus infrastructure layer that, given a view of the hardware provided by the hardware layer, constructs the newbus device tree and provides for wiring before the generic probe/attach sequence starts. On top of the newbus layer are the devices themselves. They use the newbus layer to obtain their resources and fetch device-driver specific settings. For the hardware layer we need a description of the hardware. The keying information is resource location or device path. The newbus layer needs a description of the wiring and/or routing. The keying information is resource location or device path. The device layer needs a description of per-instance driver options. The keying information is resource location or device path, combined with driver and unit number. Concretely: A simplified hardware description could be (key=ioport): ioport=0x3f8 -> iosize=8, type=UART, irq=4 A description for prewiring could be: (key=ioport): ioport=0x3f8 -> driver=sio, unit=0 A description for the driver could be (key=ioport_driver+unit): ioport=0x3f8, driver=sio, unit=0 -> fifosize=32 A serial console is defined alongside the hardware description. You don't define the hardware, so it shouldn't be part of it. You do describe intended use of the hardware, so it's should be in the hardware layer where you define it. As such, the serial console is keyed off of the ioport in the example above: ioport=0x3f8 -> what=console, baudrate=9600 This all makes it possible to replace the sio driver with uart and have a different set of driver descriptions for the same hardware: ioport=0x3f8, driver=uart, unit=any, clock=1843200 You also know that competely removing the newbus information (i.e. the prewiring) will not affect the view of the hardware. It will only affect which drivers get attached and which units are being assigned. You also know that if the (view of the) hardware changes, your newbus description will match where possible and be ignored where appropriate. This mean that if you previously had a newbus description that prewires a network interface to, say, bge2 and you removed the interface, you simply wont use the prewiring. It will later be used when the interface is added back. Apply RDB theory and you can start constructing the tables. From the tables you can derive a more suitable way of specifying the information and having it used early on by a kernel. Another thing to keep in mind is that any low-level console, whether serial or otherwise and whether using legacy devices or USB or firewire needs access to the hardware before we have newbus up-and running. That's why the console specification would be in the hardware decsription layer: you don't have newbus, no prewiring and no assigned devices. Moving forward, we should take OFW or EFI as an example of how you can describe hardware and morph that into something that allows us to: o compile into some binary form for compactness o can be loaded as a module or specified at the loader prompt. Once we have that, newbus descriptions (for prewiring) are trivially added. Driver descriptions (or more accurately driver directives) should be more like var=value lines because of the wide and unstructured nature of what drivers may need. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 01:49:55 2008 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 74FA616A417; Wed, 2 Jan 2008 01:49:55 +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 E24E213C45A; Wed, 2 Jan 2008 01:49:54 +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 m021mwMK039563; Tue, 1 Jan 2008 18:48:58 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 01 Jan 2008 18:49:09 -0700 (MST) Message-Id: <20080101.184909.195750479.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: <19740DB1-E759-4A61-8E1F-33AEAE74631E@mac.com> References: <20080101.135825.1943337000.imp@bsdimp.com> <19740DB1-E759-4A61-8E1F-33AEAE74631E@mac.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: 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: Wed, 02 Jan 2008 01:49:55 -0000 Marcel, thanks for taking the time to engage with me on this. The first part of my message does correct a couple of misconceptions you have, and may sound a bit argumentative. Sorry if it does. The second part looks to ways to incorporate your ideas into a good replacement scheme that would allow for richer expression. In message: <19740DB1-E759-4A61-8E1F-33AEAE74631E@mac.com> Marcel Moolenaar writes: : : On Jan 1, 2008, at 12:58 PM, M. Warner Losh wrote: : : > In message: : > Marcel Moolenaar writes: : > : Let's just fix this right... : > : > In many ways, you are complaining about the same thing that I've : > struggled with. Sometimes, hint.sio.0.addr=0x3e8 means 'bind : > whichever of the enumerated COM ports lives at 3e8 to sio0' (eg, cross : > binding of a device enumerated by other means to a driver/unit) and : > sometimes it means 'you have a COM port whose resource starts at : > 0x3e8'. : : Yes. We're going to use hints for too many things without making sure : that a certain statement, assertion or rule is unambiguous. : : > I disagree with you that it is a fundamental flaw in the system, but : > am always open to better suggestions at how to implement this stuff. : > The hints were my first, best guess, and they have served us well. : : Yes, but... : : In the beginning, hints were used to let drivers know where to look : for hardware. They were hints to the drivers so that drivers knew : where to probe. Possibly before probing a fixed list of I/O ports : where the ISA card could be configured to reside. In the beginning (when newbus was introduce circa 3.0) they were used by the busses to assign resources to the drivers they were adding. It just turned out that the 'hints' were compiled into tables the drivers used. In 4.x, the hints migrated from the config file to a text file called typically device.hints. Throughout these underlying changes, the drivers have never really known about resource hints. The bus is the only thing that parses and consumes them (the busses were changed from using the compiled in tables to using hints in 4.0). The ISA bus used to be the only one that looked for the 'at' key with a value of 'isa' or 'isa0', and it used that to populate the children on the isa bus. The drivers whose nodes are added to the tree as hints have no idea that the resources came from hints or from some other enumeration mechanism. They just call bus_alloc_resource and they get the resource. The removal of probing a fixed list of I/O ports happened at the same time that newbus was introduced into the system. There may have been one or two stragglers after we did the bulk of this work, but nearly all of it was done when newbus was committed. See devinfo -v on my system: isa0 ppc0 sc0 sio1 sio2 sio3 vga0 orm0 I do not have the sio or ppc drivers in my kernel at all, yet they appear to be bound to nodes in the tree by virtue of the hints that are present in device.hints. This is what allows the drivers to attach to nodes in the system if I were to dynamically load them. : The key point of that statement is that the drivers were already : there. They were compiled-in by virtue of the kernel configuration : that already included bus attachment information and resource lists. : The hints didn't cause the instantiation of a driver! Actually, they did. You are confusing the code that's in the kernel to device nodes in the tree. The hints will *ALWAYS* be there, even when the appropriate driver isn't compiled into the tree. The device nodes in the device tree will be there, unattached. : This is not what's happening now. Hints cause driver instantiations : and as such are much more significant than originally designed. : They stopped being hints and turned into something much less well- : defined. What is happening now is what has always happened. : > We : > are at the point now where we must expand them either as John has : > outlined, or we need to scrap them entirely in favor of something : > better. What we cannot do is let the promise of something better that : > isn't really being worked on stop us from expanding what we have. : : It has nothing to do with the promise of something better. It : has everything to do with understanding of the problems. : : Put differently: extending what you have because you don't want : to put in the effort of understanding the problem and working out : how such could be solved is ultimately worse, because you end up : with something that's not broken enough to fix but which will : always cause you problems -- problems you can only accept because : the alternative was not even considered. We can't let your aesthetic objections to the system that's basically working today block further efforts. I hate to be so blunt about it, but we as a project have gone more with a rough consensus and working code over a pie in the sky perfect design with no implementation. Having said that, I'm willing to consider an alternative, but it has to handle the functionality that hints handle today. : > Do you have something specific in mind that we can start working on : > some kind of design document against? : : I don't have a design document, but I have mentioned in various : emails what I think we should be doing. Unless there's sufficient : agreement on the rough course of action will I be working on : details. : : > It is OK if that's a series of : > conversations, but we have to get off the inflection point we're at : > now: No, you can't expand what's there, and there's no clearly : > articulated 'something better'. : : I have been conversing. I have been expression my point of view. : What I have not seen, until now, is an actual statement of intend : to just look at it from a different angle and see if we can come : up with some set of requirements. Everything so far has been : pivoting around hints. We have them and we're extending them. : What about letting the discussion pivot around the problems we're : trying to solve and once we have that fleshed out see if and how : we can use hints before we realize that it's better to start : from scratch? The reason for that is that hints are basically working. If there's another scheme that can work, then we can move to it, but until then we have hints and we shouldn't be inventing hacks to get around the fact that hints are apparently misunderstood. I'm happy to work with you on a better scheme from scratch, but we have to keep in mind that we need certain functionality today. : > So if you could take a few minutes and write up a straw-man proposal : > for what you see as doing it right, I think that would get us toward a : > solution... : : As said previously in many of the emails on the subject: We need to : seperate out the different uses or needs and come up with a layered : solution of some sorts: : The lowest layer is enumeration of the hardware. This, typically, is : a combination of hardware self-enumeration, firmware-based enumeration : or pure software-based enumeration (i.e. the proverbial hardcoded : tables). : : On top of the hardware layer we have the newbus infrastructure layer : that, given a view of the hardware provided by the hardware layer, : constructs the newbus device tree and provides for wiring before the : generic probe/attach sequence starts. : : On top of the newbus layer are the devices themselves. They use the : newbus layer to obtain their resources and fetch device-driver : specific settings. : : For the hardware layer we need a description of the hardware. The : keying information is resource location or device path. : : The newbus layer needs a description of the wiring and/or routing. : The keying information is resource location or device path. : : The device layer needs a description of per-instance driver options. : The keying information is resource location or device path, combined : with driver and unit number. I think you are mixing layers here. The newbus layer is in charge of assigning unit numbers. The driver shouldn't know anything at all about device paths or resources that bind it to a unit. It is told 'probe this node and your unit number is X' and the driver has to like it. There's a kludge in place now that I've removed in my tree for sio so that the serial port would get the right unit number, but that has always been considered an aberration that should be eliminated at the first change possible. : Concretely: : : A simplified hardware description could be (key=ioport): : ioport=0x3f8 -> iosize=8, type=UART, irq=4 : : A description for prewiring could be: (key=ioport): : ioport=0x3f8 -> driver=sio, unit=0 : : A description for the driver could be (key=ioport_driver+unit): : ioport=0x3f8, driver=sio, unit=0 -> fifosize=32 : : A serial console is defined alongside the hardware description. : You don't define the hardware, so it shouldn't be part of it. : You do describe intended use of the hardware, so it's should : be in the hardware layer where you define it. As such, the : serial console is keyed off of the ioport in the example above: : ioport=0x3f8 -> what=console, baudrate=9600 : : This all makes it possible to replace the sio driver with uart : and have a different set of driver descriptions for the same : hardware: : ioport=0x3f8, driver=uart, unit=any, clock=1843200 I think you are mixing the levels of abstraction again. We don't want the hardware locators to be used once the newbus bus has assigned a unit and driver to the device. This is the main problem that I have with this design: it blurs the line between the hardware location and other ways of locating a device. : You also know that competely removing the newbus information : (i.e. the prewiring) will not affect the view of the hardware. : It will only affect which drivers get attached and which units : are being assigned. : : You also know that if the (view of the) hardware changes, your : newbus description will match where possible and be ignored : where appropriate. This mean that if you previously had a newbus : description that prewires a network interface to, say, bge2 and : you removed the interface, you simply wont use the prewiring. : It will later be used when the interface is added back. : : Apply RDB theory and you can start constructing the tables. : From the tables you can derive a more suitable way of specifying : the information and having it used early on by a kernel. I need more details than this. I hate to keep pressing for more details, but I think that your view of the world leads to the same blurring of abstraction levels that we have with hints today. : Another thing to keep in mind is that any low-level console, : whether serial or otherwise and whether using legacy devices : or USB or firewire needs access to the hardware before we : have newbus up-and running. That's why the console specification : would be in the hardware decsription layer: you don't have : newbus, no prewiring and no assigned devices. If we can make consoles regular in the system, so much the better, but we shouldn't let their needs drive the design. Consoles are a special case today, and if they remain a special case, then I'm OK with that. It may be the best way to cope with consoles is to have a 'console' record that each of the possible consoles lookup. Those consoles that match would bid for which one wins (or we support multiple ones, it doesn't really matter to me). The matching console would then use the value from the console key as a set of key=value pairs to give it what it needs to do its job. : Moving forward, we should take OFW or EFI as an example of : how you can describe hardware and morph that into something : that allows us to: : o compile into some binary form for compactness : o can be loaded as a module or specified at the : loader prompt. : : Once we have that, newbus descriptions (for prewiring) are : trivially added. Driver descriptions (or more accurately : driver directives) should be more like var=value lines because : of the wide and unstructured nature of what drivers may need. So the only significant change from the current hints scheme is just the key lookup for the device? right now the only key you can use is the device name and unit for a given variable. Your scheme would allow for more types of lookups than just the one key we currently provide. Or put another way each device node in the newbus tree would have some attributes. One would use those attributes, in addition to the name/number to look up other attributes of the device. I like this idea in theory. I'd like to explore ways to make it more concrete for both the device driver interface for drivers (including console drivers) as well as for busses that have to deal with wiring device driver nodes in the newbus tree to unit numbers, drivers and actual hardware. I'll be out in the bay area in a couple of weeks. I think we're doing some talking past each other in this email exchange. Maybe we could get together while I'm out there and go over your ideas and see how we can move to that kind of system. I think this might help us get the ideas into a more concrete form than doing it just through email. Are you up for that? If so, I can send you the dates I'm available... Warner From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 04:48:12 2008 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 413BC16A419; Wed, 2 Jan 2008 04:48:12 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.79]) by mx1.freebsd.org (Postfix) with ESMTP id 297FB13C467; Wed, 2 Jan 2008 04:48:12 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp010-s [10.150.69.73]) by smtpoutm.mac.com (Xserve/smtpout016/MantshX 4.0) with ESMTP id m024m50l026376; Tue, 1 Jan 2008 20:48:05 -0800 (PST) Received: from [192.168.1.100] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/asmtp010/MantshX 4.0) with ESMTP id m024m0Uu013442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Jan 2008 20:48:00 -0800 (PST) Message-Id: <3FAE3F14-C1B6-41BB-8DB0-A88C1DD09F66@mac.com> From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20080101.184909.195750479.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: Tue, 1 Jan 2008 20:47:59 -0800 References: <20080101.135825.1943337000.imp@bsdimp.com> <19740DB1-E759-4A61-8E1F-33AEAE74631E@mac.com> <20080101.184909.195750479.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) 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: Wed, 02 Jan 2008 04:48:12 -0000 On Jan 1, 2008, at 5:49 PM, M. Warner Losh wrote: > : > I disagree with you that it is a fundamental flaw in the system, > but > : > am always open to better suggestions at how to implement this > stuff. > : > The hints were my first, best guess, and they have served us well. > : > : Yes, but... > : > : In the beginning, hints were used to let drivers know where to look > : for hardware. They were hints to the drivers so that drivers knew > : where to probe. Possibly before probing a fixed list of I/O ports > : where the ISA card could be configured to reside. > > In the beginning (when newbus was introduce circa 3.0) they were used > by the busses to assign resources to the drivers they were adding. It > just turned out that the 'hints' were compiled into tables the drivers > used. In 4.x, the hints migrated from the config file to a text file > called typically device.hints. Throughout these underlying changes, > the drivers have never really known about resource hints. The bus is > the only thing that parses and consumes them (the busses were changed > from using the compiled in tables to using hints in 4.0). The ISA bus > used to be the only one that looked for the 'at' key with a value of > 'isa' or 'isa0', and it used that to populate the children on the isa > bus. The drivers whose nodes are added to the tree as hints have no > idea that the resources came from hints or from some other enumeration > mechanism. They just call bus_alloc_resource and they get the > resource. > The removal of probing a fixed list of I/O ports happened at the same > time that newbus was introduced into the system. There may have been > one or two stragglers after we did the bulk of this work, but nearly > all of it was done when newbus was committed. > > See devinfo -v on my system: > isa0 > ppc0 > sc0 > sio1 > sio2 > sio3 > vga0 > orm0 > > I do not have the sio or ppc drivers in my kernel at all, yet they > appear to be bound to nodes in the tree by virtue of the hints that > are present in device.hints. This is what allows the drivers to > attach to nodes in the system if I were to dynamically load them. Let me use the above to better express my philosophical approach: The fact that that devinfo shows you that non-existent drivers are bound to newbus nodes is exactly the problem with hints. Pre-newbus the kernel configuration defined the instantiations and as such the list of drivers that were needed. Both (i.e. the drivers and their instantiations) came from a single description and could never be out of sync. Nowadays we have the drivers coming from the kernel configuration (or dynamically through module loading) and instantiations coming from the hints file. These two are typically out of sync with each other. If hints were tentative, then we wouldn't have newbus nodes for driver instantiations if the driver in question didn't exist. It's fundamentally wrong to instantiate a driver that doesn't exist. I mean, what does that mean anyway? > : The key point of that statement is that the drivers were already > : there. They were compiled-in by virtue of the kernel configuration > : that already included bus attachment information and resource lists. > : The hints didn't cause the instantiation of a driver! > > Actually, they did. You are confusing the code that's in the kernel > to device nodes in the tree. The hints will *ALWAYS* be there, even > when the appropriate driver isn't compiled into the tree. The device > nodes in the device tree will be there, unattached. Yes, you're right. I misspoke. The hints caused the instantiations. See also above. > : This is not what's happening now. Hints cause driver instantiations > : and as such are much more significant than originally designed. > : They stopped being hints and turned into something much less well- > : defined. > > What is happening now is what has always happened. As per above: previously the driver was guaranteed to exist, this is not the case anymore, so the meaning of hints was changed in a subtle way, not because we redefined them, but because we changed the environment in which they were used unchanged. We never accounted for that as far as I can see. > : > We > : > are at the point now where we must expand them either as John has > : > outlined, or we need to scrap them entirely in favor of something > : > better. What we cannot do is let the promise of something > better that > : > isn't really being worked on stop us from expanding what we have. > : > : It has nothing to do with the promise of something better. It > : has everything to do with understanding of the problems. > : > : Put differently: extending what you have because you don't want > : to put in the effort of understanding the problem and working out > : how such could be solved is ultimately worse, because you end up > : with something that's not broken enough to fix but which will > : always cause you problems -- problems you can only accept because > : the alternative was not even considered. > > We can't let your aesthetic objections to the system that's basically > working today block further efforts. I hate to be so blunt about it, > but we as a project have gone more with a rough consensus and working > code over a pie in the sky perfect design with no implementation. Again: it has nothing to do with pie in the sky. It has everything to do with getting the concepts right and then deciding how we want to implement. I didn't write uart(4) because I liked doing it. I wrote uart(4) because sio(4) is unportable and encumbered. It's been hacked to solve problems it shouldn't have to solve. Likewise for geom_part. I don't like doing it, but it's obvious that the minimal amount of effort put into solving the problem right has resulted in an abundance of flaky tools and something horrendous as libdisk. Whenever FreeBSD is ported to a new platform, the biggest hurdle isn't so much the MD code; it's coding the partitioning of disks so that you can install with sysinstall. I'm saying this because sooner or later someone will have to overhaul code to make it work in new environments and one of the problems of working on non-i386 is that you end up being the one to do it. I'd like to minimize the change of me having to overhaul this too... All I'm saying is: define the problem. We can still decide to partly solve the problem and extend hints. If anything, do it to prove me wrong :-) > Having said that, I'm willing to consider an alternative, but it has > to handle the functionality that hints handle today. Only fair. > : > Do you have something specific in mind that we can start working > on > : > some kind of design document against? > : > : I don't have a design document, but I have mentioned in various > : emails what I think we should be doing. Unless there's sufficient > : agreement on the rough course of action will I be working on > : details. > : > : > It is OK if that's a series of > : > conversations, but we have to get off the inflection point we're > at > : > now: No, you can't expand what's there, and there's no clearly > : > articulated 'something better'. > : > : I have been conversing. I have been expression my point of view. > : What I have not seen, until now, is an actual statement of intend > : to just look at it from a different angle and see if we can come > : up with some set of requirements. Everything so far has been > : pivoting around hints. We have them and we're extending them. > : What about letting the discussion pivot around the problems we're > : trying to solve and once we have that fleshed out see if and how > : we can use hints before we realize that it's better to start > : from scratch? > > The reason for that is that hints are basically working. I disagree. They're simply not causing problems big enough for people to notice or care about. There are many little things that are fundamentally flawed and that have been plastered over to sort-of work. I think we can do much better than that, especially if we're going to build another floor on this house of cards. > : > So if you could take a few minutes and write up a straw-man > proposal > : > for what you see as doing it right, I think that would get us > toward a > : > solution... > : > : As said previously in many of the emails on the subject: We need to > : seperate out the different uses or needs and come up with a layered > : solution of some sorts: > : The lowest layer is enumeration of the hardware. This, typically, is > : a combination of hardware self-enumeration, firmware-based > enumeration > : or pure software-based enumeration (i.e. the proverbial hardcoded > : tables). > : > : On top of the hardware layer we have the newbus infrastructure layer > : that, given a view of the hardware provided by the hardware layer, > : constructs the newbus device tree and provides for wiring before the > : generic probe/attach sequence starts. > : > : On top of the newbus layer are the devices themselves. They use the > : newbus layer to obtain their resources and fetch device-driver > : specific settings. > : > : For the hardware layer we need a description of the hardware. The > : keying information is resource location or device path. > : > : The newbus layer needs a description of the wiring and/or routing. > : The keying information is resource location or device path. > : > : The device layer needs a description of per-instance driver options. > : The keying information is resource location or device path, combined > : with driver and unit number. > > I think you are mixing layers here. The newbus layer is in charge of > assigning unit numbers. You misunderstand. I'm not mixing things up. The newbus layer is assigning the unit numbers, but it's not a key at that layer. It's a key at the layer above. At the newbus layer it's just a property. In fact, it's probably better that the unit number is not part of the key, because the unit number doesn't mean anything. Its the device path with driver combination that's important (see also below). > The driver shouldn't know anything at all > about device paths or resources that bind it to a unit. Correct. The newbus layer abstracts it. This is not to say that the information specific to the device layer (or should I say driver layer) is not to be keyed on the device path. Take for example the following case: In a computer are 2 serial ports. One is using a standard chips and the other is using one with a non-standard FIFO size. The driver needs to know the FIFO size to avoid overrunning the Tx FIFO. So, for each instance of the driver there needs to be a property that describes the FIFO size. Since the FIFO size is a property of the hardware and not of the driver instance and since the need for a FIFO size property is dependent upon the driver, the key is {device path, driver}. This is conceptually. It does mean that the driver knows about device paths. > It is told > 'probe this node and your unit number is X' and the driver has to like > it. There's a kludge in place now that I've removed in my tree for > sio so that the serial port would get the right unit number, but that > has always been considered an aberration that should be eliminated at > the first change possible. The need for the kluge is another sign that hints are misused: you don't specify which driver instance is the console, because that can change. You specify which physical port is to be used as the console and have the driver instance that maps to that port do the right thing. That's why uart(4) doesn't need to be kluged and why uart(4) works when the console is defined by ACPI tables and DIG64 HCDP tables or that it respects the OpenFirmware settings... > : Concretely: > : > : A simplified hardware description could be (key=ioport): > : ioport=0x3f8 -> iosize=8, type=UART, irq=4 > : > : A description for prewiring could be: (key=ioport): > : ioport=0x3f8 -> driver=sio, unit=0 > : > : A description for the driver could be (key=ioport_driver+unit): > : ioport=0x3f8, driver=sio, unit=0 -> fifosize=32 > : > : A serial console is defined alongside the hardware description. > : You don't define the hardware, so it shouldn't be part of it. > : You do describe intended use of the hardware, so it's should > : be in the hardware layer where you define it. As such, the > : serial console is keyed off of the ioport in the example above: > : ioport=0x3f8 -> what=console, baudrate=9600 > : > : This all makes it possible to replace the sio driver with uart > : and have a different set of driver descriptions for the same > : hardware: > : ioport=0x3f8, driver=uart, unit=any, clock=1843200 > > I think you are mixing the levels of abstraction again. We don't want > the hardware locators to be used once the newbus bus has assigned a > unit and driver to the device. It's not mixed. It's conceptual. The newbus layer abstracts the details from the driver so that the driver doesn't have to know. Think IVARs. The driver doesn't know where they came from. It's the newbus layer that tied the information to the device node. > This is the main problem that I have > with this design: it blurs the line between the hardware location and > other ways of locating a device. No it doesn't. I described a concept. The problem is that it looks like you interpret it in term of an implementation. In fact, that's the whole problem in the discussion about hints: people don't rise above the implementation. Everything I say, no matter how abstract, is interpreted from an implementation point of view. No wonder we're not getting anywhere :-) Seriously: When a piece of information applies to a layer, it does not mean that there's code that belongs to that layer that gropes in some data structure that implements the information. It means that the infor- mation has meaning to that layer and that access to that information is abstracted by the layers underneath. > : You also know that competely removing the newbus information > : (i.e. the prewiring) will not affect the view of the hardware. > : It will only affect which drivers get attached and which units > : are being assigned. > : > : You also know that if the (view of the) hardware changes, your > : newbus description will match where possible and be ignored > : where appropriate. This mean that if you previously had a newbus > : description that prewires a network interface to, say, bge2 and > : you removed the interface, you simply wont use the prewiring. > : It will later be used when the interface is added back. > : > : Apply RDB theory and you can start constructing the tables. > : From the tables you can derive a more suitable way of specifying > : the information and having it used early on by a kernel. > > I need more details than this. I hate to keep pressing for more > details, but I think that your view of the world leads to the same > blurring of abstraction levels that we have with hints today. I don't mind explaining myself in more detail or more concretely. Unfortunately, I do like to get something back: I would like people to test various cases and let me know if there are cases I haven't thought about or that I'm overlooking. The more feedback about the concepts the better I can fill in the gaps... > : Another thing to keep in mind is that any low-level console, > : whether serial or otherwise and whether using legacy devices > : or USB or firewire needs access to the hardware before we > : have newbus up-and running. That's why the console specification > : would be in the hardware decsription layer: you don't have > : newbus, no prewiring and no assigned devices. > > If we can make consoles regular in the system, so much the better, but > we shouldn't let their needs drive the design. Consoles are a special > case today, and if they remain a special case, then I'm OK with that. uart(4) does this correctly already. It is a special case no matter how you look at it, but it needs to be made a special case throughout the layers to get the proper (abstract) support to avoid it being a kluge. We have it in place already for uart(4) so the only thing we need to avoid is breaking it. > : Moving forward, we should take OFW or EFI as an example of > : how you can describe hardware and morph that into something > : that allows us to: > : o compile into some binary form for compactness > : o can be loaded as a module or specified at the > : loader prompt. > : > : Once we have that, newbus descriptions (for prewiring) are > : trivially added. Driver descriptions (or more accurately > : driver directives) should be more like var=value lines because > : of the wide and unstructured nature of what drivers may need. > > So the only significant change from the current hints scheme is just > the key lookup for the device? The key lookup makes all the difference, but yes, if we get the keying right and find that we don't have to abandon the hints concept as it is, then all the better and I don't see a reason for overhauls. > right now the only key you can use is > the device name and unit for a given variable. Your scheme would > allow for more types of lookups than just the one key we currently > provide. Or put another way each device node in the newbus tree would > have some attributes. One would use those attributes, in addition to > the name/number to look up other attributes of the device. The information available at each level differs. At the hardware level there's no notion of newbus or drivers. The hardware exists independent of that. So, "hints" that apply to the hardware layer have no correspondence to newbus nodes and/or driver instances. As such, you cannot use driver names or unit numbers as a key. The one thing that is known to be unique is the (primary) I/O address (either port or memory mapped) or alternatively, a device path of some sorts. In any case, you cannot lookup the hardware information with a key that consists of driver+unit, unless the hardware is attached by the driver. After the attach of a driver, the driver+unit, unique by definition, can be used as a secondary key. This secondary key is removed and meaningless when the driver detaches again. As such, the secondary key cannot be stored on disk. Only the I/O resource or the device path is immutable and thus safe to be used across reboots. Wiring of devices can then be defined as a pre-determined mapping between the primary key and secondary key, provided the driver actually exists. Without wiring the secondary key is mapped by virtue of the newbus probe and attach methods. Drivers don't need to know the primary key, because the secondary key is mapped to the primary key so you can get the hardware information by using the secondary key as well. This of course is abstract, not something that's done in actuality this way (I presume)... > I'll be out in the bay area in a couple of weeks. I think we're doing > some talking past each other in this email exchange. Maybe we could > get together while I'm out there and go over your ideas and see how we > can move to that kind of system. I think this might help us get the > ideas into a more concrete form than doing it just through email. Are > you up for that? If so, I can send you the dates I'm available... That sounds like an excellent plan. I'm sure we can find a couple of hours to flesh this out a bit... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 05:14:03 2008 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 1856916A41B for ; Wed, 2 Jan 2008 05:14:03 +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 8BE2F13C447 for ; Wed, 2 Jan 2008 05:14:02 +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 m025BIAL040900; Tue, 1 Jan 2008 22:11:18 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 01 Jan 2008 22:11:32 -0700 (MST) Message-Id: <20080101.221132.-1343615593.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: <20080101.184909.195750479.imp@bsdimp.com> References: <20080101.135825.1943337000.imp@bsdimp.com> <19740DB1-E759-4A61-8E1F-33AEAE74631E@mac.com> <20080101.184909.195750479.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: 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: Wed, 02 Jan 2008 05:14:03 -0000 In message: <20080101.184909.195750479.imp@bsdimp.com> "M. Warner Losh" writes: : In the beginning (when newbus was introduce circa 3.0) they were used : by the busses to assign resources to the drivers they were adding. It : just turned out that the 'hints' were compiled into tables the drivers : used. In 4.x, the hints migrated from the config file to a text file : called typically device.hints. Throughout these underlying changes, : the drivers have never really known about resource hints. The bus is : the only thing that parses and consumes them (the busses were changed : from using the compiled in tables to using hints in 4.0). s/4/5/g in the above. The switch from config generated tables to texual hints happened after RELENG_4 was branched. Also, Newbus was introduced in 3.2 not 3.0, although it was used for the alpha port in 3.0. Warner From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 11:07:59 2008 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 9D21216A474 for ; Wed, 2 Jan 2008 11:07:59 +0000 (UTC) (envelope-from alexbez@gmail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.248]) by mx1.freebsd.org (Postfix) with ESMTP id 3154313C4E3 for ; Wed, 2 Jan 2008 11:07:58 +0000 (UTC) (envelope-from alexbez@gmail.com) Received: by hs-out-2122.google.com with SMTP id j58so4340146hsj.11 for ; Wed, 02 Jan 2008 03:07:58 -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:in-reply-to:mime-version:content-type:references; bh=HOL5SUHQh1pElLTUgTtvBcpQCJwdT2XeiPFwKuAgw1Y=; b=uTWglNT5igIOhvAkzp490Gjdbetj1Kznk/u+fBUkyZWGMz22aaaGf9oWUJpuoQyUrxIUiXxoaLnZRMPxGA+tsDpq6irjurLmz7jyA861t/4kqAvUIGd1J8SlZsb+8hDZRw/Z/C+6LE0NQYnGdwsBMlQVZJ6AjOaIQg4+ORtxXqg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=VXr/7cooc3vLa5EGyECs+qJ/YjBDRDWsO+cy2FgJnbGwsMhzo8vYgAOp8IGytqQtLNtQMHDdsE6qznkJCWqcz0vNyOW5uv4g3ieG3Zqm6+t7Fbi8zJ+ZxC00dVZ7zUd8dtp07t3S4szdumeUrO9RbmgBWOW4eIxNAy+N3T4w4Vo= Received: by 10.150.155.1 with SMTP id c1mr1806764ybe.155.1199270435772; Wed, 02 Jan 2008 02:40:35 -0800 (PST) Received: by 10.150.149.12 with HTTP; Wed, 2 Jan 2008 02:40:35 -0800 (PST) Message-ID: <12e0c06a0801020240m42818a32r86ac6e4dc9ca121@mail.gmail.com> Date: Wed, 2 Jan 2008 12:40:35 +0200 From: "Alexander Bezprozvanny" To: freebsd-embedded@freebsd.org In-Reply-To: <12e0c06a0801020216s3a881e7cu2fbb9e555133289d@mail.gmail.com> MIME-Version: 1.0 References: <12e0c06a0801020216s3a881e7cu2fbb9e555133289d@mail.gmail.com> 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: [Q] Porting FreeBSD to run on top of some proprietary hard real time OS on exotic HW? 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: Wed, 02 Jan 2008 11:07:59 -0000 Hi all, We are facing the need to port FreeBSD to some (exotic) HW platform. I am totally new to this business, so I need to do some homework before coming up with a sensible project plan. The target HW platform already has some sort of a primitive proprietary hard real time OS running on it. Current plan is to have FreeBSD running in the idle process of that OS. The question is: what would be the requirements to that underlying OS from FreeBSD? What services/APIs shall it provide for FreeBSD? How the HW virtualization works in this case (RTC, etc)? If someone could point me to some resources/discussions on this subject, that would be most appreciated. Thank you! Alexander Bezprozvanny P.S. I have posted this to freebsd-platforms, but that mailing list seems to be pretty dead: for the last 12 months only spam bots and yours sincerely were posting there :-) so I decided to crosspost it to this list. From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 18:05:07 2008 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 910FB16A419 for ; Wed, 2 Jan 2008 18:05:07 +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 3B00313C465 for ; Wed, 2 Jan 2008 18:05:06 +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 227032756-1834499 for multiple; Wed, 02 Jan 2008 13:03:00 -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 m02I4kCj018326; Wed, 2 Jan 2008 13:04:52 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marcel Moolenaar Date: Wed, 2 Jan 2008 12:30:01 -0500 User-Agent: KMail/1.9.6 References: <200712311606.25424.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801021230.01517.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]); Wed, 02 Jan 2008 13:04:52 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5343/Wed Jan 2 12:41:01 2008 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: 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: Wed, 02 Jan 2008 18:05:07 -0000 On Tuesday 01 January 2008 03:09:50 pm Marcel Moolenaar wrote: > > On Dec 31, 2007, at 1:06 PM, John Baldwin wrote: > > >> 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). > > > > Redo the 'at' hints like this (pci was already this way in the > > existing hint > > wiring stuff anyway, i.e. it's _not_ a new-bus device name in > > 'at'). I'll > > use all-caps to make it stand out: > > While I think that's a good thing, the confusion to the user > when it comes to the unit number is already present. People > already assume that if they have hint.sio.0.at="isa" that > they expect to see device sio0. I fear that it's exactly the > same with "device.COM1.at=ISA. If the 1 on COM1 is just a > means to distinguish multiple COM devices, then it's much > better to use a more structural approach, eliminate the unit > and instead key-off of something that's truly identifying. It's a string. Look at your PC, on the back it has a label with "COM1" or "COMA" or some such. You can call it 'device.IHATECOMPUTERS' if you want. The idea is to just give a collection of properties a name so that they can all be bound together. > In other words: hints historically mix the hardware description > with the assignment of the driver and the unit number. Your > proposal has the same flaws. The whole thing is just awkward > for the user and impossible to implement unambiguously. COM1 is not a new-bus name. Nowhere in any of the device.FOO is a single new-bus name execept for the possible 'driver=foo' property to bind to a driver. That all said, I obviously am unable to come up with anything acceptable to your tastes so I'll just give up and work on something else. -- John Baldwin From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 18:05:36 2008 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 6B66F16A41B for ; Wed, 2 Jan 2008 18:05:36 +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 27D4713C474 for ; Wed, 2 Jan 2008 18:05:36 +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 227032782-1834499 for multiple; Wed, 02 Jan 2008 13:03:11 -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 m02I4kCl018326; Wed, 2 Jan 2008 13:05:02 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marcel Moolenaar Date: Wed, 2 Jan 2008 13:03:31 -0500 User-Agent: KMail/1.9.6 References: <20080101.184909.195750479.imp@bsdimp.com> <3FAE3F14-C1B6-41BB-8DB0-A88C1DD09F66@mac.com> In-Reply-To: <3FAE3F14-C1B6-41BB-8DB0-A88C1DD09F66@mac.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200801021303.39518.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 02 Jan 2008 13:05:03 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5343/Wed Jan 2 12:41:01 2008 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: 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: Wed, 02 Jan 2008 18:05:36 -0000 On Tuesday 01 January 2008 11:47:59 pm Marcel Moolenaar wrote: > On Jan 1, 2008, at 5:49 PM, M. Warner Losh wrote: > > See devinfo -v on my system: > > isa0 > > ppc0 > > sc0 > > sio1 > > sio2 > > sio3 > > vga0 > > orm0 > > > > I do not have the sio or ppc drivers in my kernel at all, yet they > > appear to be bound to nodes in the tree by virtue of the hints that > > are present in device.hints. This is what allows the drivers to > > attach to nodes in the system if I were to dynamically load them. > > Let me use the above to better express my philosophical approach: > > The fact that that devinfo shows you that non-existent drivers are > bound to newbus nodes is exactly the problem with hints. Pre-newbus > the kernel configuration defined the instantiations and as such the > list of drivers that were needed. Both (i.e. the drivers and their > instantiations) came from a single description and could never be > out of sync. > Nowadays we have the drivers coming from the kernel configuration > (or dynamically through module loading) and instantiations coming > from the hints file. These two are typically out of sync with each > other. If hints were tentative, then we wouldn't have newbus nodes > for driver instantiations if the driver in question didn't exist. > > It's fundamentally wrong to instantiate a driver that doesn't exist. > I mean, what does that mean anyway? Agreed, and device.FOO would create an unknownX device (much like unprobed PNPBIOS or ACPI-enumerated devices) with a set of properties (if the bus impl uses properties to create devices and doesn't use them purely as additional metadata). For example, I actually figured that the default device.hints type stuff for COM1 would look like this: device.COM1.at="isa" device.COM1.port="0x3f8-0x3ff" device.COM1.irq=4 device.COM1.pnpid="PNP0500" which is what you get with ACPI/PnPBIOS. On i386/amd64 users would probably wish to bind it using something like: device.COM1.driver="sio" device.COM1.unit=0 but it wouldn't be required. Note that it would be nice to just say 'device.COM1.unit=0' and not specify a driver at all, but that would not be easy to implement in new-bus. -- John Baldwin From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 19:15:04 2008 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 CA3F516A469; Wed, 2 Jan 2008 19:15:04 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id A506E13C469; Wed, 2 Jan 2008 19:15:04 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp003-s [10.150.69.66]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id m02JEwmE014259; Wed, 2 Jan 2008 11:14:58 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp003/MantshX 4.0) with ESMTP id m02JEtmV011289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Jan 2008 11:14:56 -0800 (PST) Message-Id: <0E7F7277-75F4-4A5A-924D-97C0C9D940CD@mac.com> From: Marcel Moolenaar To: John Baldwin In-Reply-To: <200801021303.39518.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: Wed, 2 Jan 2008 11:14:55 -0800 References: <20080101.184909.195750479.imp@bsdimp.com> <3FAE3F14-C1B6-41BB-8DB0-A88C1DD09F66@mac.com> <200801021303.39518.jhb@freebsd.org> X-Mailer: Apple Mail (2.915) 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: Wed, 02 Jan 2008 19:15:04 -0000 On Jan 2, 2008, at 10:03 AM, John Baldwin wrote: > Agreed, and device.FOO would create an unknownX device (much like > unprobed > PNPBIOS or ACPI-enumerated devices) with a set of properties (if the > bus impl > uses properties to create devices and doesn't use them purely as > additional > metadata). For example, I actually figured that the default > device.hints type > stuff for COM1 would look like this: > > device.COM1.at="isa" > device.COM1.port="0x3f8-0x3ff" > device.COM1.irq=4 > device.COM1.pnpid="PNP0500" BTW: I like the port range. > which is what you get with ACPI/PnPBIOS. On i386/amd64 users would > probably > wish to bind it using something like: > > device.COM1.driver="sio" > device.COM1.unit=0 > > but it wouldn't be required. Note that it would be nice to just > say 'device.COM1.unit=0' and not specify a driver at all, but that > would not > be easy to implement in new-bus. It can also cause conflicts. With uart and sio, you can wire both to the same unit, based on the fact that sio attaches to legacy devices by default and uart attaches to puc by default. If you remove the sio driver, then you end up with 2 wiring directives for the same unit that now apply to the same driver. Explicitly specifying the driver+unit makes it clear what is meant: if there are multiple directives for the same driver+unit, then it's obvious that the directives are conflicting and thus that it's pilot error. Anyway, back to hints: your new approach is not disliked by me. It fits my concept for the most part. However, in order to support embedded hardware, we need to extend the syntax (like using a range for the I/O port). Extending the syntax may involve some significant work; even to the extend that we can call it a rewrite, even if we keep calling it hints. More examples: the e500 core can have up to 4 MACs. Each MAC has 3 interrupts. We need to support this. Also, some devices have multiple I/O resource ranges. This too needs to be supported. If we can modify the current hints slightly to support it than I'm happy. It's just that I have not seen any consideration for it and could only assume it would fall through the cracks. Also, A syntax like: FOO { sub1=a sub2=b } ... can be considered syntactic sugaring, because it can mean exactly the same as: FOO.sub1=a FOO.sub2=b This too is exactly like hints. So, even a discussion about syntax does not mean we need to toss out everything we have and start from scratch. The bottomline: I'm not arguing that we cannot end up with something that looks like hints. I'm arguing that if we take hints *as they are* and apply your tweaks, that we don't solve all the problems we're having or know we will have. More examples: I think we need to make hints conditional so that they can be included in case they're needed, but can be disabled/masked in case they're not (and more specifically when they're wrong and fry your SoC). Since hints as we have them today are unconditional, I can only object to using hints because of the fact they are unconditional and there's no intention to make them conditional. Anyway: I don't mind if you decide to step away from this, but I do think you're making a mistake in that case. If anything, it's important that people keep arguing to make sure that we find the right balance... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 20:19:08 2008 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 873FE16A477 for ; Wed, 2 Jan 2008 20:19:08 +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 44B6E13C465 for ; Wed, 2 Jan 2008 20:19:08 +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 227051836-1834499 for multiple; Wed, 02 Jan 2008 15:17:00 -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 m02KIpIc019397; Wed, 2 Jan 2008 15:18:54 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marcel Moolenaar Date: Wed, 2 Jan 2008 14:53:02 -0500 User-Agent: KMail/1.9.6 References: <200801021303.39518.jhb@freebsd.org> <0E7F7277-75F4-4A5A-924D-97C0C9D940CD@mac.com> In-Reply-To: <0E7F7277-75F4-4A5A-924D-97C0C9D940CD@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801021453.02931.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]); Wed, 02 Jan 2008 15:18:54 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5343/Wed Jan 2 12:41:01 2008 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: 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: Wed, 02 Jan 2008 20:19:08 -0000 On Wednesday 02 January 2008 02:14:55 pm Marcel Moolenaar wrote: > > On Jan 2, 2008, at 10:03 AM, John Baldwin wrote: > > > Agreed, and device.FOO would create an unknownX device (much like > > unprobed > > PNPBIOS or ACPI-enumerated devices) with a set of properties (if the > > bus impl > > uses properties to create devices and doesn't use them purely as > > additional > > metadata). For example, I actually figured that the default > > device.hints type > > stuff for COM1 would look like this: > > > > device.COM1.at="isa" > > device.COM1.port="0x3f8-0x3ff" > > device.COM1.irq=4 > > device.COM1.pnpid="PNP0500" > > BTW: I like the port range. I hate that abuot the current hints actually where drives hardcode things like IO_COMSIZE. I really would like the enumeration data that is provided not by the firmware to look like something that comes from firmware, on which we seem to agree. > > which is what you get with ACPI/PnPBIOS. On i386/amd64 users would > > probably > > wish to bind it using something like: > > > > device.COM1.driver="sio" > > device.COM1.unit=0 > > > > but it wouldn't be required. Note that it would be nice to just > > say 'device.COM1.unit=0' and not specify a driver at all, but that > > would not > > be easy to implement in new-bus. > > It can also cause conflicts. With uart and sio, you can > wire both to the same unit, based on the fact that sio > attaches to legacy devices by default and uart attaches > to puc by default. If you remove the sio driver, then you > end up with 2 wiring directives for the same unit that > now apply to the same driver. Explicitly specifying the > driver+unit makes it clear what is meant: if there are > multiple directives for the same driver+unit, then it's > obvious that the directives are conflicting and thus that > it's pilot error. Yeah. The problem is that in the case of the reversed com ports with ACPI that's all the users really want is the units to be right, they don't really care exactly which driver attaches. In some ways it would be nice if we could just give names to devices and use _UID for that or the node in the namespace (though the latter can fall down if you have an exceptionally lame namespace like my laptop's BIOS (see www.freebsd.org/~jhb/gpe/acpi.nc6220, all non-reserved names in the ACPI tree are Cxxx)) to generate user-visible device names like /dev entries, but I think that something like that might be too much upheaval. Also, I'm not sure it would scale well across different machines. For example, at work we really want the device that is labelled COM1, COMA, Serial A, whatever, to be the serial console and to have a getty running on it. Currently the easiest way for us is to bind sio0 to the resources for COM1 using hints and use /dev/ttyd0. _UID and namespace names are too unreliable for us to use those unfortunately. > Anyway, back to hints: your new approach is not disliked > by me. It fits my concept for the most part. However, in > order to support embedded hardware, we need to extend the > syntax (like using a range for the I/O port). Extending > the syntax may involve some significant work; even to the > extend that we can call it a rewrite, even if we keep > calling it hints. > > More examples: the e500 core can have up to 4 MACs. Each > MAC has 3 interrupts. We need to support this. Also, some > devices have multiple I/O resource ranges. This too needs > to be supported. If we can modify the current hints > slightly to support it than I'm happy. It's just that I > have not seen any consideration for it and could only > assume it would fall through the cracks. Regarding resources, I'd really like to be able to specify RIDs so you could do: device.FOO.irq.0="4" device.FOO.port.1="0xa-0xb" (RID 0 of SYS_RES_IRQ and RID 1 of SYS_RES_IOPORT) I also wonder if it would be nice to isolate I/O resources in their own property namespace. Something like: FOO { resources { irq { 0=4 } ioport { 1=0xa-0xb } } at="blah" } We could also call 'at', 'location' perhaps. > Also, A syntax like: > FOO { > sub1=a > sub2=b > } > > ... can be considered syntactic sugaring, because it > can mean exactly the same as: > FOO.sub1=a > FOO.sub2=b > > This too is exactly like hints. So, even a discussion > about syntax does not mean we need to toss out everything > we have and start from scratch. True. My worry here is making sure we can change it from the loader still. However, I also would still like to have a loader command for managing this in which case having it be in the kernel environment just like hints may be less important. That is, if "device FOO irq.0 4" will work, then we can replace /boot/device.hints with 'device' invocations and the backing-store for passing the data from the loader to the kernel is less important. > The bottomline: I'm not arguing that we cannot end up with > something that looks like hints. I'm arguing that if we > take hints *as they are* and apply your tweaks, that we don't > solve all the problems we're having or know we will have. > > More examples: I think we need to make hints conditional > so that they can be included in case they're needed, but > can be disabled/masked in case they're not (and more > specifically when they're wrong and fry your SoC). Since > hints as we have them today are unconditional, I can only > object to using hints because of the fact they are unconditional > and there's no intention to make them conditional. Well, they are somewhat conditional now (isa(4) at least respects the "disabled" hint). Are you looking for a single "turn all of them off" switch or a per-object disable? > Anyway: I don't mind if you decide to step away from this, > but I do think you're making a mistake in that case. If > anything, it's important that people keep arguing to make > sure that we find the right balance... Well, I'll chew some more. At least this time I don't have any code yet that I'm throwing away. -- John Baldwin From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 20:41:25 2008 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 F029516A417; Wed, 2 Jan 2008 20:41: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 91C2213C457; Wed, 2 Jan 2008 20:41:25 +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 m02Ke9gt072736; Wed, 2 Jan 2008 13:40:09 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 02 Jan 2008 13:40:33 -0700 (MST) Message-Id: <20080102.134033.-672663610.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200801021453.02931.jhb@freebsd.org> References: <200801021303.39518.jhb@freebsd.org> <0E7F7277-75F4-4A5A-924D-97C0C9D940CD@mac.com> <200801021453.02931.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: 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: Wed, 02 Jan 2008 20:41:26 -0000 In message: <200801021453.02931.jhb@freebsd.org> John Baldwin writes: : On Wednesday 02 January 2008 02:14:55 pm Marcel Moolenaar wrote: : > : > On Jan 2, 2008, at 10:03 AM, John Baldwin wrote: : > : > > Agreed, and device.FOO would create an unknownX device (much like : > > unprobed : > > PNPBIOS or ACPI-enumerated devices) with a set of properties (if the : > > bus impl : > > uses properties to create devices and doesn't use them purely as : > > additional : > > metadata). For example, I actually figured that the default : > > device.hints type : > > stuff for COM1 would look like this: : > > : > > device.COM1.at="isa" : > > device.COM1.port="0x3f8-0x3ff" : > > device.COM1.irq=4 : > > device.COM1.pnpid="PNP0500" : > : > BTW: I like the port range. : : I hate that abuot the current hints actually where drives hardcode things like : IO_COMSIZE. I really would like the enumeration data that is provided not by : the firmware to look like something that comes from firmware, on which we : seem to agree. We're all in agreement here then. I think the entire resource (not just range) should be accepted here. Eg: hint.fdc.0.port="0x3f2-0x3f3,0x3f4-0x3f5,0x3f7" or whatever your favored syntax is for the left hand side of the = sign. I'd prefer this over a portsz key. It is useful for many instances of this problem, not just the odd-ball floppy drive. Note: The above is a little more complicated than what a user would enter, but many BIOS tables are constructed that way. Also, I'd like to keep the 'You have this resource' command different than the 'Bind me to the device that has this resource' command. So : FOO { : resources { : irq { : 0=4 : } : ioport { : 1=0xa-0xb : } : } : at="blah" : } : We could also call 'at', 'location' perhaps. I think this still confuses things and is a cumbersome syntax. FOO { resources { irq(0)=4 } location { ioport=0xa-0xb _HID="COMA" } driver="sio" unit=2 } Would be much better. we could then have wildcard entries like so that are unnamed: { location { _HID="PNP0501" bus="acpi" } driver="uart" baud=115200 } { location { vendor=0x3451 device=0x0001 bus="pci" } driver="sio" baud=1200 } if one wanted to universally use uart for all serial ports. This also mirrors the pnpinfo that the ACPI bus provides and the PCI bus provides. It would easily allow one to look at the devinfo -v output and know how to bind a driver to a hunk of hardware (generically). It would also allow us to say: { location { bus="pci3" slot=31 function=1 // or at=pci3.31.1 // or at=pci0.3.31.1 including the pci domain } override { vendor=0x3451 device=0x0001 } } if we wanted to integrate into this system the strong desire that people have expressed for being able to say 'treat device X as if it were a Y'. Warner From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 20:52:12 2008 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 AE02D16A417 for ; Wed, 2 Jan 2008 20:52:12 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by mx1.freebsd.org (Postfix) with ESMTP id 2A50513C44B for ; Wed, 2 Jan 2008 20:52:12 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from localhost (unknown [127.0.0.1]) by mail.semihalf.com (Postfix) with ESMTP id BE72C15B1C; Wed, 2 Jan 2008 21:25:34 +0100 (CET) Received: from mail.semihalf.com ([127.0.0.1]) by localhost (mail.semihalf.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27580-08; Wed, 2 Jan 2008 21:25:33 +0100 (CET) Received: from [77.114.196.33] (apn-77-114-196-33.gprs.plus.pl [77.114.196.33]) by mail.semihalf.com (Postfix) with ESMTP id 5673F15B19; Wed, 2 Jan 2008 21:25:32 +0100 (CET) Message-ID: <477BF1FB.8080104@semihalf.com> Date: Wed, 02 Jan 2008 21:20:11 +0100 From: Rafal Jaworowski MIME-Version: 1.0 To: Marcel Moolenaar References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at semihalf.com 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: Wed, 02 Jan 2008 20:52:12 -0000 Marcel Moolenaar wrote: *snip* > > 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? > Hi Marcel, [Sorry to jump in that late, but I had a couple of days break completely away from computers] There was a lot of comments already, and since the discussion turned into more general than just the integrated peripherals bus, I'd only like to emphasize the hardware perspective of things that should be taken into account with the new/improved approach. Almost any embedded silicon can be broken into: 1.) Core, 2.) SoC built around the core, 3.) Platform (board, development system) built around the SoC. While the discussion so far went around units enumeration and instantiation, for me the most problematic to model in a generic way are attributes and settings in layer 3. Most often they are things that need to be known in advance for a particular system, and that are not always uniform, examples: - IRQ lines routing - multi-purpose pins (GPIO and alike) configuration (USB/IrDA/interrupt/whatever) - I2C devices addresses - phy-to-MAC mapping (in case of a multi port Ethernet), MAC addresses themselves - on-board logic (FPGA, CPLD) configuration Those are not attributes of SoC family, but are a custom setup and usually do not have an unique ID or so that would let us differentiate it from others based on the same chip. The information on the above is also not always available from firmware, so we need to deal with this in kernel. So my question is about where these would fit in and how do we manage those, so there's clear separation of configuration for a given system? Finally I have a minor note to not confuse entities :) e500 is a CPU core (that has a couple of versions on its own), so mostly what has been said in this thread regarding on-chip devices, resources, local busses, other properites etc. pertains to the SoC (MPC85xx), not the core. Rafal From owner-freebsd-embedded@FreeBSD.ORG Thu Jan 3 06:19:19 2008 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 A1AFE16A41B for ; Thu, 3 Jan 2008 06:19:19 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id 8C51413C43E for ; Thu, 3 Jan 2008 06:19:19 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp002-s [10.150.69.65]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id m0368q8t029150; Wed, 2 Jan 2008 22:08:52 -0800 (PST) Received: from [192.168.1.100] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/asmtp002/MantshX 4.0) with ESMTP id m0368oHF003809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Jan 2008 22:08:51 -0800 (PST) Message-Id: <838C48EA-C7C9-468C-8A3B-E51A1EE7D10E@mac.com> From: Marcel Moolenaar To: Rafal Jaworowski In-Reply-To: <477BF1FB.8080104@semihalf.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: Wed, 2 Jan 2008 22:08:50 -0800 References: <477BF1FB.8080104@semihalf.com> X-Mailer: Apple Mail (2.915) 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: Thu, 03 Jan 2008 06:19:19 -0000 On Jan 2, 2008, at 12:20 PM, Rafal Jaworowski wrote: > While the discussion so far went around units enumeration and > instantiation, > for me the most problematic to model in a generic way are attributes > and > settings in layer 3. Most often they are things that need to be > known in > advance for a particular system, and that are not always uniform, > examples: > > - IRQ lines routing > - multi-purpose pins (GPIO and alike) configuration (USB/IrDA/ > interrupt/whatever) > - I2C devices addresses > - phy-to-MAC mapping (in case of a multi port Ethernet), MAC > addresses themselves > - on-board logic (FPGA, CPLD) configuration > > Those are not attributes of SoC family, but are a custom setup and > usually do > not have an unique ID or so that would let us differentiate it from > others > based on the same chip. The information on the above is also not > always > available from firmware, so we need to deal with this in kernel. So my > question is about where these would fit in and how do we manage > those, so > there's clear separation of configuration for a given system? Most of it seems to fit best in the hardware layer and I expect that there's where we initially want to put it. Given the unstructured nature of the information, we may actually end up scattering it across the layers. > Finally I have a minor note to not confuse entities :) e500 is a CPU > core > (that has a couple of versions on its own), so mostly what has been > said in > this thread regarding on-chip devices, resources, local busses, other > properites etc. pertains to the SoC (MPC85xx), not the core. Oh, picky picky picky :-) Seriously: you're right of course. -- Marcel Moolenaar marcelm@juniper.net -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-embedded@FreeBSD.ORG Thu Jan 3 08:49:46 2008 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 E15C116A418 for ; Thu, 3 Jan 2008 08:49:46 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from mta01.xtra.co.nz (mta01.xtra.co.nz [210.54.141.254]) by mx1.freebsd.org (Postfix) with ESMTP id 8100213C474 for ; Thu, 3 Jan 2008 08:49:46 +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 <20080103084944.FWEJ6316.mta01.xtra.co.nz@fep03.xtra.co.nz> for ; Thu, 3 Jan 2008 21:49:44 +1300 Received: from serv.int.fubar.geek.nz ([219.89.107.40]) by fep03.xtra.co.nz with ESMTP id <20080103084944.VSSO18083.fep03.xtra.co.nz@serv.int.fubar.geek.nz> for ; Thu, 3 Jan 2008 21:49:44 +1300 Date: Thu, 3 Jan 2008 21:49:43 +1300 From: Andrew Turner To: freebsd-embedded@freebsd.org Message-ID: <20080103214943.09bb9c2e@hermies.int.fubar.geek.nz> In-Reply-To: <47754BF7.7000603@miralink.com> References: <20071228230341.1d78aa91@hermies.int.fubar.geek.nz> <20071228.090357.1649771318.imp@bsdimp.com> <18293.14511.208655.904627@gromit.timing.com> <47754BF7.7000603@miralink.com> 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 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: Thu, 03 Jan 2008 08:49:47 -0000 On Fri, 28 Dec 2007 11:18:15 -0800 Sean Bruno wrote: > John E Hein wrote: > > 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. > > > It looks to me like the attachment was stripped. Can you post it > somewhere web accessible? > I've placed a copy at http://fubar.geek.nz/files/freebsd/freebsd-nandgeom-jb.tar.bz2 Andrew -- Andrew Turner http://fubar.geek.nz/blog/