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

[Tom Rini]

On Thu, Dec 15, 2011 at 11:09 PM, Peter Barada <peter.barada at logicpd.com> wrote:
> On 12/15/2011 01:30 PM, Tom Rini wrote:
>> On Thu, Dec 15, 2011 at 10:15 AM, Peter Barada <peter.barada at 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.
>> #if 0'd code isn't allowed for merging so I assume this is an RFC :)
> My bad - sent the wrong patch.  I'll update and send again.
>>> +               /* Let it soak for a bit */
>>> +               for (i = 0; i < 0x100; ++i)
>>> +                       asm("nop");
>> Can we just use a sdelay(...) here?  And in the whole function you
>> haven't addressed Igor's comment (unless it's incoming and I just
>> haven't gotten the email yet) about this just being checkboard().
> Done - "sdelay(0x100)" instead of the delay loop.

Great, thanks.

> 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.
>
> Remember that identify_board() not only prints a banner but also
> determines one of four machine IDs passed to the linux kernel to
> identify which of the variants its running on.
[snip]
> So the big question before I submit V3 of this patch is whether to
> include overriding OMAP3's checkboard() function or to use
> identify_board() as is to compute bi_arch_number...  I can do it either
> way, but don't want to waste anyone's time (with the wrong method).

OK, after re-reading (and mentally applying the changes you said
you've got) the patches, along with Igor's comments on v1, just inline
your identify logic to board_init()


-- 
Tom