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?