Where I'm going with x86 board.c

With Simon's work on generic relocation support, I thought I would throw in what I am planning for arch/x86/lib/board.c

Now this is not a patch, it is a work-in-progress complete version of the file (compiles, will test soon) - If feedback is positive, I'll add this to an upcoming patch set

Notice the amount of wrapping around void functions - If all other arch's follow this lead, most of this wrapping can be removed by changing the function signatures.

Lines 428 - 585 are effectively the generic init sequence - The rest is wrappers, init sequence arrays, or fluff that should be moved

I noticed something along the way - gd is no longer special... let me explain...

Some arch's use a dedicated register for the gd pointer - This allows the pointer to be written to prior to relocation. For x86, the gd pointer is simply passed around as a function parameter early - If the init_sequence_f functions accepted a gd pointer as a parameter, there would be no need for it to be global prior to relocation and therefore no need to allocate a permanent register for it - Of course do_init_loop() would no longer be generic for both pre and post relocation. This does mess with the stand-alone API, but as discussed before, stand alone applications should not be accessing gd anyway, so there should be no API to break ;)

And on that note, the following comment is well and truly wrong:

?* The requirements for any new initalization function is simple: it ?* receives a pointer to the "global data" structure as it's only ?* argument, and returns an integer return code, where 0 means ?* "continue" and != 0 means "fatal error, hang the system".

And finally, here 'tis:

/*
?* (C) Copyright 2008-2011
?* Graeme Russ, <[email protected]>
?*
?* (C) Copyright 2002
?* Daniel Engstr?m, Omicron Ceti AB, <[email protected]> ?*
?* (C) Copyright 2002
?* Wolfgang Denk, DENX Software Engineering, <[email protected]> ?*
?* (C) Copyright 2002
?* Sysgo Real-Time Solutions, GmbH <www.elinos.com>
?* Marius Groeger <[email protected]>
?*
?* See file CREDITS for list of people who contributed to this ?* project.
?*
?* This program is free software; you can redistribute it and/or ?* modify it under the terms of the GNU General Public License as ?* published by the Free Software Foundation; either version 2 of ?* the License, or (at your option) any later version.
?*
?* This program is distributed in the hope that it will be useful, ?* but WITHOUT ANY WARRANTY; without even the implied warranty of ?* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the ?* GNU General Public License for more details.
?*
?* You should have received a copy of the GNU General Public License ?* along with this program; if not, write to the Free Software ?* Foundation, Inc., 59 Temple Place, Suite 330, Boston, ?* MA 02111-1307 USA
?*/

#include <common.h>
#include <watchdog.h>
#include <command.h>
#include <stdio_dev.h>
#include <version.h>
#include <malloc.h>
#include <net.h>
#include <ide.h>
#include <serial.h>
#include <asm/u-boot-x86.h>
#include <elf.h>

#ifdef CONFIG_BITBANGMII
#include <miiphy.h>
#endif

/*
?* Pointer to initial global data area
?*
?* Here we initialize it.
?*/
#undef ?XTRN_DECLARE_GLOBAL_DATA_PTR
#define XTRN_DECLARE_GLOBAL_DATA_PTR ? ?/* empty = allocate here */ DECLARE_GLOBAL_DATA_PTR = (gd_t *) (CONFIG_SYS_INIT_GD_ADDR);

/************************************************************************ ?* Init Utilities ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? * ?************************************************************************ ?* Some of this code should be moved into the core functions, ?* or dropped completely,
?* but let's get it working (again) first...
?*/
static int init_baudrate(void)
{
? ? ? ?gd->baudrate = getenv_ulong("baudrate", 10, CONFIG_BAUDRATE); ? ? ? ?return 0;
}

static int display_banner(void)
{

? ? ? ?printf("\n\n%s\n\n", version_string);

? ? ? ?return 0;
}

static int display_dram_config(void)
{
? ? ? ?int i;

? ? ? ?puts("DRAM Configuration:\n");

? ? ? ?for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
? ? ? ? ? ? ? ?printf("Bank #%d: %08lx ", i, gd->bd->bi_dram[i].start); ? ? ? ? ? ? ? ?print_size(gd->bd->bi_dram[i].size, "\n");
? ? ? ?}

? ? ? ?return 0;
}

#ifndef CONFIG_SYS_NO_FLASH
static void display_flash_config(ulong size)
{
? ? ? ?puts("Flash: ");
? ? ? ?print_size(size, "\n");
}
#endif

/*
?* Breath some life into the board...
?*
?* Initialize an SMC for serial comms, and carry out some hardware ?* tests.
?*
?* The first part of initialization is running from Flash memory; ?* its main purpose is to initialize the RAM so that we ?* can relocate the monitor code to RAM.
?*/

/*
?* All attempts to come up with a "common" initialization sequence ?* that works for all boards and architectures failed: some of the ?* requirements are just _too_ different. To get rid of the resulting ?* mess of board dependend #ifdef'ed code we now make the whole ?* initialization sequence configurable to the user.
?*
?* The requirements for any new initalization function is simple: it ?* receives a pointer to the "global data" structure as it's only ?* argument, and returns an integer return code, where 0 means ?* "continue" and != 0 means "fatal error, hang the system". ?*/
typedef int (init_fnc_t) (void);

static int calculate_relocation_address(gd_t *);
static int copy_uboot_to_ram(gd_t *);
static int clear_bss(gd_t *);
static int do_elf_reloc_fixups(gd_t *);

init_fnc_t *init_sequence_f[] = {
? ? ? ?cpu_init_f,
? ? ? ?board_early_init_f,
? ? ? ?env_init,
? ? ? ?init_baudrate,
? ? ? ?serial_init,
? ? ? ?console_init_f,
? ? ? ?dram_init_f,

? ? ? ?NULL,
};

gd_t *gd;
bd_t bd_data;

static int init_bd_struct_r(void)
{
? ? ? ?gd->bd = &bd_data;
? ? ? ?memset(gd->bd, 0, sizeof(bd_t));

? ? ? ?return 0;
}

static int mem_malloc_init_r(void)
{
? ? ? ?mem_malloc_init(((gd->relocaddr - CONFIG_SYS_MALLOC_LEN)+3)&~3, ? ? ? ? ? ? ? ? ? ? ? ?CONFIG_SYS_MALLOC_LEN);

? ? ? ?return 0;
}

static int set_default_baudrate_r(void)
{
? ? ? ?gd->baudrate = CONFIG_BAUDRATE;
? ? ? ?return 0;
}

#ifdef CONFIG_SERIAL_MULTI
static int serial_initialize_r(void)
{
? ? ? ?serial_initialize();

? ? ? ?return 0;
}
#endif

#ifndef CONFIG_SYS_NO_FLASH
static int flash_init_r(void)
{
? ? ? ?ulong size;

? ? ? ?/* configure available FLASH banks */
? ? ? ?size = flash_init();
? ? ? ?display_flash_config(size);
? ? ? ?show_boot_progress(0x24);

? ? ? ?return 0;
}
#endif

static int env_relocate_r(void)
{
? ? ? ?/* initialize environment */
? ? ? ?env_relocate();
? ? ? ?show_boot_progress(0x26);

? ? ? ?return 0;
}

#ifdef CONFIG_CMD_NET
static int init_ip_address_r(void)
{
? ? ? ?/* IP Address */
? ? ? ?bd_data.bi_ip_addr = getenv_IPaddr("ipaddr");

? ? ? ?return 0;
}
#endif

#ifdef CONFIG_PCI
static int pci_init_r(void)
{
? ? ? ?/*
? ? ? ? * Do pci configuration
? ? ? ? */
? ? ? ?pci_init();

? ? ? ?return 0;
}
#endif

static int jumptable_init_r(void)
{
? ? ? ?jumptable_init();

? ? ? ?return 0;
}

#if defined(CONFIG_CMD_PCMCIA) && !defined(CONFIG_CMD_IDE) static int pci_init_r(void)
{
? ? ? ?puts("PCMCIA:");
? ? ? ?pcmcia_init();

? ? ? ?return 0;
}
#endif

#if defined(CONFIG_CMD_KGDB)
static int kgdb_init_r(void)
{
? ? ? ?puts("KGDB: ?");
? ? ? ?kgdb_init();

? ? ? ?return 0;
}
#endif

static int enable_interrupts_r(void)
{
? ? ? ?/* enable exceptions */
? ? ? ?enable_interrupts();
? ? ? ?show_boot_progress(0x28);

? ? ? ?return 0;
}

#ifdef CONFIG_STATUS_LED
static int status_led_set_r(void)
{
? ? ? ?status_led_set(STATUS_LED_BOOT, STATUS_LED_BLINKING); ? ? ? ?udelay(20);

? ? ? ?return 0;
}
#endif

#if defined(CONFIG_CMD_NET)
static int set_bootfile_r(void)
{
? ? ? ?char *s;

? ? ? ?s = getenv("bootfile");

? ? ? ?if (s != NULL)
? ? ? ? ? ? ? ?copy_filename(BootFile, s, sizeof(BootFile));

? ? ? ?return 0;
}

static int eth_initialize_r(void)
{
? ? ? ?puts("Net: ? ");
? ? ? ?eth_initialize(gd->bd);

? ? ? ?return 0;
}

#ifdef CONFIG_RESET_PHY_R
static int reset_phy_r(void)
{
#ifdef DEBUG
? ? ? ?puts("Reset Ethernet PHY\n");
#endif
? ? ? ?reset_phy();

? ? ? ?return 0;
}
#endif

#endif

static int set_load_addr_r(void)
{
? ? ? ?/* Initialize from environment */
? ? ? ?load_addr = getenv_ulong("loadaddr", 16, load_addr);

? ? ? ?return 0;
}

#if defined(CONFIG_CMD_IDE)
static int ide_init_r(void)
{
? ? ? ?puts("IDE: ? ");
? ? ? ?ide_init();

? ? ? ?return 0;
}
#endif

#if defined(CONFIG_CMD_SCSI)
static int scsi_init_r(void)
{
? ? ? ?puts("SCSI: ?");
? ? ? ?scsi_init();

? ? ? ?return 0;
}
#endif

#if defined(CONFIG_CMD_DOC)
static int doc_init_r(void)
{
? ? ? ?puts("DOC: ? ");
? ? ? ?doc_init();

? ? ? ?return 0;
}
#endif

#ifdef CONFIG_BITBANGMII
static int bb_miiphy_init_r(void)
{
? ? ? ?bb_miiphy_init();

? ? ? ?return 0;
}
#endif

#ifdef CONFIG_POST
static int post_run_r(void)
{
? ? ? ?post_run(NULL, POST_RAM | post_bootmode_get(0));

? ? ? ?return 0;
}
#endif

init_fnc_t *init_sequence_r[] = {
? ? ? ?init_bd_struct_r,
? ? ? ?mem_malloc_init_r,
? ? ? ?set_default_baudrate_r,
? ? ? ?cpu_init_r, ? ? ? ? ? ? /* basic cpu dependent setup */ ? ? ? ?board_early_init_r, ? ? /* basic board dependent setup */ ? ? ? ?dram_init, ? ? ? ? ? ? ?/* configure available RAM banks */ ? ? ? ?interrupt_init, ? ? ? ? /* set up exceptions */ ? ? ? ?timer_init,
? ? ? ?display_banner,
? ? ? ?display_dram_config,
#ifdef CONFIG_SERIAL_MULTI
? ? ? ?serial_initialize_r,
#endif
#ifndef CONFIG_SYS_NO_FLASH
? ? ? ?flash_init_r,
#endif
? ? ? ?env_relocate_r,
#ifdef CONFIG_CMD_NET
? ? ? ?init_ip_address_r,
#endif
#ifdef CONFIG_PCI
? ? ? ?pci_init_r,
#endif
? ? ? ?stdio_init,
? ? ? ?jumptable_init_r,
? ? ? ?console_init_r,
#ifdef CONFIG_MISC_INIT_R
? ? ? ?misc_init_r,
#endif
#if defined(CONFIG_CMD_PCMCIA) && !defined(CONFIG_CMD_IDE) ? ? ? ?pci_init_r,
#endif
#if defined(CONFIG_CMD_KGDB)
? ? ? ?kgdb_init_r,
#endif
? ? ? ?enable_interrupts_r,
#ifdef CONFIG_STATUS_LED
? ? ? ?status_led_set_r,
#endif
? ? ? ?set_load_addr_r,
#if defined(CONFIG_CMD_NET)
? ? ? ?set_bootfile_r,
#endif
#if defined(CONFIG_CMD_IDE)
? ? ? ?ide_init_r,
#endif
#if defined(CONFIG_CMD_SCSI)
? ? ? ?scsi_init_r,
#endif
#if defined(CONFIG_CMD_DOC)
? ? ? ?doc_init_r,
#endif
#ifdef CONFIG_BITBANGMII
? ? ? ?bb_miiphy_init_r,
#endif
#if defined(CONFIG_CMD_NET)
? ? ? ?eth_initialize_r,
#ifdef CONFIG_RESET_PHY_R
? ? ? ?reset_phy_r,
#endif
#endif
#ifdef CONFIG_LAST_STAGE_INIT
? ? ? ?last_stage_init,
#endif
? ? ? ?NULL,
};

static int calculate_relocation_address(gd_t *id)
{
? ? ? ?ulong text_start = (ulong)&__text_start;
? ? ? ?ulong bss_end = (ulong)&__bss_end;
? ? ? ?ulong dest_addr;
? ? ? ?ulong rel_offset;

? ? ? ?/* Calculate destination RAM Address and relocation offset */ ? ? ? ?dest_addr = id->start_addr_sp;
? ? ? ?dest_addr -= CONFIG_SYS_STACK_SIZE;
? ? ? ?dest_addr -= (bss_end - text_start);

? ? ? ?/*
? ? ? ? * Round destination address down to 16-byte boundary to keep ? ? ? ? * IDT and GDT 16-byte aligned
? ? ? ? */
? ? ? ?dest_addr &= ~15;

? ? ? ?rel_offset = dest_addr - text_start;

? ? ? ?id->relocaddr = dest_addr;
? ? ? ?id->reloc_off = rel_offset;

? ? ? ?return 0;
}

static int copy_uboot_to_ram(gd_t *id)
{
? ? ? ?size_t len = (size_t)&__data_end - (size_t)&__text_start;

? ? ? ?memcpy((void *)id->relocaddr, (void *)&__text_start, len);

? ? ? ?return 0;
}

static int clear_bss(gd_t *id)
{
? ? ? ?ulong dst_addr = (ulong)&__bss_start + id->reloc_off; ? ? ? ?size_t len = (size_t)&__bss_end - (size_t)&__bss_start;

? ? ? ?memset((void *)dst_addr, 0x00, len);

? ? ? ?return 0;
}

static int do_elf_reloc_fixups(gd_t *id)
{
? ? ? ?Elf32_Rel *re_src = (Elf32_Rel *)(&__rel_dyn_start); ? ? ? ?Elf32_Rel *re_end = (Elf32_Rel *)(&__rel_dyn_end);

? ? ? ?Elf32_Addr *offset_ptr_rom;
? ? ? ?Elf32_Addr *offset_ptr_ram;

? ? ? ?/* The size of the region of u-boot that runs out of RAM. */ ? ? ? ?uintptr_t size = (uintptr_t)&__bss_end - (uintptr_t)&__text_start;

? ? ? ?do {
? ? ? ? ? ? ? ?/* Get the location from the relocation entry */ ? ? ? ? ? ? ? ?offset_ptr_rom = (Elf32_Addr *)re_src->r_offset;

? ? ? ? ? ? ? ?/* Check that the location of the relocation is in .text */ ? ? ? ? ? ? ? ?if (offset_ptr_rom >= (Elf32_Addr *)CONFIG_SYS_TEXT_BASE) {

? ? ? ? ? ? ? ? ? ? ? ?/* Switch to the in-RAM version */
? ? ? ? ? ? ? ? ? ? ? ?offset_ptr_ram = (Elf32_Addr *)((ulong)offset_ptr_rom + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?id->reloc_off);

? ? ? ? ? ? ? ? ? ? ? ?/* Check that the target points into .text */ ? ? ? ? ? ? ? ? ? ? ? ?if (*offset_ptr_ram >= CONFIG_SYS_TEXT_BASE && ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?*offset_ptr_ram <
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(CONFIG_SYS_TEXT_BASE + size)) { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?*offset_ptr_ram += id->reloc_off; ? ? ? ? ? ? ? ? ? ? ? ?}
? ? ? ? ? ? ? ?}
? ? ? ?} while (re_src++ < re_end);

? ? ? ?return 0;
}

static void do_init_loop(init_fnc_t **init_fnc_ptr) {
? ? ? ?for (; *init_fnc_ptr; ++init_fnc_ptr) { ? ? ? ? ? ? ? ?WATCHDOG_RESET();
? ? ? ? ? ? ? ?if ((*init_fnc_ptr)() != 0) ? ? ? ? ? ? ? ? ? ? ? ?hang();
? ? ? ?}
}

/* Load U-Boot into RAM, initialize BSS, perform relocation adjustments */ void board_init_f(ulong boot_flags)
{
? ? ? ?gd->flags = boot_flags;

? ? ? ?do_init_loop(init_sequence_f);

? ? ? ?/* SDRAM is now initialised setup a new stack in SDRAM */ ? ? ? ?setup_sdram_environment(gd->ram_size, GENERATED_GBL_DATA_SIZE);

? ? ? ?/* NOTREACHED - relocate_code() does not return */ ? ? ? ?while (1)
? ? ? ? ? ? ? ?;
}

typedef void (board_init_r_t) (gd_t *, ulong);

void relocate_code(ulong stack_ptr, gd_t *id, ulong reloc_addr) {
? ? ? ?board_init_r_t *board_init_r_func;

? ? ? ?/* We are running from flash, but the stack is now in SDRAM */

? ? ? ?/* gd is still in CAR - Copy it into SDRAM */ ? ? ? ?memcpy(id, gd, sizeof(gd_t));

? ? ? ?id->start_addr_sp = stack_ptr;

? ? ? ?if (init_cache() != 0)
? ? ? ? ? ? ? ?hang();

? ? ? ?calculate_relocation_address(id);
? ? ? ?copy_uboot_to_ram(id);
? ? ? ?clear_bss(id);
? ? ? ?do_elf_reloc_fixups(id);

? ? ? ?board_init_r_func = board_init_r;
? ? ? ?board_init_r_func += id->reloc_off;
? ? ? ?board_init_r_func(id, id->relocaddr);

? ? ? ?/* NOTREACHED - relocate_code() does not return */ ? ? ? ?while (1)
? ? ? ? ? ? ? ?;
}

void board_init_r(gd_t *id, ulong dest_addr)
{
? ? ? ?/* Global data pointer is now writable */
? ? ? ?gd = id;

? ? ? ?gd->flags |= GD_FLG_RELOC;

? ? ? ?/* compiler optimization barrier needed for GCC >= 3.4 */ ? ? ? ?__asm__ __volatile__("" : : : "memory");

? ? ? ?do_init_loop(init_sequence_r);

? ? ? ?/* main_loop() can return to retry autoboot, if so just run it again. */ ? ? ? ?for (;;)
? ? ? ? ? ? ? ?main_loop();

? ? ? ?/* NOTREACHED - no way out of command loop except booting */ }

void hang(void)
{
? ? ? ?puts("### ERROR ### Please RESET the board ###\n"); ? ? ? ?for (;;)
? ? ? ? ? ? ? ?;
}

unsigned long do_go_exec(ulong (*entry)(int, char * const []), ? ? ? ? ? ? ? ? ? ? ? ? int argc, char * const argv[]) {
? ? ? ?unsigned long ret = 0;
? ? ? ?char **argv_tmp;

? ? ? ?/*
? ? ? ? * x86 does not use a dedicated register to pass the pointer to ? ? ? ? * the global_data, so it is instead passed as argv[-1]. By using ? ? ? ? * argv[-1], the called 'Application' can use the contents of ? ? ? ? * argv natively. However, to safely use argv[-1] a new copy of ? ? ? ? * argv is needed with the extra element
? ? ? ? */
? ? ? ?argv_tmp = malloc(sizeof(char *) * (argc + 1));

? ? ? ?if (argv_tmp) {
? ? ? ? ? ? ? ?argv_tmp[0] = (char *)gd;

? ? ? ? ? ? ? ?memcpy(&argv_tmp[1], argv, (size_t)(sizeof(char *) * argc));

? ? ? ? ? ? ? ?ret = (entry) (argc, &argv_tmp[1]); ? ? ? ? ? ? ? ?free(argv_tmp);
? ? ? ?}

? ? ? ?return ret;
}

void setup_pcat_compatibility(void)
? ? ? ?__attribute__((weak, alias("__setup_pcat_compatibility")));

void __setup_pcat_compatibility(void)
{
}

Hi Graeme,

Quoted 6 lines · Graeme Russ

With Simon's work on generic relocation support, I thought I would throw in what I am planning for arch/x86/lib/board.c

Now this is not a patch, it is a work-in-progress complete version of the file (compiles, will test soon) - If feedback is positive, I'll add this to an upcoming patch set

Looks good to me+++

Quoted 10 lines

Notice the amount of wrapping around void functions - If all other arch's follow this lead, most of this wrapping can be removed by changing the function signatures.

Lines 428 - 585 are effectively the generic init sequence - The rest is wrappers, init sequence arrays, or fluff that should be moved

I noticed something along the way - gd is no longer special... let me explain...

Quoted 9 lines

Some arch's use a dedicated register for the gd pointer - This allows the pointer to be written to prior to relocation. For x86, the gd pointer is simply passed around as a function parameter early - If the init_sequence_f functions accepted a gd pointer as a parameter, there would be no need for it to be global prior to relocation and therefore no need to allocate a permanent register for it - Of course do_init_loop() would no longer be generic for both pre and post relocation. This does mess with the stand-alone API, but as discussed before, stand alone applications should not be accessing gd anyway, so there should be no API to break ;)

Actually as it happens I did a bit of an experiment with this some weeks ago and my original board stuff had gd as a parameter for the pre-reloc functions (some with stubs to other ones like console_init_f()). On ARM it really doesn't make a lot of sense to use a global variable instead of a parameter. I decided that it was a bit much to bite off in one go :-) Partly that was because IMO gd really only makes sense prior to relocation - for the post-relocation init calls they don't have a lot of need for gd.

So it has my vote. Once I get somewhere on the reboard series I will post my common/board.c. As I may have mentioned I have elected so far to leave the initcall list and local functions in arch/xxx/lib/board.c.

Would be good to get all this moving.

Hi Simon,

Quoted 11 lines · Simon Glass

Hi Graeme,

Quoted 6 lines · Graeme Russ

With Simon's work on generic relocation support, I thought I would throw in what I am planning for arch/x86/lib/board.c

Now this is not a patch, it is a work-in-progress complete version of the file (compiles, will test soon) - If feedback is positive, I'll add this to an upcoming patch set

Looks good to me+++

Thanks for having a look :)

Quoted 20 lines

Quoted 10 lines

Notice the amount of wrapping around void functions - If all other arch's follow this lead, most of this wrapping can be removed by changing the function signatures.

Lines 428 - 585 are effectively the generic init sequence - The rest is wrappers, init sequence arrays, or fluff that should be moved

I noticed something along the way - gd is no longer special... let me explain...

Quoted 9 lines

Some arch's use a dedicated register for the gd pointer - This allows the pointer to be written to prior to relocation. For x86, the gd pointer is simply passed around as a function parameter early - If the init_sequence_f functions accepted a gd pointer as a parameter, there would be no need for it to be global prior to relocation and therefore no need to allocate a permanent register for it - Of course do_init_loop() would no longer be generic for both pre and post relocation. This does mess with the stand-alone API, but as discussed before, stand alone applications should not be accessing gd anyway, so there should be no API to break ;)

Quoted 8 lines

Actually as it happens I did a bit of an experiment with this some weeks ago and my original board stuff had gd as a parameter for the pre-reloc functions (some with stubs to other ones like console_init_f()). On ARM it really doesn't make a lot of sense to use a global variable instead of a parameter. I decided that it was a bit much to bite off in one go :-) Partly that was because IMO gd really only makes sense prior to relocation - for the post-relocation init calls they don't have a lot of need for gd.

I don't think this is 100% correct - I'm sure gd is used all over the place post init

Quoted 7 lines

So it has my vote. Once I get somewhere on the reboard series I will post my common/board.c. As I may have mentioned I have elected so far to leave the initcall list and local functions in arch/xxx/lib/board.c.

Would be good to get all this moving.

Well, I have a more thorough patch in the making - I creates init_wrappers.c and init_helpers.c and board.c collapses very dramatically (see below) - with a lot of #ifdef hell...

Notice the new board_init_f_r() - This is where U-Boot is running from Flash, but SDRAM has been initialised and the stack is now in RAM - So this is where we move gd to RAM and perform relocation. As a bonus, relocation can be done with cache enabled :)

Regards,

Graeme

/*
?* (C) Copyright 2008-2011
?* Graeme Russ, <[email protected]>
?*
?* (C) Copyright 2002
?* Daniel Engstr?m, Omicron Ceti AB, <[email protected]> ?*
?* (C) Copyright 2002
?* Wolfgang Denk, DENX Software Engineering, <[email protected]> ?*
?* (C) Copyright 2002
?* Sysgo Real-Time Solutions, GmbH <www.elinos.com>
?* Marius Groeger <[email protected]>
?*
?* See file CREDITS for list of people who contributed to this ?* project.
?*
?* This program is free software; you can redistribute it and/or ?* modify it under the terms of the GNU General Public License as ?* published by the Free Software Foundation; either version 2 of ?* the License, or (at your option) any later version.
?*
?* This program is distributed in the hope that it will be useful, ?* but WITHOUT ANY WARRANTY; without even the implied warranty of ?* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the ?* GNU General Public License for more details.
?*
?* You should have received a copy of the GNU General Public License ?* along with this program; if not, write to the Free Software ?* Foundation, Inc., 59 Temple Place, Suite 330, Boston, ?* MA 02111-1307 USA
?*/

#include <common.h>
#include <watchdog.h>
#include <stdio_dev.h>
#include <asm/u-boot-x86.h>

#include <asm/init_helpers.h>
#include <asm/init_wrappers.h>

/*
?* Pointer to initial global data area
?*
?* Here we initialize it.
?*/
#undef ?XTRN_DECLARE_GLOBAL_DATA_PTR
#define XTRN_DECLARE_GLOBAL_DATA_PTR ? ?/* empty = allocate here */ DECLARE_GLOBAL_DATA_PTR = (gd_t *) (CONFIG_SYS_INIT_GD_ADDR);

/*
?* Breath some life into the board...
?*
?* Initialize an SMC for serial comms, and carry out some hardware ?* tests.
?*
?* The first part of initialization is running from Flash memory; ?* its main purpose is to initialize the RAM so that we ?* can relocate the monitor code to RAM.
?*/

/*
?* All attempts to come up with a "common" initialization sequence ?* that works for all boards and architectures failed: some of the ?* requirements are just _too_ different. To get rid of the resulting ?* mess of board dependend #ifdef'ed code we now make the whole ?* initialization sequence configurable to the user.
?*
?* The requirements for any new initalization function is simple: it ?* receives a pointer to the "global data" structure as it's only ?* argument, and returns an integer return code, where 0 means ?* "continue" and != 0 means "fatal error, hang the system". ?*/
typedef int (init_fnc_t) (void);

init_fnc_t *init_sequence_f[] = {
? ? ? ?cpu_init_f,
? ? ? ?board_early_init_f,
? ? ? ?env_init,
? ? ? ?init_baudrate_f,
? ? ? ?serial_init,
? ? ? ?console_init_f,
? ? ? ?dram_init_f,

? ? ? ?NULL,
};

init_fnc_t *init_sequence_r[] = {
? ? ? ?init_bd_struct_r,
? ? ? ?mem_malloc_init_r,
? ? ? ?cpu_init_r,
? ? ? ?board_early_init_r,
? ? ? ?dram_init,
? ? ? ?interrupt_init,
? ? ? ?timer_init,
? ? ? ?display_banner,
? ? ? ?display_dram_config,
#ifdef CONFIG_SERIAL_MULTI
? ? ? ?serial_initialize_r,
#endif
#ifndef CONFIG_SYS_NO_FLASH
? ? ? ?flash_init_r,
#endif
? ? ? ?env_relocate_r,
#ifdef CONFIG_CMD_NET
? ? ? ?init_ip_address_r,
#endif
#ifdef CONFIG_PCI
? ? ? ?pci_init_r,
#endif
? ? ? ?stdio_init,
? ? ? ?jumptable_init_r,
? ? ? ?console_init_r,
#ifdef CONFIG_MISC_INIT_R
? ? ? ?misc_init_r,
#endif
#if defined(CONFIG_CMD_PCMCIA) && !defined(CONFIG_CMD_IDE) ? ? ? ?pci_init_r,
#endif
#if defined(CONFIG_CMD_KGDB)
? ? ? ?kgdb_init_r,
#endif
? ? ? ?enable_interrupts_r,
#ifdef CONFIG_STATUS_LED
? ? ? ?status_led_set_r,
#endif
? ? ? ?set_load_addr_r,
#if defined(CONFIG_CMD_NET)
? ? ? ?set_bootfile_r,
#endif
#if defined(CONFIG_CMD_IDE)
? ? ? ?ide_init_r,
#endif
#if defined(CONFIG_CMD_SCSI)
? ? ? ?scsi_init_r,
#endif
#if defined(CONFIG_CMD_DOC)
? ? ? ?doc_init_r,
#endif
#ifdef CONFIG_BITBANGMII
? ? ? ?bb_miiphy_init_r,
#endif
#if defined(CONFIG_CMD_NET)
? ? ? ?eth_initialize_r,
#ifdef CONFIG_RESET_PHY_R
? ? ? ?reset_phy_r,
#endif
#endif
#ifdef CONFIG_LAST_STAGE_INIT
? ? ? ?last_stage_init,
#endif
? ? ? ?NULL,
};

static void do_init_loop(init_fnc_t **init_fnc_ptr) {
? ? ? ?for (; *init_fnc_ptr; ++init_fnc_ptr) { ? ? ? ? ? ? ? ?WATCHDOG_RESET();
? ? ? ? ? ? ? ?if ((*init_fnc_ptr)() != 0) ? ? ? ? ? ? ? ? ? ? ? ?hang();
? ? ? ?}
}

/* Perform all steps necessary to get RAM initialised ready for relocation */ void board_init_f(ulong boot_flags)
{
? ? ? ?gd->flags = boot_flags;

? ? ? ?do_init_loop(init_sequence_f);

? ? ? ?/*
? ? ? ? * SDRAM is now initialised setup a new stack in SDRAM ? ? ? ? *
? ? ? ? * Code execution will continue in Flash, but with the stack ? ? ? ? * in SDRAM. This allows us to copy global data out of the CPU ? ? ? ? * cache prior to copying U-Boot into RAM which means we can ? ? ? ? * enable caching for the copy operation (which speeds it up ? ? ? ? * considerably)
? ? ? ? */
? ? ? ?move_stack_to_sdram(gd->ram_size);

? ? ? ?/* NOTREACHED - move_stack_to_sdram() does not return */ ? ? ? ?while (1)
? ? ? ? ? ? ? ?;
}

void board_init_f_r(gd_t *id)
{
? ? ? ?/*
? ? ? ? * U-Boot is running from flash, but the stack is now in SDRAM ? ? ? ? * (id = top of stack = final location of global data) ? ? ? ? */

? ? ? ?/*
? ? ? ? * gd is still in CAR - Copy it into SDRAM
? ? ? ? *
? ? ? ? * NOTE: We cannot set the gd variable yet as it lives in .data ? ? ? ? * which has not been relocated to RAM yet
? ? ? ? */
? ? ? ?memcpy(id, gd, sizeof(gd_t));

? ? ? ?/* Initialise the CPU cache(s) */
? ? ? ?if (init_cache() != 0)
? ? ? ? ? ? ? ?hang();

? ? ? ?/* Copy U-Boot to RAM and resume code execution in RAM */ ? ? ? ?relocate_code(0, id, 0);

? ? ? ?/* NOTREACHED - relocate_code() does not return */ ? ? ? ?while (1)
? ? ? ? ? ? ? ?;
}

__attribute__ ((__noreturn__))
void board_init_r(gd_t *id, ulong dest_addr)
{
? ? ? ?/* Global data pointer is now writable */
? ? ? ?gd = id;

? ? ? ?gd->flags |= GD_FLG_RELOC;

? ? ? ?/* compiler optimization barrier needed for GCC >= 3.4 */ ? ? ? ?__asm__ __volatile__("" : : : "memory");

? ? ? ?do_init_loop(init_sequence_r);

? ? ? ?/* main_loop() can return to retry autoboot, if so just run it again. */ ? ? ? ?for (;;)
? ? ? ? ? ? ? ?main_loop();

? ? ? ?/* NOTREACHED - no way out of command loop except booting */ }

__attribute__ ((__noreturn__))
void hang(void)
{
? ? ? ?puts("### ERROR ### Please RESET the board ###\n"); ? ? ? ?for (;;)
? ? ? ? ? ? ? ?;
}

Hi Graeme,

Quoted 46 lines · Graeme Russ

Hi Simon,

Quoted 11 lines · Simon Glass

Hi Graeme,

Quoted 6 lines · Graeme Russ

With Simon's work on generic relocation support, I thought I would throw in what I am planning for arch/x86/lib/board.c

Now this is not a patch, it is a work-in-progress complete version of the file (compiles, will test soon) - If feedback is positive, I'll add this to an upcoming patch set

Looks good to me+++

Thanks for having a look :)

Quoted 28 lines

Quoted 10 lines

Notice the amount of wrapping around void functions - If all other arch's follow this lead, most of this wrapping can be removed by changing the function signatures.

Lines 428 - 585 are effectively the generic init sequence - The rest is wrappers, init sequence arrays, or fluff that should be moved

I noticed something along the way - gd is no longer special... let me explain...

Quoted 9 lines

Some arch's use a dedicated register for the gd pointer - This allows the pointer to be written to prior to relocation. For x86, the gd pointer is simply passed around as a function parameter early - If the init_sequence_f functions accepted a gd pointer as a parameter, there would be no need for it to be global prior to relocation and therefore no need to allocate a permanent register for it - Of course do_init_loop() would no longer be generic for both pre and post relocation. This does mess with the stand-alone API, but as discussed before, stand alone applications should not be accessing gd anyway, so there should be no API to break ;)

Actually as it happens I did a bit of an experiment with this some weeks ago and my original board stuff had gd as a parameter for the pre-reloc functions (some with stubs to other ones like console_init_f()). On ARM it really doesn't make a lot of sense to use a global variable instead of a parameter. I decided that it was a bit much to bite off in one go :-) Partly that was because IMO gd really only makes sense prior to relocation - for the post-relocation init calls they don't have a lot of need for gd.

Quoted 2 lines

I don't think this is 100% correct - I'm sure gd is used all over the place post init

Not enough that it needs to be in its own register. This compile-time decision affects the whole of U-Boot post-relocation. In some routines there is a small code size / performance advantage to having r8 available.

Also it is a bit of a misnomer when used after relocation. There is lots of global data (the whole BSS) not just one structure. Arguably some things like the network code would be smaller/faster using global_data and without total reliance on global variables, but anyway it seems to me that gd is mostly a convenience for pre-relocation where memory may not be available.

Quoted 8 lines

Quoted 7 lines

So it has my vote. Once I get somewhere on the reboard series I will post my common/board.c. As I may have mentioned I have elected so far to leave the initcall list and local functions in arch/xxx/lib/board.c.

Would be good to get all this moving.

Quoted 3 lines

Well, I have a more thorough patch in the making - I creates init_wrappers.c and init_helpers.c and board.c collapses very dramatically (see below) - with a lot of #ifdef hell...

I thing that all pre-reloc functions that are called should have the same signature - i.e. return an int. if we (later) move to passing gd around then they would change in that way also.

Quoted 5 lines

Notice the new board_init_f_r() - This is where U-Boot is running from Flash, but SDRAM has been initialised and the stack is now in RAM - So this is where we move gd to RAM and perform relocation. As a bonus, relocation can be done with cache enabled :)

Yes I see. It is not so easy on ARM since we need the MMU also, but I think it can be done. Once data is set up / copied in its new location we can use it even prior to relocation. I also recently created a patch to delay console init until after relocation (cue screams on the list) which saves time.

Regards,
Simon

Hi Simon,

Le 22/12/2011 16:49, Simon Glass a ?crit :

Quoted 72 lines

Hi Graeme,

Quoted 63 lines · On Thu, Dec 22, 2011 at 3:27 AM, Graeme Russ<[email protected]> ?wrote:

Hi Simon,

Quoted 10 lines · Simon Glass

Hi Graeme,

Quoted 5 lines · On Tue, Dec 20, 2011 at 4:06 AM, Graeme Russ<[email protected]> ?wrote:

With Simon's work on generic relocation support, I thought I would throw in
what I am planning for arch/x86/lib/board.c

Quoted 8 lines

Quoted 5 lines

Now this is not a patch, it is a work-in-progress complete version of the
file (compiles, will test soon) - If feedback is positive, I'll add this to
an upcoming patch set

Looks good to me+++

Thanks for having a look :)

Quoted 27 lines

Quoted 11 lines

Notice the amount of wrapping around void functions - If all other arch's
follow this lead, most of this wrapping can be removed by changing the function signatures.

Lines 428 - 585 are effectively the generic init sequence - The rest is wrappers, init sequence arrays, or fluff that should be moved

I noticed something along the way - gd is no longer special... let me explain...

Quoted 14 lines

Some arch's use a dedicated register for the gd pointer - This allows the
pointer to be written to prior to relocation. For x86, the gd pointer is
simply passed around as a function parameter early - If the init_sequence_f
functions accepted a gd pointer as a parameter, there would be no need for
it to be global prior to relocation and therefore no need to allocate a permanent register for it - Of course do_init_loop() would no longer be generic for both pre and post relocation. This does mess with the stand-alone API, but as discussed before, stand alone applications should
not be accessing gd anyway, so there should be no API to break ;)

Quoted 8 lines

Actually as it happens I did a bit of an experiment with this some weeks ago and my original board stuff had gd as a parameter for the pre-reloc functions (some with stubs to other ones like console_init_f()). On ARM it really doesn't make a lot of sense to use a global variable instead of a parameter. I decided that it was a bit much to bite off in one go :-) Partly that was because IMO gd really only makes sense prior to relocation - for the post-relocation init calls they don't have a lot of need for gd.

Quoted 3 lines

I don't think this is 100% correct - I'm sure gd is used all over the place
post init

Quoted 4 lines

Not enough that it needs to be in its own register. This compile-time decision affects the whole of U-Boot post-relocation. In some routines there is a small code size / performance advantage to having r8 available.

From measurements I did when working on ARM relocation, I remember having tried if reserving a(nother) global register would change code size, and IIRC, it did not have a big impact on code size/efficiency.

Quoted 8 lines

Also it is a bit of a misnomer when used after relocation. There is lots of global data (the whole BSS) not just one structure. Arguably some things like the network code would be smaller/faster using global_data and without total reliance on global variables, but anyway it seems to me that gd is mostly a convenience for pre-relocation where memory may not be available.

Indeed, gd is a convenience for pre-relocation, but the point is not that memory may not be available : gd points to memory, so there must be some memory available anyway, be it SRAM, locked data cache or even SDRAM for some boards.

The convenience is that you cannot tell in advance where that memory will be, so you need a pointer, and gd is that pointer; it could indeed be passed as an argument from function to function, thus going from register to register to stack back and forth, or be allocated its own register, and considering most of pre-relocation code will want to access gd, allocating it globally to a register makes sense as it reduces stack usage (no passing of gd) and does not hurt performance that much.

Quoted 17 lines

Quoted 8 lines

Quoted 8 lines

So it has my vote. Once I get somewhere on the reboard series I will post my common/board.c. As I may have mentioned I have elected so far to leave the initcall list and local functions in arch/xxx/lib/board.c.

Quoted 7 lines

Quoted 1 line

Would be good to get all this moving.

Well, I have a more thorough patch in the making - I creates init_wrappers.c and init_helpers.c and board.c collapses very dramatically
(see below) - with a lot of #ifdef hell...

Quoted 3 lines

I thing that all pre-reloc functions that are called should have the same signature - i.e. return an int. if we (later) move to passing gd around then they would change in that way also.

That's one way of seeing it, particularly when these functions are put in a table, but note that there is no *reason* for all functions to have the same signature, no more than there would be reason for post-reloc functions to either. If a design crops up for pre-reloc code where functions involved have different signatures, and it is simple, efficient and maintainable, I personally won't oppose it on the basis of signature heterogeneity.

Quoted 8 lines

Quoted 8 lines

Notice the new board_init_f_r() - This is where U-Boot is running from Flash, but SDRAM has been initialised and the stack is now in RAM - So this
is where we move gd to RAM and perform relocation. As a bonus, relocation can be done with cache enabled :)

Not sure why this intermediary function/state is required.

Quoted 7 lines

Yes I see. It is not so easy on ARM since we need the MMU also, but I think it can be done. Once data is set up / copied in its new location we can use it even prior to relocation. I also recently created a patch to delay console init until after relocation (cue screams on the list) which saves time.

Saving time may be a good thing, but for a bootloader, this would go second to always knowing what happens, so if delaying console init means risking the loss of some console output in case of stray code execution, then indeed there will be screaming.

Quoted 3 lines

Regards,
Simon

Amicalement,
--
Albert.