From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vagrant Cascadian Date: Tue, 20 Aug 2019 10:41:36 -0700 Subject: [U-Boot] [PATCH V2 0/7] ARM: imx: Update Novena to DM/DT In-Reply-To: <1a1d7404-e8d6-5908-6c90-c82e7da11141@denx.de> References: <20190517183220.25766-1-marex@denx.de> <87o93d25ju.fsf@yucca> <1a1d7404-e8d6-5908-6c90-c82e7da11141@denx.de> Message-ID: <87a7c3ka3z.fsf@ponder> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. >> 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 : [] lr : [] >> 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. > > Can you debug it ? I think some of this was due to the EFI stuff , which > I think was fixed since. Can you re-check that ? USB appears to be working fine with 2019.10-rc2. live well, vagrant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: