Aw: Re: debugging crash for arm64

8 Dec 2021


      Hi,
thanks for answer, but it seems it is there
arch/arm/mach-rockchip/rk3568/rk3568.c:50:		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
arch/arm/mach-rockchip/rk3568/rk3568.c:56:		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
arch/arm/mach-rockchip/rk3568/rk3568.c:63:		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
or is there a mem-region not defined? if yes which?
static struct mm_region rk3568_mem_map[] = {
    {
    	.virt = 0x0UL,
    	.phys = 0x0UL,
    	.size = 0xf0000000UL,
    	.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
    		 PTE_BLOCK_INNER_SHARE
    }, {
    	.virt = 0xf0000000UL,
    	.phys = 0xf0000000UL,
    	.size = 0x10000000UL,
    	.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
    		 PTE_BLOCK_NON_SHARE |
    		 PTE_BLOCK_PXN | PTE_BLOCK_UXN
    }, {
    	.virt = 0x300000000,
    	.phys = 0x300000000,
    	.size = 0x0c0c00000,
    	.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
    		 PTE_BLOCK_NON_SHARE |
    		 PTE_BLOCK_PXN | PTE_BLOCK_UXN
    }, {
    	/* List terminator */
    	0,
    }
};
struct mm_region *mem_map = rk3568_mem_map;
regards Frank
...
Gesendet: Mittwoch, 08. Dezember 2021 um 12:49 Uhr
Von: "Joakim Tjernlund" Joakim.Tjernlund@infinera.com
An: "Frank Wunderlich" frank-w@public-files.de, "u-boot@lists.denx.de" u-boot@lists.denx.de
Betreff: Re: debugging crash for arm64
Just had the same and you are probably missing to map that mem area to the MMU. grep for PTE_BLOCK_MEMTYPE in board
and you will see how to.
That said, I think the error msg in u-boot can be a bit better, some SEGV msg perhaps.
Jocke

From: U-Boot u-boot-bounces@lists.denx.de on behalf of Frank Wunderlich frank-w@public-files.de
Sent: 08 December 2021 12:12
To: u-boot@lists.denx.de
Subject: debugging crash for arm64
Hi,
i got a crash on uboot while running reset-command in rk3568 board (bananapi-r2 pro, currently not in upstream).
maybe a callback is missing (e.g. reset_cpu())??
i tried to analyse it using the documentation:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fu-boot.rea...
Resetting CPU ...
resetting ...
"Synchronous Abort" handler, esr 0x96000045
elr: 0000000000a25f78 lr : 0000000000a25f48 (reloc)
elr: 000000007ff94f78 lr : 000000007ff94f48
x0 : 00000000fdd20000 x1 : 0000000014000001
x2 : 000000000000fdb9 x3 : 000000007df5cd48
x4 : 000000007df4fe88 x5 : 000000007df5c710
x6 : 000000000000001a x7 : 000000007df459f0
x8 : 0000000000000001 x9 : 000000000000000c
x10: 00000000000186a0 x11: 00000000ffffffd0
x12: 0000000000000010 x13: 000000000001869f
x14: 000000007ff70158 x15: 0000000000000021
x16: 000000007ff94f2c x17: 0000000000000000
x18: 000000007df4fdd0 x19: 0000000000000000
x20: 0000000000000001 x21: 0000000000000000
x22: 000000007df5ddd0 x23: 0000000000000001
x24: 000000007ffe8800 x25: 0000000000000000
x26: 0000000000000000 x27: 0000000000000000
x28: 000000007df5e980 x29: 000000007df45990
Code: d65f03c0 d5033fbf b9400661 529d9502 (b8206822)
$ echo 'Code: d65f03c0 d5033fbf b9400661 529d9502 (b8206822)' |   CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 scripts/decodecode
Code: d65f03c0 d5033fbf b9400661 529d9502 (b8206822)
All code
========
   0:   d65f03c0        ret
   4:   d5033fbf        dmb     sy
   8:   b9400661        ldr     w1, [x19, #4]
   c:   529d9502        mov     w2, #0xeca8                     // #60584
  10:*  b8206822        str     w2, [x1, x0]            <-- trapping instruction
Code starting with the faulting instruction
0:   b8206822        str     w2, [x1, x0]
now i'm here
"Now lets use the locations provided by the elr and lr registers after subtracting the relocation offset to find out where in the code the crash occurred and from where it was invoked."
does that means that i have to subtract values of first 2 lines of trace?
0x7ff94f78 - 0x00a25f78 = 0x7F56F000
"File u-boot.map contains the memory layout of the U-Boot binary. Here we find these lines:"
this is not clear enough for me too...i did not found 0x7F56F000 in the file.
i expect to do anything with the address in the disassembled code (0xb8206822), but i do not know what :p
i've uploaded the matching u-boot.map and u-boot.dbg (output of objdump) here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrive.goog...
regards Frank