intel: adsp: fix firmware image in IMR overwriting

[lyakh]

The IMR is used by the firmware to hold its own copy for hot-booting and for an "L3 heap," used for slow large allocations like loadable libraries. The beginning of the L3 heap is currently hard-coded and now the firmware has grown too large to fit into the dedicated area so that it gets overwritten by heap allocations. This is a critical bug that needs an urgent solution, for which we increase the offset, but a real fix must calculate the L3 heap offset automatically.

BugLink: thesofproject/sof#9308

[tmleman]

During debugging, I found another thing. At this line in boot.c, IMRSTACK points to IMR_BOOT_LDR_MANIFEST_BASE (0xa1042000), shouldn't it rather be IMR_BOOT_LDR_STACK_BASE?

[lyakh]

During debugging, I found another thing. At this line in boot.c, IMRSTACK points to IMR_BOOT_LDR_MANIFEST_BASE (0xa1042000), shouldn't it rather be IMR_BOOT_LDR_STACK_BASE?

@tmleman yes, I stumbled over that too, but I don't know what the correct fix there should be. I think IMRSTACK should point to the top of the stack, so it might coincide with the beginning of some area, but there it doesn't seem apparent to me that the area below the manifest is reserved for the stack? I traced back that stack == manifest idea to some 2.5 year old commit 692770a . But back then we probably didn't re-use the firmware IMR image for resuming, so now we have to revisit that design... And at least to document it well. But I'd really like to know what is in that area of IMR below the manifest? If there's really nothing then maybe we have to free it or use it in some meaningful way.

[lyakh]

A link to an explanation of the IMR memory layout and how parts of it get corrupted thesofproject/sof#9308 (comment)

[andyross]

Fix is sound. Agreed that the the tradition of manually-typed layout offsets in SOF (well, "SOF-derived code") has been stretched past the breaking point and needs a rework.

[marc-hb]

I just filed new issue #76247 to discuss and track a longer term solution.