Date: Fri, 28 Dec 2007 15:08:28 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: marcelm@juniper.net Cc: embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <20071228.150828.-861033669.imp@bsdimp.com> In-Reply-To: <7C4C5641-EA0E-4BEA-8EEC-EEB69CDEE071@juniper.net> References: <20071228.130329.43010549.imp@bsdimp.com> <dcfb161c0712281231y4d726502v42959fa7217d7376@mail.gmail.com> <7C4C5641-EA0E-4BEA-8EEC-EEB69CDEE071@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <7C4C5641-EA0E-4BEA-8EEC-EEB69CDEE071@juniper.net>
Marcel Moolenaar <marcelm@juniper.net> writes:
:
: On Dec 28, 2007, at 12:31 PM, Olivier Gautherot wrote:
:
: >> : It violates newbus in that drivers compete for a device.
: >> : If the bus assigns the driver, then there's no competition
: >> : possible. The fact that the bus is abstract should not
: >> : mean that we should change its paradigm.
: >>
: >> No it doesn't. There's two kinds of busses in newbus. Those that
: >> self enumerate based on the hardware present (ie pccard, pci, usb,
: >> firewire) and then those that are told what's there (oldcard-style
: >> pccard, pure ISA, I2C, etc). The busses on the SoC more strongly
: >> resemble the latter than the former. The former busses already are
: >> enumerated with hints, but the actual mechanism is just a few calls
: >> that could be replaced with something better.
: >
: > 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.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071228.150828.-861033669.imp>