Looking to formalize board support in embedded platforms.

[Arnar Mar Sig]

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.

"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.

>
> 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'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'm also soliciting comments on the above boards in addition to the
> above. Send them to me, or post them here.
> _______________________________________________
> freebsd-embedded at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-embedded
> To unsubscribe, send any mail to "freebsd-embedded-unsubscribe at 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.

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.

Greets
	Arnar Mar Sig
	Valka ehf