Date: Thu, 04 Dec 2008 23:28:13 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: antab@valka.is Cc: embedded@freebsd.org Subject: Re: Looking to formalize board support in embedded platforms. Message-ID: <20081204.232813.-1592326736.imp@bsdimp.com> In-Reply-To: <987F43D1-F7F8-4276-99BA-81F45D1F4BB0@valka.is> References: <20081204.153726.-1548257878.imp@bsdimp.com> <987F43D1-F7F8-4276-99BA-81F45D1F4BB0@valka.is>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <987F43D1-F7F8-4276-99BA-81F45D1F4BB0@valka.is>
Arnar Mar Sig <antab@valka.is> writes:
: On Dec 4, 2008, at 11:37 PM, M. Warner Losh wrote:
: > I've spent a little bit of time implementing the start of board files
: > for the arm port. The initial push has been for the at91 subport only,
: > and many improvements could be made to this. I've written up my
: > initial thoughts on this on the FreeBSD wiki
: > http://wiki.freebsd.org/FreeBSDArmBoards/. It could use much
: > improvement, I'm sure.
: Some comments:
: What is the point of a std.* file for every board, cant this be in the
: config file? I can understand the reason for having std.at91 and
: std.xscale that board configs can include to set cpu dependent
: options. But imo it would be cleaner to skip the std.* files for the
: boards.
The thinking here is that each of the board defines a certain set of
things that are standard for all users of that board, and that the
kernel config just stitches together the non-board specific parts for
the kernel. Each of these boards may have slightly different load
addresses, and the like, and putting that in the kernels for the board
is very repetitive and error prone.
It is a hierarchy: boards define the most specific thing, and then
include the next more general thing (usually the SoC definitions),
which in turn includes the next more general thing (say, the family
of devices) and so on until we get to the std.arm file which is what's
standard for all arm boards.
In any event, that's why it is there. I'll keep track of your
comments. It may mean that how we're doing things is wrong, and your
reaction to the solution to the wrongness informs us that something
else is wrong... I'm not sure yet...
: "There's some suggestions that there be a separate "boards" directory.
: I'm not sure that I like it."
: Depends on have many board we have, with 2 board it doesn't matter
: much, but with 10+ board all with a separate std.*, *.c and maybe
: files.* then its probably best to add the "boards" directory.
I'll keep that in mind. You may be right...
: > One idea that hasn't been reflected there yet, was shown to me by Sam
: > Laffler who suggested using linker sets to allow boards to 'probe',
: > 'init' and other standardized functions. This is an interesting idea
: > and I plan on working on adding it to the above links when Sam has
: > results to share.
: Sounds interesting
I'm very interested to see how his experiments work out.
: > I'd also like to expand the above wiki page to be a 'best practices'
: > guide for all architectures where there's great diversity of
: > boards/cpus/etc (eg, not the homogeneous env that x86 provides).
: Good thing.
I hope so...
: > I'm also soliciting comments on the above boards in addition to the
: > above. Send them to me, or post them here.
: > _______________________________________________
: > freebsd-embedded@freebsd.org mailing list
: > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded
: > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org
: > "
:
:
: Another thing semi related to board settings, device clocks.
: I see that in some of the device drivers for at91 the peripheral input
: clock is hard coded. This is probably fine for cpu's with one clock
: zone (don't know if at91 has one or many), but for cpu's like avr32
: where you have many clock zones and peripherals can be connected to
: any one of them then hard coding this will not work.
The AT91 has several clock zones. We're trying to move away from
having these clocks hard coded. It works for the moment, but doesn't
scale well. We also need a generic hierarchical clock framework as
well, since differing clock domains are a common feature of embedded
processors.
: I think we need a clock framework (extension to the device driver
: framework?) to be able to lookup the peripherals input clock so the
: driver can calculates its prescalers right. This would also allow use
: to dynamically change the frequency for zones to get better power
: efficiency.
Absolutely! On the AT91 there's also a number of different ways to
drive the core CPU frequency that help save energy, at the cost of a
slight increase in latency to the memory chips. Some folks want less
energy use, others want faster RAM access to improve their execution
times (some folks are greedy and want both). Having the ability to
control the clock domains would help this out a lot.
This is an area that's rich for research, I think. People have done
some interesting things here in Linux, and I think we can learn from
their successes and failures.
Thanks again for all your comments! I appreciate them.
Warner
: Greets
: Arnar Mar Sig
: Valka ehf
:
:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081204.232813.-1592326736.imp>