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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
