[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