Date: Fri, 5 Dec 2008 07:07:55 +0100 From: Arnar Mar Sig <antab@valka.is> To: "M. Warner Losh" <imp@bsdimp.com> Cc: embedded@freebsd.org Subject: Re: Looking to formalize board support in embedded platforms. Message-ID: <987F43D1-F7F8-4276-99BA-81F45D1F4BB0@valka.is> In-Reply-To: <20081204.153726.-1548257878.imp@bsdimp.com> References: <20081204.153726.-1548257878.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?987F43D1-F7F8-4276-99BA-81F45D1F4BB0>