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