Now we know that the boot strap initialization in u-boot is done in assembly and then after initializing an ‘initial’ stack the control flow goes to the ‘C’ functions in u-boot. By looking at other cpu\ and board\ files we can understand that each cpu implements its initial boot strap code in assembly (start.S) and they have specific ‘C’ initialization functions for different boards which use these cpus. The AP7000 processor uses its internal RAM first for allocating a small stack before the SDRAM controller is initialized later in the ‘board_init_f’ function. If SDRAM is not available on the board the booting stalls here, ./lib_avr32/board.c:199:
/* If we have no SDRAM, we can’t go on */
if (sdram_size <= 0)
panic(“No working SDRAM available\n”);
U-boot sets UART Baudrate and initializes the serial console and sends a ‘banner’ to display memory configuration and ram test results. This can be view by connecting gtkTerm or PuTTy to ATngw100 serial port.
Once the SDRAM is initialized u-boot relocates itself from flash to RAM and execute from there. Before relocating code a ‘bigger’ stack and space for the following are allocated in RAM,
– u-boot image
– heap for malloc()
– board info struct
– global data struct(**)
It is interesting that ‘board_init_f’ function never returns, knowing that it was never ‘call’ed! [ ./cpu/at32ap/start.S:186: rjmp board_init_f ]
It simply calls ‘relocate_code((unsigned long)new_sp, new_gd, monitor_addr);’ which is a call to its assembly implementation in start.S.
(**) Did you notice that? There is a mysterious pointer ‘new_gd’ leading us to know more about so called ‘global data struct’ (gd_t) in u-boot! Also I am curios to know how ‘relocate_code’ ‘C’ function call pass parameters to its assembly implementation in start.S!