Date: Tue, 25 Nov 2008 14:19:57 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: raj@semihalf.com Cc: arm@FreeBSD.org Subject: Re: Code review request: boards on AT91 Message-ID: <20081125.141957.1723235268.imp@bsdimp.com> In-Reply-To: <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC@semihalf.com> References: <20081125.104452.535842403.imp@bsdimp.com> <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC@semihalf.com>
Rafa=B3_Jaworowski <raj@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 t=
he
: > 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 boa=
rd
: > support code called. In Linux land, all ARM boot loaders are expec=
ted
: > 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 capabl=
e =
: 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 answe=
r
: > any question, please feel free to ask. Also, comments would be nic=
e.
: =
: I was dreaming once about all-generic initarm() that would have KOBJ-=
=
: based dispatcher, but am not sure this wouldn't cause some chicken-an=
d- =
: 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 ow=
n =
: 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081125.141957.1723235268.imp>