Hi Albert, On Sat, Oct 22, 2011 at 12:17 AM, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: > Le 22/10/2011 07:11, Simon Glass a écrit : >> >> Hi, >> >> Each architecture has its own board.c but they are mostly quite similar. >> >> New features such as fdt, boot timing, trace, profiling, etc. must be >> done separately for each arch, even if there are no >> architecture-specific bits. >> >> What would you say to adding something like lib/board.c which is a >> simplified cleaned-up copy of one of the existing board.c files, and a >> CONFIG_ARCH_GENERIC_BOARD option to select that in preference to the >> architecture-specific one. Then perhaps people could try it out and we >> could slowly move to it over time... > > I'd say anything that factorizes ARM code is a good thing. :) > > However I'm not in favor of a CONFIG option that would force the board code > to provide some functions just in odrer to override one, not if weak
My suggestion was: CONFIG_ARCH_GENERIC_BOARD - you get lib/board.c not CONFIG_ARCH_GENERIC_BOARD - you get arch/xxx/lib/board.c > definitions can do a finer job. I am looking into that already for cache > management function specialization, and it seems like there is the same kind > of possibility here, with lib functions defined weak and the board code > overriding the ones it deems necessary to. ok. Just one little point. Weak symbols are the punishment our C++ overlords gave us for not having to understand what code is executed when we instantiate a C++ subclass. It is nice to know what code is being linked in and avoid having to disassemble to find out. I think using weak symbols to avoid a OBJS-$(CONFIG_ARCH_GENERIC_BOARD) in a couple of Makefiles risks going too far. Regards, Simon Regards, Simon Regards, Simon > > I will look into it a bit more this morning. > > Amicalement, > -- > Albert. > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
