On 07/28/11 11:19, Chander Kashyap wrote:
> On 28 July 2011 13:29, Igor Grinberg <grinb...@compulab.co.il> wrote:
>>
>> On 07/28/11 09:41, Chander Kashyap wrote:
>>> Dear Igor,
>>>
>>>
>>> On 27 July 2011 18:34, Igor Grinberg <grinb...@compulab.co.il> wrote:
>>>> On 07/27/11 13:31, Chander Kashyap wrote:
>>>>> dear Igor,
>>>>>
>>>>>
>>>>> On 14 July 2011 21:15, Igor Grinberg <grinb...@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 <grinb...@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.
I've looked into the code a bit more deeply...
Currently, I don't see how the bd initialization can be done earlier than it is
right now,
to let boards use it in board_early_init_f() function and other early functions.
I have not found any other initialization of bd on that architecture,
so this makes the otc570 misuse the bd pointer
(unless 0 is a valid pointer on that architecture, but then it is a total
mess...)
>>>>>> 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@lists.denx.de
>>>>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>>>>
>>>>> >From d8df2f0ca9f08470c0cb88307fea4a66f41147a5 Mon Sep 17 00:00:00 2001
>>>>> From: Chander Kashyap <chander.kash...@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.kash...@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.
If I recall correctly there was an attempt to boot Linux straight from SPL code,
but I'm not sure...
Anyway, if we move the bi_arch_number initialization after the init_sequence[]
array,
then it can be moved further till after the POST.
I'll send a patch for this in a minute.
Can you please test it?
--
Regards,
Igor.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
