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

Chander Kashyap chander.kashyap at linaro.org
Thu Jul 28 10:19:18 CEST 2011


On 28 July 2011 13:29, Igor Grinberg <grinberg at compulab.co.il> wrote:
>
>
> On 07/28/11 09:41, Chander Kashyap wrote:
>> Dear Igor,
>>
>>
>> On 27 July 2011 18:34, Igor Grinberg <grinberg at compulab.co.il> wrote:
>>> On 07/27/11 13:31, Chander Kashyap wrote:
>>>> dear Igor,
>>>>
>>>>
>>>> On 14 July 2011 21:15, Igor Grinberg <grinberg at 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 at 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?
>> can you please point out any board which sets in board_early_init_f() ?
>
> board/esd/otc570/otc570.c
>
> Also, I don't think we should restrict setting it to board_init() and later functions.
>
>>>>>        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 at 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 at 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.
>> as per my understanding board_init_f() is the first initialisation call.
>
> Yes, but there is the init_sequence[] array, which calls early board functions...
> Also your proposed patch moves the initialization of bi_arch_number inside
> #ifndef CONFIG_PRELOADER which is IMHO not right.
CONFIG_PRELOADER is only defined when building SPL.
>
>
>
>
> --
> Regards,
> Igor.
>
>



-- 
with warm regards,
Chander Kashyap


More information about the U-Boot mailing list