On 07:40 Sun 28 Jun , Dirk Behme wrote: > Dear Jean-Christophe, > > Jean-Christophe PLAGNIOL-VILLARD wrote: > >On 19:12 Thu 25 Jun , Jason Kridner wrote: > >> On Thu, Jun 25, 2009 at 4:59 PM, Jean-Christophe PLAGNIOL-VILLARD > >> <plagn...@jcrosoft.com> wrote: > >> > >> On 14:57 Mon 08 Jun , Grazvydas Ignotas wrote: > >> > The update consists of following changes: > >> > - remove configuration of not connected pins, effectively > >> > leaving them in safe mode. > >> > - remove unused GPIOs, setup newly added ones. > >> > - setup pulls for various GPIOs. Disable pulls for game > >> > buttons, as they have external pulls. > >> > - SDRC CS change based on recent patch for > >> > Beagle and Overo. > >> > > >> > Old boards are no longer supported, but there was only > >> > small number of test boards made. Updated configuration > >> > is expected to be used for mass production. > >> If user have old version in possession NACK > >> > >> I believe no users who would possibly object have the old version (or any > >> version) in possession. Only the core developers ever got > >>these boards. Is the expectation to create #ifdef or some > >>sort of auto-detection > >> (unlikely possible)? > >untill the hardware will be really not anymore use yes please > > If two or three people (from the board manufacturer?) which are more > familiar with the development board situation than you say "we don't > need it" then this should be accepted. If nobody uses the older > boards any more (and this is what I understood they said: "There > were only few older boards, we know where they are and they are > replaced by new ones") then there is absolutely no reason to pollute > U-Boot with support for it. There is no need to add dead code to > U-Boot. No, it's different no people have a board and some people have a board > > We should trust the board maintainers somehow. It's not me who tell that some people have the board
when you will be in possession of the old version of a board and just because few people have the board is remove from the mainline you will not be happy. So no we will support the both > > >> this kind of huge update is non bisectable so we do need to use a true > >> mux api > >> as the kernel lot's of other arch in u-boot > >> > >> Why is it not bisectable? > >because your mix cleanup, fixup and new board support > >> Do you have a "true mux api" to suggest? > >the same as the kernel one is the best for code sharing > > OMAP3 pin mux in kernel is totally broken. do you really think it's a good reason to have copy & paster everywhere and not a simple api as at91, davinic and others? I do not Best Regards, J. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot