[U-Boot] [PATCH V2 0/7] ARM: imx: Update Novena to DM/DT

[Marek Vasut]

On 6/6/19 7:17 PM, Vagrant Cascadian wrote:
> On 2019-06-04, Vagrant Cascadian wrote:
>> On 2019-05-17, Marek Vasut wrote:
> 
> Retried with a build from:
> 
>   https://github.com/marex/u-boot-imx/tree/imx-dm
>   commit:7a381bb7edfd43aefc1dbfea6d574234ef9d7771
> 
> Which contains the two patchsets needed.
> 
> 
>> 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?
>>
>> Several other kernel+initrd+dtb combinations work fine.
> 
> Running "dcache off" before booting still produces the warnings/errors,
> but actually does boot successfully. Of course, it's much slower.

Well, someone needs to debug this :-)

>> The second issue is still using one out of four exposed USB ports fails
>> and resets the board:
>>
>> load usb 0:1 $kernel_addr_r misc/Binaries/linux/Image
>> data abort
>> pc : [<fefbb67a>]          lr : [<fefbb0fd>]
>> reloc pc : [<1783367a>]    lr : [<178330fd>]
>> sp : faf7c6e8  ip : 00000003     fp : 00000005
>> r10: faf8b200  r9 : faf87ea0     r8 : 00000001
>> r7 : faf8b2c0  r6 : f9f7a040     r5 : faf7c710  r4 : 00000038
>> r3 : 0000006d  r2 : f9f7a0a3     r1 : faf8b32c  r0 : f9f7a09f
>> Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
>> Code: 4630fc5b 81f0e8bd e7d84606 bf082b2f (f822235c)
>> Resetting CPU ...
>>
>> The three other usb ports work just fine with the same USB stick and
>> file. All four ports work with 2019.01.
> 
> Got a bit-for-bit identical error on this one.
> 
> I was able to get the objdump output with the reloc pc value:
> 
>   $ arm-linux-gnueabihf-objdump -d u-boot | grep 178337aa
>   178337aa:       f822 3b02       strh.w  r3, [r2], #2
> 
> Hope that's helpful!

Not at all, it basically says "writing unknown value to unknown offset
in memory causes data abort". If you run ...objdump -lSD u-boot, you can
likely find more information in the dump and also where/why it crashes.

-- 
Best regards,
Marek Vasut