Rockbox

If you know which album art in particular was giving you trouble, or at least what was in the playlist when the crash occurred, and if you could attach it here or upload it somewhere, that would be a big help. Most problems I’ve seen so far have turned out to be related to the relative sizes of the WPS AA tag and the source bitmap - a few cases where things can go wrong have shown up since scaling was committed.

I’m attaching the .bmp from an album that I know exhibited the problems I mentioned. I’ll have to wait until I have some time to document my usage to provide more information.

   cover.bmp (33.1 KiB)

Surfi from Anythingbutipod just helped me with this exact problem. It seems that the problem lies in resizing the album art to an odd number. I fixed the problem with my theme by simply changing the resize size from 85 to 90.

I saw the same problem on my e200 real target.
“Data abort at 000322E8 (0)”

Steps to reproduce
(1) play with the attached “cover.bmp”(130×130) on cabbiev2 wps (120×120)
(2) select Free-State wps (%Cl|7|138|c75|c75|)
(3) can’t change wps and abort…

and this problem does not occur on e200 sim.
#I also saw the same problem on my ipod video real target.
#but the problem does not occur on ipod video sim.
#Something arm related issue?

So, I dumped my e200 binary with nm and objdump.
Please see the following info.

— $ arm-elf-nm rockbox.elf | sort
000320b0 T unload_wps_backdrop
000320c4 T show_main_backdrop
000320f8 T show_wps_backdrop
00032134 t scale_h_area_setup
00032174 t scale_h_area «< maybe this func (+0×174)
00032434 t scale_v_area
00032720 t scale_h_linear_setup

— $ arm-elf-objdump -SDlr app/recorder/resize.o
00000040 <scale_h_area>:
scale_h_area():
/home/idak/src/rockbox/svn/rockbox/apps/recorder/resize.c:116

/* horizontal area average scaler */
static bool scale_h_area(struct bitmap *bm, struct dim *src,

                       struct uint32_rgb *out_line,
                       struct scaler_context *ctx, bool accum)

{

40:   e92d4ff0        stmdb   sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr}
44:   e24dd028        sub     sp, sp, #40     ; 0x28
48:   e1a09000        mov     r9, r0
4c:   e58d1008        str     r1, [sp, #8]
50:   e58d2004        str     r2, [sp, #4]
54:   e1a06003        mov     r6, r3
58:   e5dd104c        ldrb    r1, [sp, #76]
5c:   e58d1000        str     r1, [sp]

(snip…)

/home/idak/src/rockbox/svn/rockbox/apps/recorder/resize.c:156

          rgbvalacc.g += rgbvaltmp.g * mul;

18c: e1a0e00b mov lr, fp
190: e02e8e90 mla lr, r0, lr, r8
/home/idak/src/rockbox/svn/rockbox/apps/recorder/resize.c:157

          rgbvalacc.b += rgbvaltmp.b * mul;

194: e1a0800c mov r8, ip
198: e0284890 mla r8, r0, r8, r4
/home/idak/src/rockbox/svn/rockbox/apps/recorder/resize.c:159

          /* round, divide, and either store or accumulate to output row */
          out_line[ox].r = (accum ? out_line[ox].r : 0) +

19c: e59da00c ldr sl, [sp, #12]
1a0: e08a308a add r3, sl, sl, lsl #1
1a4: e59db004 ldr fp, [sp, #4]
1a8: e08b1103 add r1, fp, r3, lsl #2
1ac: e59dc000 ldr ip, [sp]
1b0: e35c0000 cmp ip, #0 ; 0×0 1b4: 1591c000 ldrne ip, [r1] ««< here?
1b8: e5963004 ldr r3, [r6, #4]
1bc: e0823003 add r3, r2, r3
1c0: e5962000 ldr r2, [r6]
1c4: e08ba293 umull sl, fp, r3, r2
1c8: e08c300b add r3, ip, fp
1cc: e5813000 str r3, [r1]
/home/idak/src/rockbox/svn/rockbox/apps/recorder/resize.c:162

                           ((rgbvalacc.r + ctx->round) *
                           (uint64_t)ctx->divmul >> 32);
          out_line[ox].g = (accum ? out_line[ox].g : 0) +

1d0: e59db000 ldr fp, [sp]
1d4: e35b0000 cmp fp, #0 ; 0×0

Free-State is the following.
http://www.rockbox.org/twiki/bin/viewfile/Main/WpsSansaE200?rev=4;filename=Free-State-fixed.zip

   resize.objdump (157.9 KiB)

Akio: thanks for finding it. The load is guaranteed to be unaligned if both dimensions of the output size are odd, I’ve added an align_buffer to fix it. Should work as of r19439.