Re: [U-Boot] A bit about board.c, board.c
Hi Simon,
On 23/10/11 03:36, Simon Glass wrote:
Hi Graeme,
Did you mean to send to list?
Oops, yes I did - Done now
On Fri, Oct 21, 2011 at 10:49 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon
On Oct 22, 2011 4:11 PM, "Simon Glass" sjg@chromium.org wrote:
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.
Yes, it is a mess - something my unit sequence patches tried to clean up
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
100% agree
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 vote to pick an arch, convert it to a unified style and move it to lib/board.c and then merge each arch over. This should be done in a single series rather than the ol' 'migrate over time' which never happens.
I thing you mean merge each arch over in its own series?
x86 is a good arch to start with because the number of boards is so small (1)
Also, I'd personally like the init sequence patches I posted earlier to be re-examined
I already examined and thought it was good. Let's be careful to keep it simple in the sense that we only need a very small number of init functions. Most of the board_init_r() code should not be there as I understand it (e.g. on ARM MMC, USB, NAND should be inited if/when used and not before). Need to be careful not to confuse this bit with driver init or any refactor of the driver model. So we have things like
- init memory and make it so we can relocate code, etc. (this is
called from start.S at present)
- init the CPU core
- arch init like turn off caches, MMU, flush TLBs, etc.
- early board init (hopefully just requires an initcall in board code if needed)
- the current init sequence like banner, serial, etc.
- relocate
- console init
- board_init (initcall in board code if needed)
- (hopefully all other post-relocation init can be punted)
So board.c becomes a few functions and about a dozen initcalls. Albert will want to use weak symbols instead of #ifdef, and we will be done.
Regards, Simon
Regards,
Graeme
Hi Simon,
On 23/10/11 08:41, Graeme Russ wrote:
Hi Simon,
On 23/10/11 03:36, Simon Glass wrote:
Hi Graeme,
[snip]
I vote to pick an arch, convert it to a unified style and move it to lib/board.c and then merge each arch over. This should be done in a single series rather than the ol' 'migrate over time' which never happens.
I thing you mean merge each arch over in its own series?
I mean merge all arches in one series
x86 is a good arch to start with because the number of boards is so small (1)
Also, I'd personally like the init sequence patches I posted earlier to be re-examined
I already examined and thought it was good. Let's be careful to keep it simple in the sense that we only need a very small number of init functions. Most of the board_init_r() code should not be there as I understand it (e.g. on ARM MMC, USB, NAND should be inited if/when used and not before). Need to be careful not to confuse this bit with driver init or any refactor of the driver model. So we have things like
My biggest gripe with the init code is the lack of consistency. There are two prime examples of this:
1) The pre-relocation sequence and post-relocation sequences can be implemented using identical code (a sequence loop) - x86 almost gets there, other arches only loop for one, and have sequential logic for the other 2) Even with the init loop, there is a lot of sequential code after the loop that could be merged into the loop
- init memory and make it so we can relocate code, etc. (this is
called from start.S at present)
- init the CPU core
- arch init like turn off caches, MMU, flush TLBs, etc.
- early board init (hopefully just requires an initcall in board code if needed)
- the current init sequence like banner, serial, etc.
- relocate
- console init
- board_init (initcall in board code if needed)
- (hopefully all other post-relocation init can be punted)
So board.c becomes a few functions and about a dozen initcalls. Albert will want to use weak symbols instead of #ifdef, and we will be done.
The INIT_CALL approach eliminated this need - If the .c file does not get compiled in, the INIT_CALL does not get included. And adding a new INIT_CALL was as simple as including the macro in the .c file without needing to mess with board.c at all - simple :)
INIT_CALL is a completely separate issue to what you are looking at and would be easier to implement after board.c was merged into lib
Regard,
Graeme
participants (1)
-
Graeme Russ