public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Igor Grinberg <grinberg@compulab.co.il>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 1/3] arm: add CONFIG_MACH_TYPE setting and documentation
Date: Wed, 27 Jul 2011 16:04:38 +0300	[thread overview]
Message-ID: <4E300CE6.1050605@compulab.co.il> (raw)
In-Reply-To: <CANuQgHGOY58qNS2Pv3uKaiKCOYa1140YNwkWPER-LY9oKrrdYw@mail.gmail.com>

On 07/27/11 13:31, Chander Kashyap wrote:
> dear Igor,
>
>
> On 14 July 2011 21:15, Igor Grinberg <grinberg@compulab.co.il> wrote:
>> CONFIG_MACH_TYPE is used to set the machine type number in the
>> common arm code instead of setting it in the board code.
>> Boards with dynamically discoverable machine types can still set the
>> machine type number in the board code.
>>
>> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
>> ---
>> v2:     Document the option as mandatory.
>>        Move the bi_arch_number setting to board_init_f()
>>
>>  README               |   10 ++++++++++
>>  arch/arm/lib/board.c |    4 ++++
>>  2 files changed, 14 insertions(+), 0 deletions(-)
>>
>> diff --git a/README b/README
>> index 446966d..0b6802d 100644
>> --- a/README
>> +++ b/README
>> @@ -442,6 +442,16 @@ 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][mandatory]
>> +
>> +               This setting is mandatory for all boards that have only one
>> +               machine type and must 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/).
>> +               Only boards that have multiple machine types supported
>> +               in a single configuration file and the machine type is
>> +               runtime discoverable, do not have to use this setting.
>> +
>>  - 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..9901694 100644
>> --- a/arch/arm/lib/board.c
>> +++ b/arch/arm/lib/board.c
>> @@ -281,6 +281,10 @@ void board_init_f (ulong bootflag)
>>
>>        gd->mon_len = _bss_end_ofs;
>>
>> +#ifdef CONFIG_MACH_TYPE
>> +       gd->bd->bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */
>> +#endif
>> +
> bd structure is not initialised by this time.
> It leads to u-boot hanging for my board.
> I fixed this problem but modifying it. Below is the patch attached for the same.

Then how does it work for boards setting the gd->bd->bi_arch_number
in board_early_init_f() function?

>>        for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
>>                if ((*init_fnc_ptr)() != 0) {
>>                        hang ();
>> --
>> 1.7.3.4
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
> >From d8df2f0ca9f08470c0cb88307fea4a66f41147a5 Mon Sep 17 00:00:00 2001
> From: Chander Kashyap <chander.kashyap@linaro.org>
> Date: Wed, 27 Jul 2011 15:10:59 +0530
> Subject: [PATCH] ARM: Fix wrong initialisation of bi_arch_number
>
> bi_arch_number is initialised using
> @arch/arm/lib/board.c
> \#ifdef CONFIG_MACH_TYPE
>         gd->bd->bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */
> \#endif
>
> bd structure is not intialized by this time.
> This leads to u-boot hanging when CONFIG_MACH_TYPE is defined.
>
> Signed-off-by: Chander Kashyap <chander.kashyap@linaro.org>
> ---
>  arch/arm/lib/board.c |    7 +++----
>  1 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index bcbf697..98a9bcc 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -281,10 +281,6 @@ void board_init_f (ulong bootflag)
>
>  	gd->mon_len = _bss_end_ofs;
>
> -#ifdef CONFIG_MACH_TYPE
> -	gd->bd->bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */
> -#endif
> -
>  	for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
>  		if ((*init_fnc_ptr)() != 0) {
>  			hang ();
> @@ -380,6 +376,9 @@ void board_init_f (ulong bootflag)
>  	gd->bd = bd;
>  	debug ("Reserving %zu Bytes for Board Info at: %08lx\n",
>  			sizeof (bd_t), addr_sp);
> +#ifdef CONFIG_MACH_TYPE
> +	gd->bd->bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */
> +#endif

This is problematic...
There are boards that rely on this setting in early init function calls.
For them it should be set before the init_sequence array is run.
I will rethink this once again.

Thanks for testing...


-- 
Regards,
Igor.

  reply	other threads:[~2011-07-27 13:04 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-04  9:00 [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation Igor Grinberg
2011-07-04  9:00 ` [U-Boot] [PATCH 2/3] arm: nvidia and smdk6400: use common code for machine type Igor Grinberg
2011-07-04  9:00 ` [U-Boot] [PATCH 3/3] arm: omap: innovator: " Igor Grinberg
2011-07-04 21:06 ` [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation Christopher Harvey
2011-07-04 22:03   ` Albert ARIBAUD
2011-07-04 22:03     ` Albert ARIBAUD
2011-07-04 22:16   ` Wolfgang Denk
2011-07-05 14:08     ` charvey at matrox.com
2011-07-05 15:12       ` Igor Grinberg
2011-07-05  7:10   ` Igor Grinberg
2011-07-06 18:53 ` Albert ARIBAUD
2011-07-06 20:05   ` Igor Grinberg
2011-07-07 16:07     ` Albert ARIBAUD
2011-07-07 16:51       ` Igor Grinberg
2011-07-07 17:46         ` Albert ARIBAUD
2011-07-07 21:06           ` Igor Grinberg
2011-07-13  5:52             ` Igor Grinberg
2011-07-14 14:10               ` Albert ARIBAUD
2011-07-14 14:20                 ` Albert ARIBAUD
2011-07-14 14:57                   ` Igor Grinberg
2011-07-14 15:45                     ` [U-Boot] [PATCH v2 1/3] arm: add CONFIG_MACH_TYPE setting " Igor Grinberg
2011-07-17  6:56                       ` Igor Grinberg
2011-07-17  9:10                         ` Albert ARIBAUD
2011-07-17  9:08                       ` Albert ARIBAUD
2011-07-27 10:31                       ` Chander Kashyap
2011-07-27 13:04                         ` Igor Grinberg [this message]
2011-07-28  6:41                           ` Chander Kashyap
2011-07-28  7:59                             ` Igor Grinberg
2011-07-28  8:19                               ` Chander Kashyap
2011-07-28  8:58                                 ` Igor Grinberg
2011-08-04 12:05                                   ` Albert ARIBAUD
2011-08-11  4:16                                     ` Chander Kashyap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E300CE6.1050605@compulab.co.il \
    --to=grinberg@compulab.co.il \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox