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" <[email protected]>
> An: "Frank Wunderlich" <[email protected]>, "[email protected]"
> <[email protected]>
> 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 <[email protected]> on behalf of Frank Wunderlich
> <[email protected]>
> Sent: 08 December 2021 12:12
> To: [email protected]
> 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
>
>
