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

Simon Glass sjg at chromium.org
Mon Jul 7 12:51:00 CEST 2014


Hi Masahiro,

On 7 July 2014 20:37, Masahiro Yamada <yamada.m at 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


More information about the U-Boot mailing list