Date: Fri, 28 Dec 2007 14:42:58 -0800 From: Marcel Moolenaar <marcelm@juniper.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <9355ADCA-B61C-4515-AEA4-CFA96A12AF0B@juniper.net> In-Reply-To: <20071228.150828.-861033669.imp@bsdimp.com> References: <20071228.130329.43010549.imp@bsdimp.com> <dcfb161c0712281231y4d726502v42959fa7217d7376@mail.gmail.com> <7C4C5641-EA0E-4BEA-8EEC-EEB69CDEE071@juniper.net> <20071228.150828.-861033669.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9355ADCA-B61C-4515-AEA4-CFA96A12AF0B>