1*4882a593SmuzhiyunIf you are experiencing hangups/data-aborts when trying to display a BMP image, 2*4882a593Smuzhiyunthe following might be relevant to your situation... 3*4882a593Smuzhiyun 4*4882a593SmuzhiyunSome architectures cannot handle unaligned memory accesses, and an attempt to 5*4882a593Smuzhiyunperform one will lead to a data abort. On such architectures it is necessary to 6*4882a593Smuzhiyunmake sure all data is properly aligned, and in many situations simply choosing 7*4882a593Smuzhiyuna 32 bit aligned address is enough to ensure proper alignment. This is not 8*4882a593Smuzhiyunalways the case when dealing with data that has an internal layout such as a 9*4882a593SmuzhiyunBMP image: 10*4882a593Smuzhiyun 11*4882a593SmuzhiyunBMP images have a header that starts with 2 byte-size fields followed by mostly 12*4882a593Smuzhiyun32 bit fields. The packed struct that represents this header can be seen below: 13*4882a593Smuzhiyun 14*4882a593Smuzhiyuntypedef struct bmp_header { 15*4882a593Smuzhiyun /* Header */ 16*4882a593Smuzhiyun char signature[2]; 17*4882a593Smuzhiyun __u32 file_size; 18*4882a593Smuzhiyun __u32 reserved; 19*4882a593Smuzhiyun __u32 data_offset; 20*4882a593Smuzhiyun ... etc 21*4882a593Smuzhiyun} __attribute__ ((packed)) bmp_header_t; 22*4882a593Smuzhiyun 23*4882a593SmuzhiyunWhen placed in an aligned address such as 0x80a00000, char signature offsets 24*4882a593Smuzhiyunthe __u32 fields into unaligned addresses (in our example 0x80a00002, 25*4882a593Smuzhiyun0x80a00006, and so on...). When these fields are accessed by U-Boot, a 32 bit 26*4882a593Smuzhiyunaccess is generated at a non-32-bit-aligned address, causing a data abort. 27*4882a593SmuzhiyunThe proper alignment for BMP images is therefore: 32-bit-aligned-address + 2. 28