Hi Albert,
On 4 August 2011 17:35, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: > Hi Igor, > > > On 28/07/2011 10:58, Igor Grinberg wrote: > >> On 07/28/11 11:19, Chander Kashyap wrote: >> >>> On 28 July 2011 13:29, Igor >>> Grinberg<grinb...@compulab.co.**il<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<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<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<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/<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<http://lists.denx.de/mailman/listinfo/u-boot> >>>>>>>> >>>>>>>> > From d8df2f0ca9f08470c0cb88307fea4a**66f41147a5 Mon Sep 17 >>>>>>> 00:00:00 2001 >>>>>>> From: Chander >>>>>>> Kashyap<chander.kashyap@**linaro.org<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.kashyap@**linaro.org<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? >> > > Should I revert this patch? > Either revert this patch or apply new patch sent by Igor. http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/104522 > > Amicalement, > -- > Albert. > -- with warm regards, Chander Kashyap
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
