I really don't see any simpler and more flexible way to define the memory
map than linker scripts.
This is the purpose of the script itself.
On the other hand though, I cannot argue against a tool that I haven't seen
yet...
In any case, I think that we agree that step no 1 is always the same.
The code must properly place everything to the correct region, so the
linker can produce the desired result.
That is, the heap definition shall change, and all "interesting" parts of
the memory shall be declared in an __attribute__((section(""))) way.
Στις Παρ, 26 Μαρ 2021 στις 7:32 μ.μ., ο/η Nathan Hartman <
hartman.nat...@gmail.com> έγραψε:
> On Fri, Mar 26, 2021 at 12:46 PM Fotis Panagiotopoulos
> <f.j.pa...@gmail.com> wrote:
> > Oh, sorry.
> > Attached again as .txt. Is it OK now?
>
> Yes, the files went through this time. Thanks! More below...
>
> > > A tool that takes the Kconfig + chip+ memorymap and make a linker
> include
> > > file and the config code for the heap may be the way to go.
> >
> > I am pretty sure that a "tool" will not be able to cover all use cases.
> > Over the years I had to make custom scripts to account for:
> > * Bootloaders
> > * Binary blops
> > * Firmware headers
> > * ROM files
> > * DMA buffers
> > * External memories
> > etc etc..
> >
> > Do you believe that a tool can be made that can handle everything?
>
> It is very annoying to have to do all of that, and error prone, and
> it's pretty awful when there's a potentially clobbering situation
> (like a heap allocation clobbering a DMA buffer) that might not
> manifest for hours or days in a running firmware. Could be very hard
> to debug.
>
> I like the idea of a tool that takes Kconfig settings and emits a
> correct linker script.
>
> Could a tool account for *all* of the above? And, you forgot to
> mention: Different toolchains with their own linker script dialect.
>
> I suppose that at first, it would not support all of that. It would
> probably start out supporting only a small subset of options, and then
> each user who has a different requirement would have to improve the
> tool, and hopefully open a PR so the rest of the community benefits
> from it.
>
> If we want to try this, I would recommend a Kconfig option
> CUSTOM_LINKER_SCRIPT. If set, the tool will not run, leaving your
> custom script in place.
>
> The good thing about such a tool: see for example at the nucleo-h743zi
> board. It has 5 different linker scripts and you have to choose the
> correct one(s), depending on flash, kernel, elf, etc. If a tool could
> generate the right one automatically, it would be harder work up front
> to create the tool, but then it would be much less work in maintenance
> later. Also it would be integrated with in-tree improvements so
> out-of-tree boards don't break every time we change something in the
> tree.
>
> Nathan
>
