Skip to content

Conversation

@LaurentiuM1234
Copy link
Contributor

@LaurentiuM1234 LaurentiuM1234 commented Apr 10, 2024

Switch to using Zephyr logging on imx8 and imx8x to prepare for using native Zephyr drivers.

Cherry-picked from #8863

@LaurentiuM1234
Copy link
Contributor Author

LaurentiuM1234 commented Apr 10, 2024

@marc-hb seems like this commit is the cause for the win/linux compare failure from #8863.

EDIT btw, from your experience, do you happen to know what would cause differences between windows and linux builds?

@marc-hb
Copy link
Collaborator

marc-hb commented Apr 11, 2024

Same, previously seen disassembly difference in https://github.com/thesofproject/sof/actions/runs/8630426621?pr=9021 already observed in #8863

--- win/build-sof-staging/sof-info/imx8x/zephyr.lst	2024-04-10 19:30:27
+++ lin/build-sof-staging/sof-info/imx8x/zephyr.lst	2024-04-04 09:12:34
@@ -81134,6 +81134,12 @@
 92433b10:	833441                      	l32r	a4, 924147e0 <_stext+0x1598> (92413034 <s_lpuartClock>)
 92433b13:	a03340                      	addx4	a3, a3, a4
 92433b16:	03a8                          	l32i.n	a10, a3, 0
+ * @param name  Which clock to enable, see \ref clock_ip_name_t.
+ * @return true for success, false for failure.
+ */
+static inline bool CLOCK_EnableClock(clock_ip_name_t name)
+{
+    return CLOCK_EnableClockExt(name, 0);
 92433b18:	31e9                          	s32i.n	a14, a1, 12
 92433b1a:	00a0b2                      	movi	a11, 0
 92433b1d:	ffcfa5                      	call8	92433818 <CLOCK_EnableClockExt>

from your experience, do you happen to know what would cause differences between windows and linux builds?

I downloaded the files, did some inspection, jogged my memory and searched archives and I think I may have found something... Do you have any .. in some #include paths by any chance? We could have a situation similar to these:

So the inline C code seems correct in both cases, but for some reason the same zephyr-sdk/xtensa-...-objdump -S is "not as good" when running on Windows and can't find the source of the inline function CLOCK_EnableClock() when disassembling LPUART_Init()... even though both Linux and Windows find that same source earlier in the binary when disassembling mcux_ccm_on()!

There's one notable difference here: mcux_ccm_on() is located in Zephyr whereas LPUART_Init() is located in modules/hal/nxp! Which is why I'm suspecting #include paths?

I think the simple reason it is appearing now is because you're now enabling some lpuart in this commit.

@LaurentiuM1234
Copy link
Contributor Author

LaurentiuM1234 commented Apr 11, 2024

Interestingly enough this also seems to happen for 8ULP when we pull in the patch that enables LPUART. Results here: https://github.com/thesofproject/sof/actions/runs/8645734717/job/23703888439?pr=9029. @marc-hb would you mind pasting the diffs for that as well? Can't seem to be able to check it out in the CI job :(. Also, is there any other info in the CI job that may help with debugging this?

BTW, appreciate the info!

@marc-hb
Copy link
Collaborator

marc-hb commented Apr 11, 2024

Results here: https://github.com/thesofproject/sof/actions/runs/8645734717/job/23703888439?pr=9029. @marc-hb would you mind pasting the diffs for that as well? Can't seem to be able to check it out in the CI job :(.

Also, is there any other info in the CI job that may help with debugging this?

I've created new issue #9034 and answered there.

Switch to using Zephyr logging on imx8 and imx8x to
prepare for using native Zephyr drivers.

Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants