Aw: Re: debugging crash for arm64

[Frank Wunderlich]

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 at infinera.com>
> An: "Frank Wunderlich" <frank-w at public-files.de>, "u-boot at lists.denx.de" <u-boot at 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 at lists.denx.de> on behalf of Frank Wunderlich <frank-w at public-files.de>
> Sent: 08 December 2021 12:12
> To: u-boot at 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.readthedocs.io%2Fen%2Flatest%2Fdevelop%2Fcrash_dumps.html&data=04%7C01%7Cjoakim.tjernlund%40infinera.com%7C59463e6ea58d41f0ca9008d9ba3b9a99%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C1%7C637745587442544318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2PrM0CxcISTGINRz2DvLtMXB0UWow0x%2Bl0y58JkpkK0%3D&reserved=0
>
> 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.google.com%2Fdrive%2Ffolders%2F10rJbjWNdkYTA_pjnfXEADIZO-7yo4ZhC%3Fusp%3Dsharing&data=04%7C01%7Cjoakim.tjernlund%40infinera.com%7C59463e6ea58d41f0ca9008d9ba3b9a99%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C1%7C637745587442544318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZTv1TcijNfXF7Ft2TG0hcw0MGTyFQvF9X2XeWlO2gxk%3D&reserved=0
>
> regards Frank
>
>