[U-Boot] dcache issues with wandboard too (was: [PATCH V2 0/7] ARM: imx: Update Novena to DM/DT)

[Marek Vasut]

On 9/26/19 8:52 PM, Vagrant Cascadian wrote:
> On 2019-08-20, Vagrant Cascadian wrote:
>> On 2019-08-19, Marek Vasut wrote:
>>> On 6/4/19 9:06 AM, Vagrant Cascadian wrote:
>>>> On 2019-05-17, Marek Vasut wrote:
>>>>> Update Kosagi Novena to DM / DT and remove the warnings.
>> ...
>>>> I have two oustanding issues... with some files it sometimes fails to
>>>> load one or more from SATA:
>>>>
>>>> Retrieving file: /boot/initrd.img-5.0.0-trunk-armmp
>>>> 20077960 bytes read in 375 ms (51.1 MiB/s)
>>>> Retrieving file: /boot/vmlinuz-5.0.0-trunk-armmp
>>>> 4215296 bytes read in 40 ms (100.5 MiB/s)
>>>> append: root=UUID=9666ab0b-f932-4e2f-95d7-0e96a12a4540 ro quiet
>>>> Retrieving file: /usr/lib/linux-image-5.0.0-trunk-armmp/imx6q-novena.dtb
>>>> CACHE: Misaligned operation at range [fafb5398, fafb6398]
>>>> CACHE: Misaligned operation at range [fafb5398, fafb6398]
>>>> ERROR: v7_outer_cache_inval_range - start address is not aligned -
>>>> 0xfafb5398
>>>> ERROR: v7_outer_cache_inval_range - stop address is not aligned -
>>>> 0xfafb6398
>>>> invalid extent block
>>>>
>>>> It then falls back to one of the other kernels (using the extlinux.conf
>>>> parsing) and succeeds. It consistantly gets a cache/alignment error with
>>>> this specific file. A bit-for-bit identical .dtb loaded from another
>>>> path works just fine. Older versions of u-boot boot this fine. Would
>>>> some particular EXT4 flag possibly be causing issues?
>>>
>>> I don't know. Do you still run into this with u-boot/master ?
>>
>> Still occurring with 2019.10-rc2. Haven't tested with master yet.
>>
>> Using "dcache off" before booting still outputs the CACHE and ERROR
>> messages, but does successfully boot.
> 
> Also seeing this problem with wandboard solo with 2019.10-rc4 booting
> from microSD. Haven't retested with novena recently.
> 
> Setting CONFIG_SYS_DCACHE_OFF=y avoids the need to manually type "dcache
> off" ... though obviously doesn't address the real problem.

Can you debug it further or prepare a reproducible testcase ?