Hi Mark,
On Thu, 14 Jul 2022 at 19:09, Mark Rutland mark.rutland@arm.com wrote:
On Thu, Jul 14, 2022 at 02:06:28PM +0100, Mark Rutland wrote:
... and I've just reproduced the issue by running the script from a different directory, since apprarently the semihosting interface just grabs the file from the current directory.
I'm pretty sure this means that *something* is clobbering the Image early on during boot, and the semihisting loading happens to refresh it.
I had a go with my own kernel built from my arm64/traps/rework branch:
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/...
... and Naresh's config:
https://builds.tuxbuild.com/2BnQMpJj3kDTJXoCwd2pY5gW9CN/config
When *only* using the initial loading into memory, that blows up in stackdepot and with a subsequent bogus pointer dereference (full log below), and when loaded via semihosting that just works. Note that my kernel is based on the arm64 for-next/core branch, which itself is based on v5.19-rc3.
My failing kernel Image is ~47M, as is Naresh's original Image. When using smaller Images (as large as 43M so far), I don't see any issues.
I also note that if I enable KASAN_OUTLINE, the kernel is so big that it clobbers the DTB, and cannot be booted. So this looks liek a problem with tha arbitrary placement / limits chosen for U-Boot being too small, and this is not a kernel bug.
Now I have understood the reason.
Naresh, please can you fix your boot flow before reporting any further issues?
Yes.
This sort of corruption will manifest in a number of ways, and we need to rule that out for any other bug reports.
Any further reports I will do needful initial investigation.
- Naresh