[U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation

[Christopher Harvey <charvey@matrox.com>]

On Mon, Jul 04, 2011 at 12:00:19PM +0300, Igor Grinberg wrote:
> CONFIG_MACH_TYPE can be used to set the machine type number in the
> common arm code instead of setting it in the board code.
> 
> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> ---
>  README               |   12 ++++++++++++
>  arch/arm/lib/board.c |    5 +++++
>  2 files changed, 17 insertions(+), 0 deletions(-)
> 
> diff --git a/README b/README
> index 446966d..a9ccb0a 100644
> --- a/README
> +++ b/README
> @@ -442,6 +442,18 @@ The following options need to be configured:
>  		crash. This is needed for buggy hardware (uc101) where
>  		no pull down resistor is connected to the signal IDE5V_DD7.
>  
> +		CONFIG_MACH_TYPE		[relevant for ARM only]
> +
> +		This option can be used to specify the machine type number
> +		as it appears in the ARM machine registry
> +		(see http://www.arm.linux.org.uk/developer/machines/).
> +		If this option is not defined, then your board code
> +		will have to set this up like:
> +		gd->bd->bi_arch_number = <mach type>;
> +		Note: This option is not suitable if you have multiple
> +		boards supported in a single configuration file and the
> +		machine type is runtime discoverable.
> +
>  - vxWorks boot parameters:
>  
>  		bootvx constructs a valid bootline using the following
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index 169dfeb..ee77d05 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -451,6 +451,11 @@ void board_init_r (gd_t *id, ulong dest_addr)
>  
>  	monitor_flash_len = _end_ofs;
>  	debug ("monitor flash len: %08lX\n", monitor_flash_len);
> +
> +#ifdef CONFIG_MACH_TYPE
> +	bd->bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */
> +#endif
> +
>  	board_init();	/* Setup chipselects */
>  
>  #ifdef CONFIG_SERIAL_MULTI
> -- 
> 1.7.3.4
> 
I'm curious, is it a feature that bd->bi_arch_number can be set at
runtime? Do any boards actually make a decision about what value to
set this to? If not, then maybe it should be a required value.  I've
submitted some patches that deal with the same sort of issue, so I'm
interested in seeing that happens to this one.