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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
