[U-Boot] [Question] Any plan to refactor Generic Board Framework?

Hi.
The generic board code looks really dirty to me: common/board_f.c is sprinkled with ARCH/CPU/BOARD configs
For example,
#if defined(CONFIG_405GP) || defined(CONFIG_405EP) || \ defined(CONFIG_440EP) || defined(CONFIG_440GR) || \ defined(CONFIG_440EPX) || defined(CONFIG_440GRX) bd->bi_pci_busfreq = get_PCI_freq(); bd->bi_opbfreq = get_OPB_freq(); #elif defined(CONFIG_XILINX_405) bd->bi_pci_busfreq = get_PCI_freq(); #endif
or
#if defined(CONFIG_8xx) || defined(CONFIG_MPC8260) || defined(CONFIG_5xx) || \ defined(CONFIG_E500) || defined(CONFIG_MPC86xx) bd->bi_immr_base = CONFIG_SYS_IMMR; /* base of IMMR register */ #endif #if defined(CONFIG_MPC5xxx) bd->bi_mbar_base = CONFIG_SYS_MBAR; /* base of internal registers */ #endif #if defined(CONFIG_MPC83xx) bd->bi_immrbar = CONFIG_SYS_IMMR; #endif
Is there any plan to fix them? When? By whom?
(They include some old platform macros such as CONFIG_8xx. Is it worth refactoring? If so, who will do it? )
Besides, there are many 'TODO' marks. But it seems nothing has happened so far...
Now generic board is suppored in ARM, PPC, MIPS, Sandbox, ARC, x86.
Accoding to doc/README.generic-board, we are expecting the other architectures will support it before October. I think we should start to do something now.
If we keep going without any clean-up, I guess it will be messed up.
Best Regards Masahiro Yamada

Hi Masahiro,
On 7 July 2014 20:37, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hi.
The generic board code looks really dirty to me: common/board_f.c is sprinkled with ARCH/CPU/BOARD configs
For example,
#if defined(CONFIG_405GP) || defined(CONFIG_405EP) || \ defined(CONFIG_440EP) || defined(CONFIG_440GR) || \ defined(CONFIG_440EPX) || defined(CONFIG_440GRX) bd->bi_pci_busfreq = get_PCI_freq(); bd->bi_opbfreq = get_OPB_freq(); #elif defined(CONFIG_XILINX_405) bd->bi_pci_busfreq = get_PCI_freq(); #endif
or
#if defined(CONFIG_8xx) || defined(CONFIG_MPC8260) || defined(CONFIG_5xx) || \ defined(CONFIG_E500) || defined(CONFIG_MPC86xx) bd->bi_immr_base = CONFIG_SYS_IMMR; /* base of IMMR register */ #endif #if defined(CONFIG_MPC5xxx) bd->bi_mbar_base = CONFIG_SYS_MBAR; /* base of internal registers */ #endif #if defined(CONFIG_MPC83xx) bd->bi_immrbar = CONFIG_SYS_IMMR; #endif
Is there any plan to fix them? When? By whom?
(They include some old platform macros such as CONFIG_8xx. Is it worth refactoring? If so, who will do it? )
Besides, there are many 'TODO' marks. But it seems nothing has happened so far...
Now generic board is suppored in ARM, PPC, MIPS, Sandbox, ARC, x86.
Accoding to doc/README.generic-board, we are expecting the other architectures will support it before October. I think we should start to do something now.
If we keep going without any clean-up, I guess it will be messed up.
The code is trying to duplicate the old board init without changing/breaking anything. So the #ifdefs are trying to duplicate those in the old board init code. I didn't want to create lots of test problems/breakages, although even with this approach I am aware of at least one problem.
The TODOs are mostly things that I hope board authors will look at when they convert over their boards.
The goal was to get all of the archs using the same code, even if it is just as full of #ifdefs as the old arch/xxx/lib/board.c code. The benefit is that we can add new features without doing it in 10 places.
The plan is that board init will mostly go away and be replaced by driver model init. What is left in board_f and board_r will be U-Boot generic things like relocation.
This is quite a long-term plan, since driver model conversion is going to take a while.
Regards, Simon

Hi Simon,
On Mon, 7 Jul 2014 20:51:00 +1000 Simon Glass sjg@chromium.org wrote:
Is there any plan to fix them? When? By whom?
(They include some old platform macros such as CONFIG_8xx. Is it worth refactoring? If so, who will do it? )
Besides, there are many 'TODO' marks. But it seems nothing has happened so far...
Now generic board is suppored in ARM, PPC, MIPS, Sandbox, ARC, x86.
Accoding to doc/README.generic-board, we are expecting the other architectures will support it before October. I think we should start to do something now.
If we keep going without any clean-up, I guess it will be messed up.
The code is trying to duplicate the old board init without changing/breaking anything. So the #ifdefs are trying to duplicate those in the old board init code.
Thanks. I was missing this. This verbatim dupulication makes it easy to switch to generic board, in most cases, just by adding CONFIG_SYS_GENERIC_BOARD although run-test is strongly recommended.
Then, we can clean-up code after removing arch/*/lib/board.c (Maybe next year?)
Best Regards Masahiro Yamada
participants (2)
-
Masahiro Yamada
-
Simon Glass