[U-Boot] OMAP (4) boot_params

[Michael Cashwell]

On Apr 8, 2013, at 5:43 AM, Sricharan R <r.sricharan at ti.com> wrote:

>  The **only** reason for passing the boot_params from SPL to U-BOOT was
>  when somebody uses a CONFIGURATION HEADER + SPL + U-BOOT, which
>  was never a case. But the broken code that you pointed was trying to
>  help such a scenario. I guess nobody would have used this combination.

I think there is a much more common case that needs this information.

Consider a normal memory-boot (e.g.: not UART or USB). It goes like:

ROM -> SPL -> U-Boot -> Linux kernel+initrd

When there are multiple possible bootable busses/memories a decision must
be made at each step as to which to read from. The current behavior seems
broken because SPL and u-boot can come from one source while u-boot will
load linux from a different source.

I think, by default, the selected source should be consistent. My approach
for this is to decode boot_params.omap_bootdevice in board_mmc_init()
and call mmc_init() so the correct default bus is selected before any
"mmc read" commands (that don't specify a bus) execute.

I found that boot_params.omap_bootdevice (actually all of boot_params)
was always zero no matter what boot device had actually been used. This
was because of the .bss clearing.

>  save_boot_params ideally should not write in to either .data or .bss.
>  Because this would break a XIP kind of a boot. The only place where it can
>  write is the GD or some reserved SRAM area that is always 'writable'.
>  We did not have a XIP in OMAP4/5 and thus this went unnoticed.
> 
>  I will post a patch today to address this.

Great! I will look for this and track it.

Perhaps we need to add any missing fields to struct omap_boot_parameters, add
that whole struct added to an OMAP4/5 section in:

./arch/arm/include/asm/global_data.h:struct arch_global_data

since that's in struct global_data already.

The only hard part I see is that C structs are not directly accessible from
assembly code like save_boot_params and tracking the needed assembly offsets
manually is error prone. And of course, save_boot_params runs so early we
don't even have a stack setup yet.

One idea I was thinking about was to just save the r0 pointer somewhere
but defer the processing of it until after we're done with CRT setup. That
would get all this out of assembly code and into C code. Not only would the
bss clearing then already be done it's much cleaner to access structs from C.

Let me know if I can assist in any way.

Best regards,
-Michael Cashwell