Dear Reinhard Meyer, Am 31.10.2010 um 16:24 schrieb Reinhard Meyer:
> Dear Wolfgang Denk, Andreas Bießmann, >> -at91rm9200ek arm arm920t - atmel >> at91 >> +at91rm9200ek arm arm920t at91rm9200ek atmel >> at91 at91rm9200ek >> +at91rm9200ek_ram arm arm920t at91rm9200ek atmel >> at91 at91rm9200ek:RAMBOOT > > Just two technical questions: > > 1. Who is taking this patch in? cause this is atmel/at91 related it should go through u-boot-atmel. The patches are on top of atmel/at91: '816dd1b AT91: add header file for the Shutdown Controller'. > 2. Should we, since Atmel is not likely maintaining the boards, > change relevant maintainers entries (if the person fixing > that Atmel board agrees)? docs/README.arm-relocation says: "Boards which are not fixed to support relocation will be REMOVED!" If one can fix some remaining atmel (or arm in general) boards they should become the new maintainer. 3. How should we treat at91rm9200 boards which are not transformed to at91. I plan to get the at91rm9200 device drivers (at91rm9200_usart, emac) merged with at91 implementation. When we do this transition (will last til end of this year at least; not before 2011.03/maybe 2011.06) we could completely delete the deprecated drivers. Thus we break at91rm9200 boards completely (which may not working at all due to new arm relocation stuff ... but who knows/test this/is responsible for?). Should we write down/propagate a time schedule for this transition as it is done for arm relocation? Should we drop those possible not working boards in general? Jens, you began with at91rm9200 to at91 transition as far as I know. How do you think about it? In README.at91rm9200 there is a little definition how to do the transition from at91rm9200 to at91 but no time schedule or dead line. regards Andreas Bießmann _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
