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. > >>>>> 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. > > > > > -- > Regards, > Igor. > >
-- with warm regards, Chander Kashyap _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
