[U-Boot-Users] [PATCH 3/4] AVR32: Add support for the ATSTK1003 board

[Kim Phillips]

On Tue, 30 Oct 2007 14:40:08 +0100
Haavard Skinnemoen <hskinnemoen at atmel.com> wrote:

> On Tue, 30 Oct 2007 13:44:27 +0100
> Stefan Roese <sr at denx.de> wrote:
> 
> > On Tuesday 30 October 2007, Haavard Skinnemoen wrote:
> > > > Please don't forget to add the new boards to MAKEALL and MAINTAINERS.
> > >
> > > Ah, right. Thanks for spotting that. I guess I should add them to README
> > > as well.
> > 
> > Not sure. Do we have a list of all official supported boards in the README 
> > too? The README is too big already from my point of view.
> 
> I'm referring to this section:
> 
> - CPU Daughterboard Type: (if CONFIG_ATSTK1000 is defined)
>                 Define exactly one of
>                 CONFIG_ATSTK1002
> 
> I suppose we could remove it though. The new Kconfig stuff will make it
> obsolete anyway, right?

yes.  For some reason, that one missed the axe (see commit
2628114ec564f969f34b5f7105fbd168cb8c9c3f).  Perhaps it should be
changed to an "e.g." instead, to leave the reader aware of
Daughterboard types.

> > > MAINTAINERS currently only mentions ATSTK1000, which is the motherboard
> > > for ATSTK100[234]. Should I add entries for all the daughterboards or
> > > should I simply update it to say AT32AP700x in the CPU column instead
> > > of AT32AP7000?
> > 
> > MAKEALL definitely has to have all boards listed. MAINTAINERS probably too, 
> > since it makes it easier to locate the board via a grep.
> 
> Sure, but MAKEALL needs to list all _configurations_ that are available
> (i.e. the stuff under include/configs.) If you're trying to locate the
> board, you'll find all three daughterboards living under
> boards/atmel/atstk1000, so grepping for ATSTK1000 is the natural thing
> to do, isn't it?

technically MAKEALL uses the main Makefile targets.

> I guess the safest way is to include all of them, in addition to
> ATSTK1000. I'll do that as an additional patch since I need to add
> ATSTK1002 as well.

yes, this'll give you the fullest testing coverage.

> Håvard

Kim