Hello,
Please don't dont that. Linker scripts are per board (I have my own
bootloader) but also per chip, since the chip flash is not mapped the
same on all arm microcontrollers.
But you can provide templates and docs as references of the mandatory
sections that have to be included, and in what order.
Sébastien
Le 04/11/2022 à 21:12, Nathan Hartman a écrit :
On Fri, Nov 4, 2022 at 4:06 PM Nathan Hartman <hartman.nat...@gmail.com>
wrote:
On Fri, Nov 4, 2022 at 2:12 PM Carlos Sanchez
<carlossanc...@geotab.com.invalid> wrote:
It is exactly the same issue, I should have checked there, apologies for
duplicating. Shall we continue the discussion there?
In any case, I do not think it is such an uncommon scenario... We have
hit
it in our application (that is why we saw it). I mostly agree with the OP
of the original bug report, this is memory space and as such should be
allocated somewhere in the memory map instead of assuming there is free
space after BSS.
I *can* easily produce a patch for armv[678]-m (I have it already
implemented as a local patch in my Nuttx copy) and I have updated my
linker
script (same way as I updated QEMU test one). I can also patch all the
obvious ld files for other armv[678]-m targets. But I cannot test those (I
do not have the HW) and I might miss some ld file... and the problem is
that would render the build unusable (strictly speaking, a linker script
change should not be necessary as the stack can be anywhere in the memory,
but in other places of ARM-specific code it is assumed stack is contiguous
to heap space).
Shall I still prepare the patch? (Alan I know you already said but it will
take a bit of time to go through all the ld files so I want to confirm
before getting to it).
I think this makes sense. Build-time is a much better time to discover
that your image won't fit than wondering why the board won't boot and then
wasting time with debugging.
It is even more important to detect things like this at build time because
of automated testing like the pre-checks that run when PRs are opened.
Please feel free to ping me when the PR is opened and I'll help
review/test it.
I just had a thought. The linker scripts really should be per-arch, not
per-board, right?
Then again, a particular board might have a special requirement that needs
a custom linker script just for that board.
So maybe it would make more sense to migrate all the linker scripts to be
per-arch and add a Kconfig, e.g., a bool CONFIG_BOARD_LINKER_SCRIPT. If
true, then the board needs to provide its own ld.script; if false, we use
the default per-arch ld.script, and for most boards that should be adequate.
If this is done, then fixes like Carlos is discussing would take much less
work.
Thoughts?
Cheers
Nathan
