search

ARM-software / tf-issues

Issue tracking for the ARM Trusted Firmware project
37 stars 16 forks source link

BL3-1 per-cpu exception stack is in an odd "data" section #70

Closed athoelke closed 10 years ago

athoelke commented 10 years ago

Presumably this stack should be in the same section as the per-cpu runtime stacks: tzfw_coherent_mem rather than the data section that is not explicitly referenced in the link script.

See: https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl31/aarch64/runtime_exceptions.S#L447 https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/common/aarch64/platform_helpers.S#L150

tixy commented 10 years ago

Don't we only need to use tzfw_coherent_mem if coherent memory is required, i.e. may be used before and after the MMU is enabled? Looking at how the exception stack is setup, I don't believe it's required anywhere near early startup code.

As to data section not being mentioned in linker scripts, it would be caught by the catch-all *(COMMON) line, but explicitly using .bss would be clearer. Or exception_stacks if we want to give it it's own name.

I thought of suggesting it's own section which isn't zero initialised to save a tiny amount of boot time, but being paranoid, I would personally always plump for initialised memory for everything.

tixy commented 10 years ago

On Wed, 2014-03-26 at 10:41 -0700, danh-arm wrote:

Closed #70 via ARM-software/arm-trusted-firmware@d8b07aa03f209b6a8143816537105edc63553b8e.

Still not sure that was the best solution, but I guess this can be revisited as part of the work for coherent stacks removal during boot? (https://github.com/ARM-software/tf-issues/issues/103)

danh-arm commented 10 years ago

Agree this can be improved as part of #103. This issue was about fixing the clearly "wrong" behaviour.