On 01/08/23, Oliver Graute wrote: > On 14/02/23, Ying-Chun Liu (PaulLiu) wrote: > > From: Marc Zyngier <m...@kernel.org> > > > > In the add_map() function, for each level it populates, it iterates from > > the root of the PT tree, making it ineficient if a mapping needs to occur > > past level 1. > > > > Instead, replace it with a recursive (and much simpler) algorithm > > that keeps the complexity as low as possible. With this, mapping > > 512GB at level 2 goes from several seconds down to not measurable > > on an A55 machine. > > > > We keep the block mappings at level 1 for now though. > > > > Signed-off-by: Marc Zyngier <m...@kernel.org> > > Signed-off-by: Pierre-Clément Tosi <pt...@google.com> > > [ Paul: pick from the Android tree. Fixup Pierre's commit. Rebase to the > > upstream ] > > Signed-off-by: Ying-Chun Liu (PaulLiu) <paul....@linaro.org> > > Cc: Tom Rini <tr...@konsulko.com> > > Link: > > https://android.googlesource.com/platform/external/u-boot/+/96ad729cf4cab53bdff8222bb3eb256f38b5c3a6 > > Link: > > https://android.googlesource.com/platform/external/u-boot/+/6be9330601d81545c7c941e3609f35bf68a09059 > > Hello Marc, > > this patch somehow broke the boot of my imx8qm board. I run into this > issue: > > U-Boot 2023.07-rc6-00004-g5527698481 (Aug 01 2023 - 10:10:52 +0200) > > Model: Advantech iMX8QM DMSSE20 > Board: DMS-SE20A1 8GB > Build: SCFW 549b1e18, SECO-FW c9de51c0, ATF 5782363 > Boot: USB > DRAM: 8 GiB > "Error" handler, esr 0xbf000000 > elr: 0000000080020938 lr : 00000000800209c8 (reloc) > elr: 00000000ffecf938 lr : 00000000ffecf9c8 > x0 : 0000000000000001 x1 : 0000000060000000 > x2 : 0000000010000000 x3 : 0000000000000002 > x4 : 0000000040000000 x5 : 0060000000000401 > x6 : 0000000000000800 x7 : 00000000fff44a60 > x8 : 0068000000000481 x9 : 0000000000000008 > x10: 000000000a200023 x11: 0000000000000002 > x12: 0000000000000002 x13: 0000000080095a00 > x14: 00000000ffffffff x15: 00000000ffecfd2c > x16: 000000008005454c x17: 0000000000000000 > x18: 00000000fd6afd50 x19: 000000000fe00000 > x20: 0000000000000000 x21: 0060000000000401 > x22: 0000000060200000 x23: 0000000000200000 > x24: 0000000040000808 x25: 00000000001fffff > x26: 0000000000000003 x27: 0000000060200000 > x28: 0000000000000002 x29: 00000000fd6ab110 > > Code: a94573fb a8c67bfd d65f03c0 b9418a40 (8a160334) > Resetting CPU ... > > resetting ... > SCI reboot > request............................................................................................................................................................................................................................ > > After some bisecting this patch poped up: > > 41e2787f5ec4249cb2e77a3ebd3c49035e3c6535 is the first bad commit > arm64: Reduce add_map() complexity > > After I reverted everything on top of this patch its booting again with > v2023.07 > > commit c1da6fdb5c239b432440721772d993e63cfdeb20 > armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present > > commit 836b8d4b205d2175b57cb9ef271e638b0c116e89 > arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present > > commit 6cdf6b7a340db4ddd008516181de7e08e3f8c213 > arm64: Use FEAT_HAFDBS to track dirty pages when available > > > Do you have any idea whats going on here?
Is this behavior somehow releated to the known Cache coherency issue on A53 Core on NXP imx8qm? https://lore.kernel.org/linux-arm-kernel/ZDflS%2FCnEx8iCspk@FVFF77S0Q05N/T/#mf733406e618244b0b21fd25077febd69b31b686e +Jason Liu +Peng Fan Best Regards, Oliver