Code review request: boards on AT91

[M. Warner Losh]

In message: <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC at semihalf.com>
            Rafał_Jaworowski <raj at semihalf.com> writes:
: On 2008-11-25, at 18:44, M. Warner Losh wrote:
: 
: > I'm trying a little experiment.  I'm moving the board support for the
: > different sets of boards we support to their own file.  This is the
: > first step in moving to supporting multiple boards more easily.
: > There's a number of gross hacks to make this work now in at91 land,
: > and I'd like to clean them up.  The mv port is much cleaner, but we
: > still likely need some way to identify boards and get the right board
: > support code called.  In Linux land, all ARM boot loaders are expected
: > to pass in a machine type, which is used to do the multiplexing.
: > Something similar in FreeBSD would be useful (and not just for ARM).
: 
: Hi Warner,
: While I understand your point about systems with simplistic  
: bootloaders, which cannot provide enough config data to kernel, we  
: should not see the machine ID model as a final solution for more  
: capable environments. I guess we all agree that for those more capable  
: systems we need some really extensible mechanism (device tree type),  
: as discussed previously :-)

Yes.  Agreed.  My point was more to make sure that we didn't require
the loader to provide freebsd-specific kenv.

: > If anybody wants me to write up where I'm going with this, or answer
: > any question, please feel free to ask.  Also, comments would be nice.
: 
: I was dreaming once about all-generic initarm() that would have KOBJ- 
: based dispatcher, but am not sure this wouldn't cause some chicken-and- 
: egg issues as some parts of the infrastructure might not be available  
: at such early stages, but didn't investigate this too close, any  
: thoughts? But anyways, even a simple scheme with common logic and  
: function ptrs, which each platform variation would implement their own  
: routines (or use generic), would improve the ARM init code  
: significantly.

Yes.  There's much duplication of code now, and I'd love to work
towards ways of coping with less duplication.  I'd also like to see
the ability to compile code either for multi-board support, or just a
single board support.  For the moment, I'd like to take the first step
and get to have the latter...

The Marvell/Orion stuff has a much better separation, but still needs
some tweaks for board level support.  I think I'm going to write up
what I've done and put it on a wiki and then ask if you could review
it and see if your experience with the Marvell implementation could
help refine it.

Warner