diff options
author | 2023-10-10 14:33:42 +0000 | |
---|---|---|
committer | 2023-10-10 14:33:42 +0000 | |
commit | af1a266670d040d2f4083ff309d732d648afba2a (patch) | |
tree | 2fc46203448ddcc6f81546d379abfaeb323575e9 /roms/u-boot/doc/README.displaying-bmps | |
parent | e02cda008591317b1625707ff8e115a4841aa889 (diff) |
Change-Id: Iaf8d18082d3991dec7c0ebbea540f092188eb4ec
Diffstat (limited to 'roms/u-boot/doc/README.displaying-bmps')
-rw-r--r-- | roms/u-boot/doc/README.displaying-bmps | 27 |
1 files changed, 27 insertions, 0 deletions
diff --git a/roms/u-boot/doc/README.displaying-bmps b/roms/u-boot/doc/README.displaying-bmps new file mode 100644 index 000000000..331154166 --- /dev/null +++ b/roms/u-boot/doc/README.displaying-bmps @@ -0,0 +1,27 @@ +If you are experiencing hangups/data-aborts when trying to display a BMP image, +the following might be relevant to your situation... + +Some architectures cannot handle unaligned memory accesses, and an attempt to +perform one will lead to a data abort. On such architectures it is necessary to +make sure all data is properly aligned, and in many situations simply choosing +a 32 bit aligned address is enough to ensure proper alignment. This is not +always the case when dealing with data that has an internal layout such as a +BMP image: + +BMP images have a header that starts with 2 byte-size fields followed by mostly +32 bit fields. The packed struct that represents this header can be seen below: + +typedef struct bmp_header { + /* Header */ + char signature[2]; + __u32 file_size; + __u32 reserved; + __u32 data_offset; + ... etc +} __attribute__ ((packed)) bmp_header_t; + +When placed in an aligned address such as 0x80a00000, char signature offsets +the __u32 fields into unaligned addresses (in our example 0x80a00002, +0x80a00006, and so on...). When these fields are accessed by U-Boot, a 32 bit +access is generated at a non-32-bit-aligned address, causing a data abort. +The proper alignment for BMP images is therefore: 32-bit-aligned-address + 2. |