[U-Boot] [PATCH v2] ARMV7: Add support For Logic OMAP35x/DM37x modules

[Igor Grinberg <grinberg@compulab.co.il>]

Hi Peter,

On 12/16/11 08:09, Peter Barada wrote:
> On 12/15/2011 01:30 PM, Tom Rini wrote:
>> On Thu, Dec 15, 2011 at 10:15 AM, Peter Barada <peter.barada@logicpd.com> wrote:
>>> This patch adds basic support for OMAP35x/DM37x SOM LV/Torpedo
>>> reference boards. It assumes U-boot is loaded to SDRAM with the
>>> help of another small bootloader (x-load) running from SRAM.

[...]

> As for the function, in arch/arm/cpu/armv7/omap3/board.c there's already
> a checkboard() function that is called early (before relocation) that
> prints out the banner.  I tried to make that a weak alias and override
> it in my board file, but when its called, gd->bd is not setup so that
> code aborts when it tries to set gd->bd->bi_arch_number.  I then tried
> storing the value in a global and then set gd->bd->bi_arch_number in
> board_init(), but between the call to checkboard() and board_init() the
> BSS section is zeroed.  If I stored/load the computed bi_arch_number
> into a non-zero static value it works, but I feel that is really fragile.

This make me wonder, should we move the checkboard() call further
in the init sequence?
Because, IIRC, it stayed in the same place, where it was, before
the relocation feature was introduced and board_init() was called
before the checkboard() (as board_init_f() does now).
Also, the struct bd_info (bd_t) should have the board data and
ironically it is not available in checkboard() function.

So, Albert, Wolfgang,
the question is, should we move the checkboard() call after
the gd->bd pointer initialization or are there any cases
where it is not appropriate?


-- 
Regards,
Igor.