Date: Tue, 21 Sep 2021 16:45:51 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258467 --- Comment #7 from Klaus Küchemann <email@example.com> --- (In reply to Leandro Lupori from comment #6) yeah, but I`ll try your approach to copy the archsw-block before defsw in /stand/uboot/common/main.c tonight, because the previous loader.efi worked . (while aarch64 doesn't have problems with the new loader-changes) the problem with this machine is : Physical memory chunk(s): 0x80000000 - 0x27fffffff, 8192 MB (2097152 pages) Excluded memory regions: 0x80000000 - 0x8001ffff, 0 MB ( 32 pages) NoAlloc NoDump 0xf6600000 - 0xf70ecfff, 10 MB ( 2797 pages) NoAlloc Found 4 CPUs in the device tree Copyright (c) 1992-2021 The FreeBSD Project. ---- real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x0000000080020000 - 0x00000000f65fffff, 1985871872 bytes (484832 pages) 0x00000000f70ed000 - 0x000000027348dfff, 6379147264 bytes (1557409 pages) avail memory = 8337354752 (7951 MB) - every attempt(after u-boot) to access that regions results in panic but if the OS is once booted everything is O.K. everything in u-boot is O.K. since opensbi tells u-boot to exclude these regions. but it seems that no mechanism exists to tell loader.efi the protected memory parameters(while @mhorne made a patch for the booted OS as for opensbi) IIRC. since I don`t know other code in the loader-changes that could trigger the relocation-issue I hope your failure analysis is also valid for riscv...thanks -- You are receiving this mail because: You are the assignee for the bug.