frdm_k64f bus exception bug due to peculiar RAM configuration

[nashif]

Reported by Marcus Shawcroft:

The cortex-m linker script and associated configuration defines a single SRAM region in to which the linker maps all data sections.

The frdm_k64f defconfig defines 192KB of SRAM.

The K64F reference manual section 3.5.3.1 describes two SRAM banks, upper and lower, and specifically calls out that any misaligned memory access across the 0x20000000 boundary will fault.

The toolchain / linker is at liberty to place arbitrary objects across the 0x20000000 boundary. IFF an object is placed to straddle this boundary, and the compiler decides to make an unaligned access to the object then a bus exception will be thrown.

I've not constructed a test case to reproduce this, but it should be relatively straight forward.

This is a particularly unpleasant issue because subtle changes in a binary will either present or hide the issue and the probability that any given binary exhibits the issue is very small.

[The mbed folks ran into this issue a year or so ago, IIRC it was rather painful to diagnose, I can see by inspection that zephyr does not yet deal with this issue].

(Imported from Jira ZEP-1517)

[nashif]

by Kumar Gala:

Any idea on how the mbed guys solved this? Was it just via linker magic or something more painful?

[nashif]

by Johann Fischer:

Does it not concern to the other Cortex M4 MCUs? http://infocenter.arm.com/help/topic/com.arm.doc.ddi0439b/ch03s04s02.html

Is it relevant? : http://infocenter.arm.com/help/topic/com.arm.doc.ihi0046b/IHI0046B_ABI_Advisory_1.pdf

In RIOT-OS M4 will be linked with: https://github.com/RIOT-OS/RIOT/blob/master/cpu/cortexm_common/ldscripts/cortexm_base.ld https://github.com/RIOT-OS/RIOT/blob/master/cpu/k64f/ldscripts/mk64fn1m0vll12.ld

[nashif]

by Marcus Shawcroft:

The mbed-os linker script implements a partitioning of stuff into a data and a data_2 section, it isn't elegant by any stretch of the imagination. Here is a link:

https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/device/TOOLCHAIN_GCC_ARM/MK64FN1M0xxx12.ld#L71

The original mbed-os issue is over here The original mbed-os issue is here https://github.com/ARMmbed/target-kinetis-k64-gcc/issues/4

There is a related upstream binutils issue here https://sourceware.org/bugzilla/show_bug.cgi?id=14299 unfortunately that issue has languished since 2012.

[nashif]

by Marcus Shawcroft:

I don;t believe IHI0046B_ABI_Advisory_1 is relevant to this issue.

[nashif]

by Marcus Shawcroft:

It isn;t clear to me what the relevance of the riot link scripts are here, I've not studied them in detail but a quick glance suggests to me that they are exposed to this issue aswell.

[nashif]

by Johann Fischer:

Ok, I probably did not understand the bug description correctly. However, I presume it affects all Cortex-M4 MCUs.

[1] K64 RM: (3.5.3.1) SRAM sizes: Misaligned accesses across the 0x2000_0000 boundary are not supported in the ARM Cortex-M4 architecture.

[2] Cortex-M4 Technical Reference (3.4.3): "DCode accesses wrap within the region. For example, an unaligned halfword access to the last byte of Code space ( 0x1FFFFFFF ) is converted by the DCode interface into a byte access to 0x1FFFFFFF followed by a byte access to 0x00000000 ."

Is it [2] what you mean with the bug description?

[nashif]

by Maureen Helm:

The data and data_2 sections are what we do in MCUXpresso SDK too. I think the mbed solution may have come from the SDK, but not entirely sure of the history there. I don't know of any more elegant solutions

[nashif]

by Marcus Shawcroft:

Johann, my understanding of the TRM is that this issue will indeed affect any cortex-m4 platform where SRAM spans the 0x20000000 boundary.

[nashif]

by Mark Linkmeyer:

Correcting the priority field

[nashif]

by Mark Linkmeyer:

Maureen Helm , who should be the owner of this bug? I'd like to get it correctly assigned.

[nashif]

by Maureen Helm:

I'll take it, but I think we're at a loss right now for a proper solution.

[nashif]

by Marcus Shawcroft:

This proposal/RFC https://sourceware.org/ml/binutils/2017-02/msg00250.html on upstream binutils mailing list is intended to provide a long term robust solution to this issue.

[nashif]

by Maureen Helm:

Currently we are only using the upper SRAM starting at 0x2000_0000, therefore this issue will not occur. Leaving this issue open but reducing to low priority so we don't forget about it when we enable the lower SRAM.