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

[Jeroen Hofstee <jeroen@myspectrum.nl>]

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).

Regards,
Jeroen