On Tue, 01 Aug 2023 09:53:52 +0100,
Oliver Graute <oliver.gra...@gmail.com> 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
SError.
> 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?
Not really. I can only tell you that your HW has generated a SError,
which is usually pretty fatal. There could be all sort of reasons why
this happen, such as mapping a piece of address space that you are not
supposed to access.
If the previous incarnation of the PT code was behaving in a better
way, the way to debug this is to dump both sets of page tables and
compare what they actually map, figuring out where things go wrong.
M.
--
Without deviation from the norm, progress is not possible.
