[U-Boot] OMAP (4) boot_params

[Michael Cashwell]

On Apr 3, 2013, at 1:56 AM, Albert ARIBAUD <albert.u.boot at aribaud.net> wrote:

> (please wrap your line around 70 chars max)

I've never understood why this is useful. It's poor on both large
computer screens (wastes space and forces extra vertical scrolling)
AND on small screens like handheld devices (because the arbitrary width is
limit still too wide).

Your MUA seems to have handled the quoted-printable content transfer
encoding I sent (since your quoted text had no tell tail = characters
at the end of each line). Why can't it wrap the text to whatever width
*you* want? Mine does (provided the message ISN'T hard-wrapped) and I
don't much like senders forcing the rendering on my devices to be done
in ways that are counter to my preferences.

Wouldn't it be better for readers to do what's best for each device?
Imagine someone on a tablet viewing email first in portrait mode and then
rotating to landscape. Why advocate forcing one or the other to have a
demonstrably poor user experience?

The MUA controls many other elements of the presentation. HTLM aside,
does the sender control what font face, size or color all recipients
must use to view the message? Of course not, and for good reason. I fail
to see why line width should be some magical special case.

So with all due respect, I can with greater legitimately turn your
admonition around and ask that you please update or configure your MUA
to handle your display preferences on your side.

> On Tue, 2 Apr 2013 18:39:17 -0400, Michael Cashwell
> <mboards at prograde.net> wrote:
> 
>> 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.
>> 
>> ...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.
> 
> If I'm not mistaken, lowlevel_init() is not supposed to use BSS at all,
> as the C runtime has not been initialized yet -- precisely, the BSS
> clearing loop long after the cpu_init_crit() call belongs to the code
> that sets up this environment.

Yes, that was my thinking too. Surely clearing data after code has set
it can't be right.

> Besides, it seems like SPL does not jump directly to Linux but to
> U-Boot, so U-Boot itself should set up the boot params, not SPL, which
> can at best prepare and store values in static RAM not mapped as data
> or BSS in either SPL or U-Boot (this is normally done through GD).

OK, here we have an unfortunate name overloading. The boot_params here
is specifically an OMAP handoff from the CPU's internal boot ROM to SPL
and then from SPL to u-boot. (The same code paths are involved.) It's
totally unrelated to the the boot_params passed to the Linux kernel.

Since it's confusing maybe a renaming is called for as well.

Best regards,
-Mike