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