On 07/28/11 11:19, Chander Kashyap wrote:
On 28 July 2011 13:29, Igor Grinberg grinberg@compulab.co.il wrote:
On 07/28/11 09:41, Chander Kashyap wrote:
Dear Igor,
On 27 July 2011 18:34, Igor Grinberg grinberg@compulab.co.il wrote:
On 07/27/11 13:31, Chander Kashyap wrote:
dear Igor,
On 14 July 2011 21:15, Igor Grinberg grinberg@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@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 onemachine type and must be used to specify the machine typenumber as it appears in the ARM machine registry(see http://www.arm.linux.org.uk/developer/machines/).Only boards that have multiple machine types supportedin a single configuration file and the machine type isruntime discoverable, do not have to use this setting.
vxWorks boot parameters:
bootvx constructs a valid bootline using the followingdiff --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.kashyap@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
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?