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