On Apr 3, 2013, at 1:56 AM, Albert ARIBAUD albert.u.boot@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@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