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.tjernl...@infinera.com> > An: "Frank Wunderlich" <fran...@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-boun...@lists.denx.de> on behalf of Frank Wunderlich > <fran...@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.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 > >