Hi Scott,
On 27 July 2015 at 13:57, Scott Wood scottwood@freescale.com wrote:
On Tue, 2015-07-21 at 00:35 +0200, Marcel Ziswiler wrote:
From: Marcel Ziswiler marcel.ziswiler@toradex.com
Integrate cache alignment bounce buffer to workaround issues as follows:
Loading file '/boot/zImage' to addr 0x01000000 with size 4499152 (0x0044a6d0)... ERROR: v7_dcache_inval_range - start address is not aligned - 0x1f7f0108 ERROR: v7_dcache_inval_range - stop address is not aligned - 0x1f7f1108 Done Kernel image @ 0x1000000 [ 0x000000 - 0x44a6d0 ]
Starting kernel ...
undefined instruction pc : [<005ff03c>] lr : [<0000800c>] sp : 0144b6e8 ip : 01000188 fp : 0144a6c8 r10: 00000000 r9 : 411fc090 r8 : 00000100 r7 : 00000cfb r6 : 0144a6d0 r5 : 00000000 r4 : 00008000 r3 : 0000000c r2 : 00000100 r1 : 00000cfb r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
Signed-off-by: Marcel Ziswiler marcel.ziswiler@toradex.com
Changes in v2: Migrated to using generic bounce buffer implementation as suggested by Simon.
I didn't see Simon's suggestion, but what is the general policy in U-Boot supposed to be for I/O alignment? Responsibility of the API user, or of the driver? Are there other drivers with the same problem?
MMC has it. I feel that in general we should be able to ask the higher-level systems to do the right thing and align their data. Otherwise it introduces inefficiencies into the stack. But at least if we do introduce this, we should use common infrastructure, hence my request.
writel(virt_to_phys(buf), &info->reg->data_block_ptr);
writel((u32)bbstate.bounce_buffer, &info->reg->data_block_ptr);Why are you converting usage of virt_to_phys() into a u32 cast?
-Scott
Regards, Simon