From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 22:43:12 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0801416A469 for ; Fri, 28 Dec 2007 22:43:12 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by mx1.freebsd.org (Postfix) with ESMTP id DB79313C4E7 for ; Fri, 28 Dec 2007 22:43:11 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 14:43:00 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Dec 2007 14:42:48 -0800 Received: from mini-g4.jnpr.net (aparmelee-t41.jnpr.net [172.24.104.164] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSMgw900914; Fri, 28 Dec 2007 14:42:58 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: <9355ADCA-B61C-4515-AEA4-CFA96A12AF0B@juniper.net> From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.150828.-861033669.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 14:42:58 -0800 References: <20071228.130329.43010549.imp@bsdimp.com> <7C4C5641-EA0E-4BEA-8EEC-EEB69CDEE071@juniper.net> <20071228.150828.-861033669.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 22:42:48.0596 (UTC) FILETIME=[F8B15540:01C849A2] Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 22:43:12 -0000 On Dec 28, 2007, at 2:08 PM, M. Warner Losh wrote: > : > Excuse my ignorance about obio, ocpbus and the like... > : > If we envisage to use a PCI-like approach to initialise the on- > chip > : > drivers, couldn't we generate a table on a per CPUID basis? > : > : That's only part the story. There are embedded devices that > : aren't SoC. You can't use the CPU ID to figure out what's > : there in that case. You typically need to use board IDs, or > : SKUs for that. But other than that, yes. A description of > : the hardware is, when not fixed, keyed off of some easy to > : obtain ID or characteristic... > > Very true. The CPU ID is a degenerate case. In Linux, at least for > arm, all boards are assigned a unique ID by the arm team and the boot > loader passes this id to the kernel that then uses it to figure out > which board init to call, which knows what devices are on that board. > In the case of multiplexed pins, it also knows which pins are > connected (usb or ethernet or GPIO), and which pins aren't and need to > be turned off (or pulled high, etc). FreeBSD's arm port needs to make > better use of information like this... > > I'm not sure how these sorts of things are done in the PowerPC world. At this time the only example is e500 and my experience here at Juniper. The on-chip peripherals can be enumerated based on the CPU ID, but whatever is underneath the local bus or attached to the i2c controllers (whether with our without multiplexers) is entirely board specific. Our tables even contain PCI resource assignments and interrupt routing for PCI devices. This because there's no firmware that assigns resources to PCI devices. We need to do that in the kernel itself... In other words: PowerPC is not SoC, but can be. There is more than one bus that needs to be enumerated and each of these may need a different set of tables, independently of the others. Tables may need to describe PCI busses as well so that the kernel knows how to set up the I/O windows and to program the hardware so that memory accesses are forwarded to the right device (DRAM, PCI or local bus). -- Marcel Moolenaar marcelm@juniper.net