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