Mediatek DSP fixups #844
Open
Mediatek DSP fixups #844
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Yeah... how about a respin that after running |
The new directory structure in the upstream Cadence tarballs wasn't as compatible as I thought. Binutils will produce a working assembler, but only if it does NOT see the new xtensa-config.h (which was added in a path it doesn't look at). Also gcc ends up hitting the in-tree/non-overlayed xtensa-config.h and produces a big endian compiler! Don't be fancy. Move stuff around to match the older overlays exactly. Also add the "defs.h" inclusion as generated by make-overlay.sh, and rename the copy of xtensa-xtregs.c in gdbserver to .cc as required by current binutils and done by other sdk-ng overlays. And I'd forgotten the copy of core-isa.h for newlib (which SOF doesn't use, but should still be present in the SDK). Signed-off-by: Andy Ross <[email protected]> squashme defs.h
There is no "predicted branches" extension in any version of the Xtensa ISA reference I have. Newer versions of Cadence tooling have removed (and presumably deprecated) this symbol, but binutils still relies on seeing it (even just to evaluate to a zero to diable the feature). Really the proper fix would be to patch binutils upstream, but let's have compatible headers here first. Signed-off-by: Andy Ross <[email protected]>
The name of the rmap array changed in upstream bintuils commit
2b16913cdca2 ("gdb: make gdbarch_alloc take ownership of the tdep").
At the same time it seems like the xtensa_tdep definition (which
contra the filename is actually a C++ object definition and not a
function prototype!) moved into this file from elsewhere in binutils.
The xtensa_rmap symbol is only used by newer binutils versions than
the Zephyr SDK builds, but add an alias so it builds with upstream
crosstools-ng, and commit it here as a reference if we want to port
the other Xtensa overlays.
Signed-off-by: Andy Ross <[email protected]>
|
And I see we now have a build. And I can confirm it generates working binaries for all four devices with these two in-flight PRs applied: zephyrproject-rtos/zephyr#82350 Once those merge we can uncomment the test lines in the Github integration. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixed needed to get a real working toolchain out of the recently merged overlays. Not quite sure how I convinced myself that was going to work. My own builds with upstream ct-ng were doing OK, but it's possible it was confounded by a union of the two directory schemes (or maybe we're a little behind?).