On 27 July 2015 21:57:14 CEST, 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?
Well, well. You got us into some ruff terrain right there. Remember I have some other alignment patches awaiting acceptance (e.g U-Boot's MTD and most possibly other subsystems are deeply broken in that respect) but even with those I failed booting a kernel loaded from UBIFS so I started having my doubts whether or not this is truly possible without bouncing. At least Tegra's MMC driver just bounces as well.
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?
Good question. I believe this I took straight from the MMC driver but will double check it again for a v3.