On 01/08/23, Oliver Graute wrote:
On 14/02/23, Ying-Chun Liu (PaulLiu) wrote:
From: Marc Zyngier maz@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 maz@kernel.org Signed-off-by: Pierre-Clément Tosi ptosi@google.com [ Paul: pick from the Android tree. Fixup Pierre's commit. Rebase to the upstream ] Signed-off-by: Ying-Chun Liu (PaulLiu) paul.liu@linaro.org Cc: Tom Rini trini@konsulko.com Link: https://android.googlesource.com/platform/external/u-boot/+/96ad729cf4cab53b... Link: https://android.googlesource.com/platform/external/u-boot/+/6be9330601d81545...
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/#...
+Jason Liu +Peng Fan
Best Regards,
Oliver