Revert "Fix data abort introduced by ef92ed4a."

This reverts commit 61a096499b72f82dd8efc782e30cfeb1a31ef400.

The original issue was caused by a new structure member which caused
bmp_args::buf to be unaligned for 2-byte reads. Enforcing that alignment
should be the faster fix. Aligning to cache (while at it) should
improve bmp loading times even more.

Change-Id: I58a2caaf08c0ce46e2fb9666de628a30a36ea5f4

1 files changed, 4 insertions, 2 deletions

diff --git a/apps/recorder/bmp.c b/apps/recorder/bmp.c
index 3e7356a500..e4eb588eb3 100644
--- a/apps/recorder/bmp.c
+++ b/apps/recorder/bmp.c
@@ -175,13 +175,15 @@ enum color_order {
 };
 
 struct bmp_args {
+    /* needs to be at least 2byte aligned for faster 16bit reads.
+     * but aligning to cache should be even faster */
+    unsigned char buf[BM_MAX_WIDTH * 4] CACHEALIGN_AT_LEAST_ATTR(2);
     int fd;
     short padded_width;
     short read_width;
     short width;
     short depth;
     enum color_order order;
-    unsigned char buf[BM_MAX_WIDTH * 4];
     struct uint8_rgb *palette;
 #if (LCD_DEPTH > 1 || (defined(HAVE_REMOTE_LCD) && LCD_REMOTE_DEPTH > 1)) && \
     defined(HAVE_BMP_SCALING) || defined(PLUGIN)
@@ -276,7 +278,7 @@ static unsigned int read_part_line(struct bmp_args *ba)
             break;
           case 15:
           case 16:
-            data = ibuf[0] | (ibuf[1]<<8);
+            data = letoh16(*(uint16_t*)ibuf);
             component = (data << 3) & 0xf8;
             component |= component >> 5;
             buf->blue = component;