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.hu...@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.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
