[PATCH 10/11] Add MPC8360EMDS board support
Jerry Van Baren
gerald.vanbaren at smiths-aerospace.com
Thu Oct 5 02:05:21 EST 2006
Dan Malek wrote:
> On Oct 4, 2006, at 1:52 AM, Benjamin Herrenschmidt wrote:
>> I don't see how a mecanism of feature call at the board support
>> level is
>> in any way incompatible with the device-tree thing.
> It isn't.
>> ... I'm happy mixing
>> both on powermac :)
> I know. This was just an opportunity to make people
> realize that a board port does require the writing of
> some board specific code. Using the feature call is
> an excellent model of portability and flexibility. My
> point was that any BCSR access is necessary to be
> hidden behind such a function, because it is truly
> board specific. You can't require the drivers to
> have this kind of logic in them, they must call out
> to board support functions for assistance.
> Just like the powermac ports, embedded drivers
> will need a feature call at some points during
> their processing (set up clock routing, IO pin
> configuration, board specific bus connections,
> power management, etc). Some board ports
> may do nothing, others may do lots of work.
> Therefore, I see no reason why a BSCR address
> and all of it's associated format can't simply
> be a #define in a board specific file. There is no
> need for this in the device tree.
> -- Dan
The promise of OF for me is that it promises to keep configuration
information in _one place_. My experience to date is that my u-boot has
a bunch of semi-hardcoded constants, my linux drivers have a bunch of
semi-hardcoded constants that likely do not match 1:1 (name and
definitely not location) with the equivalent u-boot constants, and some
constants are passed from u-boot to linux using the BD structure, which
is never defined the same (for me) in u-boot and linux.
The result is that, when I upgrade my u-boot and/or linux sources, I end
up having to re-find all the places where the constants live (and find
some new places), fix them, and then make the u-boot and linux BD
structures match. Granted, this isn't insurmountable, but it is a major
hassle and should be unnecessary.
In a perfect world perhaps we would have one (set of) #include file(s)
that had all the configuration information necessary to build u-boot and
linux. In the current world, u-boot and linux are in different
repositories with different people with different machines (and agendas)
doing different development on them, and the result is disjoint.
I look at OF to be the /lingua franca/ of PowerPC bootloaders and linux.
More information about the Linuxppc-dev