I am looking for a custom linker sample as I am reading about the [custom boot loader]( libDaisy: Getting Started - Daisy Bootloader (electro-smith.github.io)) and it notes:
For a starting point, you can look through the linkers provided in libDaisy’s
core folder. Non-bootloader programs running on internal flash are linked with the
STM32H750IB_flash.lds script, while the other two
.lds scripts handle their respective configurations. Right now, the Daisy bootloader will only accept QSPI and SRAM as valid locations for programs, so custom linkers must place the
.text sections in these regions.
It wasn’t clear to me what I would put in in these sections. For example if I have an LED.cpp file that creates an LED.o file, then what would I put in one of the sections if i wanted to have the LED be placed into QSPI?
For others that may end up reading this later, I found this article: Mastering the GNU linker script. I’m still working through it, but so far it has been helpful as I continue to work through this.
I’m sorry I couldn’t reply to you earlier, but I’m glad you found a helpful article. Thank you for sharing
@Takumi_Ogata , @Corvus_Prudens ,
I was wondering do either of you know if the custom linker script and/or attribute macro to assign an entire object to a diffrent location in memory?
Example: I have created an AudioDescription class that is bassed off of the WavPlayer and I’d like to allocate the entire runtime and data to either the flash locaiton and/or the qspi if possible.
Any thoughts on how that might be done?
Note: I am running the SRAM build here.
Thank you for any ideas you may have on this.
Example: I have a fully contained AudioDesc.o that hodls all of the elements
Is this class intended to be mutable? If it’s anything besides const data, it won’t make much sense to put it in non-writeable areas like QSPI.
Good point - I do have a fair amount of static data in the class, but it is not all static data. For example I have a number of lookup tables for audio files. I plan to add a base set of audio files in that space in the future. But for the active running code, I plan to put the audio buffers in SDRAM (future work).
Thanks for the observation though… I should have noticed that.