[U-Boot] [PATCH 5/5] cm-t35: add support for loading splash image from NAND

[Nikita Kiryanov]

On 12/26/2012 04:27 PM, Jeroen Hofstee wrote:
> Hello Nikita,
>
> On 12/25/2012 09:56 AM, Nikita Kiryanov wrote:
>>
>>> fyi, I noticed that my board compiled with gcc 4.7.3 from ELDK 5.3 will
>>> trap if the bitmap is not aligned. Aligned is a bit tricky though
>>> since the
>>> bitmap has the signature, e.g. "BM" prepended and is thereafter 32 bit
>>> aligned (or at least combined fields of 32 bits). In my case
>>> displaying the
>>> bitmap now only works when loaded to an aligned address - 2. Since
>>> you accept the value from the user, which has no ability to restore
>>> it once
>>> set "incorrectly", you might want to check the load address (well
>>> obviously
>>> only if it is a problem in your case as well).
>>
>> Thanks for verifying this issue. I did encounter it during testing, but
>> I assumed it to be a compiler problem because it worked when compiling
>> with a different version.
>>
>> Loading to aligned address - 2 works for me as well when compiling with
>> the problematic compiler, but this is strange to me. Isn't the "packed"
>> attribute that is applied to bmp_header_t supposed to prevent these
>> types of problems by effectively forcing the compiler to assume byte
>> alignment?
> Not per definition, while the pack does place most members at unaligned
> addresses, it does not control if the data can be loaded from it. Since the
> 4.7+ compilers by default assume that the chip does support unaligned
> accesses, it just generates ldr instruction to get the uint32_t members
> (and thus trap on this mcu). Older versions (or 4.7 with
> -mno-unaligned-access)
> will generate byte fetches due to the pack since it assumes the chip does
> not support unaligned accesses.
>
> So when compiled with a older compiler the bitmap could be loaded anywhere.
> With 4.7+ it is faster but needs to be aligned (in a bit weird manner).

Hmm... Then this means that lcd.c is similarly broken; it makes the same
accesses and the same assumptions about the load address.

Personally, I don't like the idea that board users should be aware of
the architecture's capabilities or the internal structure of BMP files
in order to select a correct load address, so requiring them to load it
to aligned address - 2 really irks me.

README.arm-unaligned-accesses does list standard compliance as a
possible reason for allowing emulated unaligned accesses, and the
format of the BMP header is certainly a standard of the BMP file format,
so I wonder if this constitutes a good reason to allow emulated
unaligned accesses for lcd.c?

Barring that, we should at least protect lcd.c from this issue by
making some sort of check for affected targets, or maybe limit the
possible values for splashimage... This issue makes it way too easy
to accidentally break the boot process in a way that's hard to recover
from.

>
> Regards,
> Jeroen
>
>
>


-- 
Regards,
Nikita.