[U-Boot] [PATCH v2 09/16] mtd/nand/tegra: alignment workaround

Marcel Ziswiler marcel at ziswiler.com
Tue Jul 28 03:55:46 CEST 2015



On 27 July 2015 21:57:14 CEST, Scott Wood <scottwood at freescale.com> wrote:
>On Tue, 2015-07-21 at 00:35 +0200, Marcel Ziswiler wrote:
>> From: Marcel Ziswiler <marcel.ziswiler at 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 at 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.


More information about the U-Boot mailing list