Date: Wed, 02 Jan 2008 21:20:11 +0100 From: Rafal Jaworowski <raj@semihalf.com> To: Marcel Moolenaar <marcelm@juniper.net> Cc: embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <477BF1FB.8080104@semihalf.com> In-Reply-To: <B56F8F3C-7872-47B9-8154-1C08F5BEEA3D@juniper.net> References: <B56F8F3C-7872-47B9-8154-1C08F5BEEA3D@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?477BF1FB.8080104>