On Fri, Aug 16, 2013 at 01:28:26PM -0600, Simon Glass wrote:
Hi David,
On Thu, Aug 15, 2013 at 11:02 PM, FengHua fenghua@phytium.com.cn wrote:
hi Simon, I have worked on generic board for a few days, but something confuse me. Why it is needed? Each processor architecture has different features, this will affect processor specific and board specific code. Putting board_init_* code of each platform into one file with many macro switch make things messy, the board_f.c and board_r.c become very complicated and less readable. Is it really needed? We should make it clear that what parts are common between architecture and what parts are specific. Actually, I have different opinion with this. Architecture specific board.c file have more advantages. how ahout your opinion?
Scott's reply jogged my memory to reply to this.
I suspect having a board.c for each arch was a good idea at the start, and it was hard to reconcile the different ordering and init needs of each arch as it was added. It was much each when porting to a new arch to just copy one of the existing archs and modify the code until it works.
Unfortunately, this means we have about 10 different versions of what turns out to be mostly the same code. The generic board effort was an attempt to unify these into one. While I agree there are lots of #idefs I think that is a separate problem, and at least the code is now all in one file. As a first step it would be nice to sort through and weed out the arch-specific #idefs in common/board_{f,r}.c.
Related to this is global_data and the board data in bd_t. These structures have been unified and again found to contain a lot of common elements across archs.
As a specific example of where having generic board init helps, it is now possible to add a new feature to all archs without changing 10 different files. For example the trace feature was added that way. Decide tree support (CONFIG_OF_CONTROL) can in principle be turned on for any arch by porting it to generic board.
So far ARM and PowerPC support generic board, and x86 and sandbox use it exclusively (i.e. their old board.c code is removed).
As it turns out, this board.c file is not really very arch-specific, as Scott says. It should not be a huge job to make aarch64 use it instead of its own board.c although I am sure there will be a few curly problems.
We have not talked about this on the list, and it is far to early yet, but at some point it would be nice to deprecate the old board.c files.
And this would be another reason to place this in arch/arm to start with, rather than split-arch, leveraging this otherwise generic stuff should just be a matter of setting the define, and one less thing for you to worry about having to cover. It's on my plate to confirm that for example, the trivial convert and boot test I did on am335x was enough.