[RFC] arm naming inconsistance

[RFC] arm naming inconsistance

[Antony Pavlov]

Hi!

Barebox has an hierarchy for supported stuff:

 arch -> mach

    arch \in {arm, x86, nios2 ...}

 for arch=arm, mach \in { at91, ims, msx, ... versatile }

 Also there is the 'board', the lowest level of hierarchy.

 E.g. for mach=at91, board \in { at91sam9m10g45ek, pm9263 ...}

But there are strange things in arch/arm/Kconfig and
arch/arm/cpu/start.c:

#ifdef CONFIG_ARCH_HAS_LOWLEVEL_INIT
        arch_init_lowlevel();
#endif

At the first glance all ok: if arch has lowlevel init, the do
arch_init_lowlevel().
But arch_init_lowlevel() is not __per-arch__ function, but
__per-mach__ function!
It is used in at91 and omap mach.

#ifdef CONFIG_MACH_DO_LOWLEVEL_INIT
        board_init_lowlevel();
#endif

Here we have a more bizarre thing: if __mach__ do low level init then
do __board__ low level init!

In arch/arm/Kconfig we have the same strange things:

config ARCH_VERSATILE
        bool "ARM Versatile boards (ARM926EJ-S)"
        select CPU_ARM926T

But versatile is not arch, it's a mach!

By this examples one can see that the conception of architecture
('arch') is mixed up with the conception of machine ('mach').

Can anybody explain this?

-- 
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [RFC] arm naming inconsistance

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:28 Fri 12 Aug     , Antony Pavlov wrote:
> Hi!
> 
> Barebox has an hierarchy for supported stuff:
> 
>  arch -> mach
> 
>     arch \in {arm, x86, nios2 ...}
> 
>  for arch=arm, mach \in { at91, ims, msx, ... versatile }
> 
>  Also there is the 'board', the lowest level of hierarchy.
> 
>  E.g. for mach=at91, board \in { at91sam9m10g45ek, pm9263 ...}
> 
> But there are strange things in arch/arm/Kconfig and
> arch/arm/cpu/start.c:
> 
> #ifdef CONFIG_ARCH_HAS_LOWLEVEL_INIT
>         arch_init_lowlevel();
> #endif
> 
> At the first glance all ok: if arch has lowlevel init, the do
> arch_init_lowlevel().
> But arch_init_lowlevel() is not __per-arch__ function, but
> __per-mach__ function!
> It is used in at91 and omap mach.
> 
> #ifdef CONFIG_MACH_DO_LOWLEVEL_INIT
>         board_init_lowlevel();
> #endif
in at91 I did so because it's really a board init but the init is generic to
the soc so no need to duplicate it

the only difference are the clock and timings basicly

Best Regards,
J.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [RFC] arm naming inconsistance

[Sascha Hauer]

On Fri, Aug 12, 2011 at 05:28:17PM +0400, Antony Pavlov wrote:
> Hi!
> 
> Barebox has an hierarchy for supported stuff:
> 
>  arch -> mach
> 
>     arch \in {arm, x86, nios2 ...}
> 
>  for arch=arm, mach \in { at91, ims, msx, ... versatile }
> 
>  Also there is the 'board', the lowest level of hierarchy.
> 
>  E.g. for mach=at91, board \in { at91sam9m10g45ek, pm9263 ...}
> 
> But there are strange things in arch/arm/Kconfig and
> arch/arm/cpu/start.c:
> 
> #ifdef CONFIG_ARCH_HAS_LOWLEVEL_INIT
>         arch_init_lowlevel();
> #endif
> 
> At the first glance all ok: if arch has lowlevel init, the do
> arch_init_lowlevel().
> But arch_init_lowlevel() is not __per-arch__ function, but
> __per-mach__ function!
> It is used in at91 and omap mach.

for the at91rm9200 the arch_init_lowlevel() simply should go away.
It sets up the exception vectors which is now done by the mmu code
anyway, at least if it'S enabled. If not, the code should still go
somewhere else. At this early stage we can't do anything with
exceptions since printf is not working.

For Omap this function looks indeed architecture specific (Soc specific
would be a better name, architecture is used for far too many things)
Most of the things here look rather useless. It should be cleaned up
and SoC specific bits should be moved to arch/arm/mach-omap
CONFIG_OMAP3_COPY_CLOCK_SRAM isn't set in any configuration and I have
now idea why I should enable this option. The cache invalidation is
repeated in the generic code.

> 
> #ifdef CONFIG_MACH_DO_LOWLEVEL_INIT
>         board_init_lowlevel();
> #endif
> 
> Here we have a more bizarre thing: if __mach__ do low level init then
> do __board__ low level init!
> 
> In arch/arm/Kconfig we have the same strange things:
> 
> config ARCH_VERSATILE
>         bool "ARM Versatile boards (ARM926EJ-S)"
>         select CPU_ARM926T
> 
> But versatile is not arch, it's a mach!
> 
> By this examples one can see that the conception of architecture
> ('arch') is mixed up with the conception of machine ('mach').

The confusion about architecture and machine has a long tradition.
Arguably an architecture is ARM or x86, but in the arm world
architecture is often used for what we better call SoCs. Sometimes
MACH is used for different SoCs aswell (in the kernel we had MACH_MX21
and MACH_MX27 for a long time, or in both the kernel we have
arch/arm/mach-* instead of arch/arm/soc-*). We should better generally
use 'SoC' and 'board' to make clear what we mean. Mass renaming this
stuff is not a good idea, but at least we should use the right words
in email conversation.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox