Greetings,
I've been fighting with SPL passing not boot_params properly to u-boot on OMAP4. There are many layers to this onion but I've tracked the bulk of the problem down to the following issues.
--- SPL ---
arch/arm/cpu/armv7/omap-common/hwinit-common.c sets a pointer to the SPL's &boot_params correctly (cpu_init_crit->lowlevel_init->s_init) but the definition of that pointer in common/spl/spl.c:
u32 *boot_params_ptr = NULL;
puts it into the spl bss section (in SDRAM) which is cleared long after cpu_init_crit(). Making that:
u32 *boot_params_ptr __attribute__ ((section(".data")));
allows the pointer to be in SPL data section (SRAM) and still have its value by the time image_entry() is called. But common/spl/spl.c is not omap-specific so changes there are a concern.
Next, image_entry() is called with the argument being indirected an extra time: u32 boot_params_ptr_addr = (u32)&boot_params_ptr; image_entry((u32 *)boot_params_ptr_addr);
That extra level of indirection is never dealt with (on ARM anyway) and it ends up passing junk to u-boot. I've tested replacing those lines with: image_entry((u32 *)boot_params_ptr);
and that passes a correct address in r0 to lowlevel_init.S in u-boot.
--- u-boot ---
lowlevel_init.S only deals with pointers for boot_params. It does not *copy* the content of the boot_params struct. With the fixes above we get to u-boot with *the address in SRAM* of the SPL's boot_params struct stored in the first word of u-boot's boot_params struct. Here's logging showing what I have working to this point:
U-Boot SPL 2013.04-rc1-00386-g1d3dea1-dirty (Apr 02 2013 - 17:21:36) OMAP4460 ES1.1 boot_params_ptr @40309a5c = 40309918 OMAP SD/MMC: 0 image entry point: 0xBF800000
U-Boot 2013.04-rc1-00386-g1d3dea1-dirty (Apr 02 2013 - 17:21:36)
<<< a debug %p print of & boot_params in board_mmc_init said bffdbf10 >>>
# md 0xbffdbf10 4 bffdbf10: 40309918 00000000 00000000 bffd297c
<<< 40309918 is the expected SPL &boot_params in SRAM as noted above >>>
# md 40309918 5 40309918: 4030d204 00000000 00000005 00000001 40309928: 00000001
That maps to the expected (omap_bootdevice == 5 being salient for me):
struct omap_boot_parameters { char *boot_message; unsigned int mem_boot_descriptor; unsigned char omap_bootdevice; unsigned char reset_reason; unsigned char ch_flags; };
That leaves me at an impasse. If we expect to have a struct in both contexts then something must copy its contents. That's not currently done.
Or we could have a struct in SPL but a *struct in u-boot. But that mixes the . and -> access syntax and there may be source that's agnostic to being in the SPL or u-boot.
The last idea I had was to make the SPL struct hidden and only use a pointer for access. That means both SPL and u-boot source could use the -> syntax.
The only places where I see this are: ./arch/arm/cpu/armv7/omap-common/boot-common.c: return (u32) (boot_params.omap_bootdevice); ./arch/arm/include/asm/arch-omap4/sys_proto.h:extern struct omap_boot_parameters boot_params; ./arch/arm/include/asm/arch-omap4/sys_proto.h: if ((boot_params.ch_flags) & (CH_FLAGS_CHSETTINGS)) ./arch/arm/include/asm/arch-omap5/sys_proto.h:extern struct omap_boot_parameters boot_params; ./arch/arm/include/asm/arch-omap5/sys_proto.h: if ((boot_params.ch_flags) & (CH_FLAGS_CHSETTINGS))
but I have no OMAP5 to test against. And I'm a little surprised that OMAP3 isn't in evidence here.
This has me wrapped around the axle so many times I need guidance regarding what's "the right way" to fix this.
Pointers welcome. (pun intended.)
-Mike Cashwell