-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
drivers: net: ot: Provide structure instance for HDLC RCP context #84227
drivers: net: ot: Provide structure instance for HDLC RCP context #84227
Conversation
Gentle ping on this issue .... |
Hello @lmajewski, There is no problem with the NET_DEVICE_DT_INST_DEFINE macro and the "No context data" field set to NULL as you can see with the previous call stack. I can understand the static ot_hdlc_rcp_ctx variable instantiation can change the mapping. But the ot_hdlc_rcp_ctx variable is not used in the hdlc_iface_init() function. Why the following code is not done ? Thanks |
@xavraz - Thanks for your input.
IMHO the issue is that you currently have a dereference to the area of memory starting from 0x0, which in case MIMXRT1020 is a valid one and has flash driver code necessary for XIP. As both
There is no instantiation - without this patch the
In the
It shall be (as it is now):
Is the With the I think that this approach is correct. |
@lmajewski , It would be better to change the comment /* No context data */, now. Proposal : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment should be updated /* No context data */
Without this patch the hdlc_iface_init() function assigns to ot_hdlc_rcp_context structure pointer (*ctx) value of 0, as in the NET_DEVICE_DT_INST_DEFINE() preprocessor macro the 'data' field is set to NULL. Afterwards, the ctx->iface is set to iface address passed to the function (as well as the ctx->ot_context is set). Writing those values to address 0x0 is catastrophic to for example mimxrt1020, which uses ITCM memory (mapped from 0x0) to store flash handling functions, as those are used to XIP code directly from SPI NOR memory (as mximxrt1020 doesn't have internal flash). In this particular case - the flash_flexspi_nor_erase() function is mapped (i.e. relocated) to ITCM's 0x0 address. Overwriting first 8 bytes of it causes the SoC to enter "Precise data bus error" exception. The fix is to define the static instance of struct ot_hdlc_rcp_context and pass its address to the NET_DEVICE_DT_INST_DEFINE() macro. As a result its storage is now in RAM, not ITCM. This issue has been discovered on UART based HDLC RCP communication, but as it also may be problematic on the NXP driver, this patch fixes it too. Signed-off-by: Lukasz Majewski <[email protected]>
23f8052
to
a47a5ba
Compare
Without this patch the hdlc_iface_init() function assigns to ot_hdlc_rcp_context structure pointer (*ctx) value of 0, as in the NET_DEVICE_DT_INST_DEFINE() preprocessor macro the 'data' field is set to NULL.
Afterwards, the ctx->iface is set to iface address passed to the function (as well as the ctx->ot_context is set).
Writing those values to address 0x0 is catastrophic to for example mimxrt1020, which uses ITCM memory (mapped from 0x0) to store flash handling functions, as those are used to XIP code directly from SPI NOR memory (as mximxrt1020 doesn't have internal flash).
In this particular case - the flash_flexspi_nor_erase() function is mapped (i.e. relocated) to ITCM's 0x0 address. Overwriting first 8 bytes of it causes the SoC to enter "Precise data bus error" exception.
The fix is to define the static instance of struct ot_hdlc_rcp_context and pass its address to the NET_DEVICE_DT_INST_DEFINE() macro. As a result its storage is now in RAM, not ITCM.
This issue has been discovered on UART based HDLC RCP communication, but as it also may be problematic on the NXP driver, this patch fixes it too.