[PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible
dufault at hda.com
dufault at hda.com
Sat Jun 19 14:35:40 UTC 2021
I'm getting back to this as I have the HyperRAM working so I'm trying to set up appropriate linker settings.
> On Jun 10, 2021, at 01:43 , Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>
> The initial stack needs to be in an accessible memory area. Currently it is placed in this linker output section:
>
> .rtemsstack (NOLOAD) : ALIGN_WITH_INPUT {
> bsp_section_rtemsstack_begin = .;
> *(SORT_BY_ALIGNMENT (SORT_BY_NAME (.rtemsstack*)))
> bsp_section_rtemsstack_end = .;
> } > REGION_WORK AT > REGION_WORK
> bsp_section_rtemsstack_size = bsp_section_rtemsstack_end - bsp_section_rtemsstack_begin;
>
> Maybe we should place the .rtemsstack.interrupt input section into the REGION_VECTOR memory region.
On the "imxrt" REGION_VECTOR is in FLASH, at least ".vector' in the app I'm testing is at 0x6004653c which is in HyperFLASH.
In HyperRAM I see these regions allocated:
REGION_DATA: .rwbarrier
REGION_DATA_LOAD: .data, .rtemsrwset
REGION_BSS: .bss
REGION_WORK: .rtemsstack, .work
REGION_STACK: .stack
So I put REGION_WORK in the OCRAM to get .rtemsstack out of HyperRAM to get started. My application is now running out of HyperFLASH and HyperRAM though I'm sure I'll find issues.
- What's in "REGION_WORK"? Does that have anything to do with the RTEMS work space?
- What's the proper solution? I don't particularly want to redo my HyperRAM initialization to avoid using stack since I'm calling some NXP functions. I'd like a small amount of stack available in the context of bsp_start_hook_0() to set up the external RAM.
- What's going on in the shared ARM _start with bsp_start_hook_0_done and the branch to bsp_start_hook_0()?
Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to interception and tampering.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210619/5aab9399/attachment.bin>
More information about the devel
mailing list