We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
riscv-rt
cortex-m-rt
I suggest adopting part of cortex-m-rt structure:
link.x
memory.x
In this way, PACs and BSPs would have to provide a memory.x linker file that defines the memory layout and regions.
End users would need to do something like RUSTFLAGS="-C link-arg=-Tlink.x when building binaries, regardless of the final target.
RUSTFLAGS="-C link-arg=-Tlink.x
I think the current riscv-rt approach is quite versatile and I don't see any advantage in limiting sections to FLASH and RAM.
__
I think it is a good idea to follow the same naming convention as in cortex-m-rt (__stext, __etext...).
__stext
__etext
The text was updated successfully, but these errors were encountered:
More information in #236
Sorry, something went wrong.
No branches or pull requests
I suggest adopting part of
cortex-m-rt
structure:Make
link.x
includememory.x
In this way, PACs and BSPs would have to provide a
memory.x
linker file that defines the memory layout and regions.End users would need to do something like
RUSTFLAGS="-C link-arg=-Tlink.x
when building binaries, regardless of the final target.Keep using region aliases
I think the current
riscv-rt
approach is quite versatile and I don't see any advantage in limiting sections to FLASH and RAM.Use
__
to define start and end of sectionsI think it is a good idea to follow the same naming convention as in
cortex-m-rt
(__stext
,__etext
...).The text was updated successfully, but these errors were encountered: