[U-Boot] [PATCH] mtd: nand: mxs: fix cache alignment for cache lines >32

[Stefan Agner]

On 2016-08-03 12:08, Simon Glass wrote:
> Hi Fabio,
> 
> On 3 August 2016 at 12:44, Fabio Estevam <festevam at gmail.com> wrote:
>> Hi Simon,
>>
>> On Wed, Aug 3, 2016 at 3:35 PM, Simon Glass <sjg at chromium.org> wrote:
>>
>>> Actually I think these are bugs and should be fixed. In this case,
>>> from what I can tell netboot_common() should cache-align the size in
>>> the call to:
>>>
>>> /* flush cache */
>>> flush_cache(load_addr, size);
>>
>> Do you mean like this?
>>
>> --- a/cmd/net.c
>> +++ b/cmd/net.c
>> @@ -244,6 +244,8 @@ static int netboot_common(enum proto_t proto, cmd_tbl_t *cmd
>>         }
>>
>>         /* flush cache */
>> +       load_addr &= ~(CONFIG_SYS_CACHELINE_SIZE - 1);
>> +       size = ALIGN(size, CONFIG_SYS_CACHELINE_SIZE);
>>         flush_cache(load_addr, size);
>>
>>         bootstage_mark(BOOTSTAGE_ID_NET_LOADED);
>>
>> This makes the net warnings go away.
>>
>> There is still this one that I am seeing:
>>
>> Kernel image @ 0x80800000 [ 0x000000 - 0x6fea70 ]
>> ## Flattened Device Tree blob at 83000000
>>    Booting using the fdt blob at 0x83000000
>>    Using Device Tree in place at 83000000, end 83009c5d
>>
>> Starting kernel ...
>>
>> CACHE: Misaligned operation at range [00900000, 00900529]
>> [    0.000000] Booting Linux on physical CPU 0x0
>>
>> Any ideas where it may come from?
> 
> Not really...maybe boot_ramdisk_high()?
> 
> It's clearly pretty late in the process.

That looks like a SRAM address, and it is used for the secure stuff for
instance (CONFIG_ARMV7_SECURE_BASE).

I bet its from relocate_secure_section in arch/arm/cpu/armv7/virt-v7.c.

Will send out a patch for that.

--
Stefan