You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Tim <Ti...@JTi.uk.com.INVALID> on 2021/06/07 16:22:20 UTC
Memory locations
This is probably not really a NuttX question per se, but it relates to
getting the MCAN interface for a sama5d2 to work properly. And you are all
such knowledgable and helpful people :)
The MCAN controllers assume the base address of the message ram is at
0x200000+offsets. 0x200000 is the internal SRAM whereas everything else is
in DDR from 0x2000000. I will readily confess that this side of programming
is my very weakest!!
I will, I believe, need to declare - place - MCAN related structures such
that they (or at least some elements of them) are in SRAM.
Is that possible? "CONFIG_MM_REGIONS" related maybe?
What does the internal SRAM get used for as the system.map file lists
nothing there at all.
Or have I got it wrong and this isn't the way to sort it - perhaps the
processor DMA "matrix" stuff (hope not - don't understand the datasheet
section on this at all!)?
Thanks!
Tim.
Re: Memory locations
Posted by TimH <Ti...@JTi.uk.com.INVALID>.
On 07/06/2021 17:22, Tim wrote:
> This is probably not really a NuttX question per se, but it relates to
> getting the MCAN interface for a sama5d2 to work properly. And you are all
> such knowledgable and helpful people :)
>
>
>
> The MCAN controllers assume the base address of the message ram is at
> 0x200000+offsets. 0x200000 is the internal SRAM whereas everything else is
> in DDR from 0x2000000. I will readily confess that this side of
> programming
> is my very weakest!!
>
>
>
> I will, I believe, need to declare - place - MCAN related structures such
> that they (or at least some elements of them) are in SRAM.
>
>
>
> Is that possible? "CONFIG_MM_REGIONS" related maybe?
>
>
>
> What does the internal SRAM get used for as the system.map file lists
> nothing there at all.
>
>
>
> Or have I got it wrong and this isn't the way to sort it - perhaps the
> processor DMA "matrix" stuff (hope not - don't understand the datasheet
> section on this at all!)?
>
>
>
>
>
> Thanks!
>
>
>
> Tim.
>
>
>
That's some excellent guidance, thanks Nathan - lots of reading/learning
needed! I have started playing with the .ld file but haven't seen the
message buffer address change as yet; need to learn more about the
syntax and/or making sure the build picks up the changes to the board's
.ld file.
Then I can worry about things overlapping.
--
JT Innovations Ltd., Unit 23 Tradecroft Industrial Estate, Wide Street,
Portland, Dorset, DT5 2LN, UK Company number 7619086 VAT Registration GB
111 7906 35
Re: Memory locations
Posted by Tim Hardisty <Ti...@JTi.uk.com.INVALID>.
On 07/06/2021 20:45, Gregory Nutt wrote:
>
>>> I will, I believe, need to declare - place - MCAN related structures
>>> such
>>> that they (or at least some elements of them) are in SRAM.
>>>
> You will need to exercise care. SRAM (called isram in the linker
> scripts) is already used for other things including the MMU page table:
> https://github.com/patacongo/incubator-nuttx/blob/master/boards/arm/sama5/sama5d2-xult/scripts/dramboot.ld#L21
>
>
> The first 112Kb should be available, however, unless the board logic
> uses that too.
>
>
Thanks Greg - needs no more than 4kbyte. Just got to understand linker
scripts now lol and will check for any board logic usage there (there's
none that I've set up for my board, at least)
Re: Memory locations
Posted by Gregory Nutt <sp...@gmail.com>.
>> I will, I believe, need to declare - place - MCAN related structures such
>> that they (or at least some elements of them) are in SRAM.
>>
You will need to exercise care. SRAM (called isram in the linker
scripts) is already used for other things including the MMU page table:
https://github.com/patacongo/incubator-nuttx/blob/master/boards/arm/sama5/sama5d2-xult/scripts/dramboot.ld#L21
The first 112Kb should be available, however, unless the board logic
uses that too.
Re: Memory locations
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hello,
The correct syntax is:
.isramdata (NOLOAD) : /*<- this is the segment name in the output,
NOLOAD means that this segment is not to be initialized, like BSS, but
the linker alread knows that BSS is NOLOAD*/
{
*(.isramdata) /*<- this is the input sections from the
relocatable object files*/
} > isram
If you dont add names between the braces, no symbol from object files
get included in this segment.
And you should not initialize the variable declaration.
Sebastien
Le 08/06/2021 à 13:23, Tim Hardisty a écrit :
> I have added this to my linker script (and other variations on that
> theme, all of which compile OK with no warnings or errors)
>
> .isramdata :
> {
> } > isram
>
> and declared
>
> static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
> __attribute__((section(".isramdata"))) = {0};
> But it does not place the array in isram :(
Re: Memory locations
Posted by Tim Hardisty <Ti...@JTi.uk.com.INVALID>.
Thanks, but still no cigar :(
I have tried:
.isramdata_reserve (NOLOAD) :
{
*(.isramdata)
. = ALIGN(4);
_isramdata_heap_start = ABSOLUTE(.);
} > isram
and also just
.isramdata(NOLOAD) :
{
*(.isramdata)
} > isram
along with trying
staticuint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
aligned_data(MCAN_ALIGN) locate_data(".isramdata");
where MCAN_ALIGN is ARMV7A_DCACHE_LINESIZE, which is 32
or
static uint32_t g_mcan0_msgram[MCAN0_MSGRAM_WORDS] __attribute__
((section (".isramdata")));
and all methods still report this as in SDRAM not ISRAM
On 08/06/2021 13:33, David Sidrane wrote:
> Here is a working example.
>
>
> https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32h7/stm32_spi.c#L715-L716
>
> https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld#L179-L184
>
> You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram
>
> David
>
> -----Original Message-----
> From: Tim Hardisty [mailto:TimH@JTi.uk.com]
> Sent: Tuesday, June 08, 2021 4:23 AM
> To: dev@nuttx.apache.org
> Subject: Re: Memory locations
>
>
> On 07/06/2021 19:06, Nathan Hartman wrote:
>> On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:
>>> I will, I believe, need to declare - place - MCAN related structures such
>>> that they (or at least some elements of them) are in SRAM.
>>>
>> Yes. It is possible. It is done by adding attributes in the code which
>> tell the compiler that an object should be located at a particular
>> address or section.
> I have added this to my linker script (and other variations on that
> theme, all of which compile OK with no warnings or errors)
>
> .isramdata :
> {
> } > isram
>
> and declared
>
> static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
> __attribute__((section(".isramdata"))) = {0};
> But it does not place the array in isram :(
> system.map states: 20053fc4 D g_mcan0_msgram
> which is confirmed by the debugger and an info debug message
> Is there anything overruling this? Or a silly mistake, given my
> inexperience with linker scripts?
> Any guidance much appreciated!
Re: Memory locations
Posted by Sara da Cunha Monteiro de Souza <sa...@gmail.com>.
Hi Tim,
I am not a linker script expert neither.
But I'll let here a helpful link that helped me a lot:
https://interrupt.memfault.com/blog/how-to-write-linker-scripts-for-firmware
Em ter., 8 de jun. de 2021 às 10:19, Sebastien Lorquet <se...@lorquet.fr>
escreveu:
> what I would check here (just a live tought process)
>
> * check that the ld file is actually used (ld file is pointed by main
> Make.defs IIRC) (easy: just add garbage in it and verify build actually
> breaks)
>
> * check that the driver source with the definition is being recompiled
>
> * check that the object file that contains the isram based definition
> actually shows the use of the new section
>
> * make distclean, restart with a fresh build tree, rebuild all
>
> * reboot machine if possible (im not joking)
>
> Seems obvious, but sometimes bugs are hiding where we're assuming
> they're not
>
> Sebastien
>
> Le 08/06/2021 à 15:12, Tim Hardisty a écrit :
> > Thanks, but still no cigar :(
> >
> > I have tried:
> >
> > .isramdata_reserve (NOLOAD) :
> > {
> > *(.isramdata)
> > . = ALIGN(4);
> > _isramdata_heap_start = ABSOLUTE(.);
> > } > isram
> >
> > and also just
> >
> > .isramdata(NOLOAD) :
> > {
> > *(.isramdata)
> > } > isram
> >
> > along with trying
> >
> > staticuint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
> > aligned_data(MCAN_ALIGN) locate_data(".isramdata");
> > where MCAN_ALIGN is ARMV7A_DCACHE_LINESIZE, which is 32
> > or
> > static uint32_t g_mcan0_msgram[MCAN0_MSGRAM_WORDS] __attribute__
> > ((section (".isramdata")));
> > and all methods still report this as in SDRAM not ISRAM
> > On 08/06/2021 13:33, David Sidrane wrote:
> >> Here is a working example.
> >>
> >>
> >>
> https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32h7/stm32_spi.c#L715-L716
> >>
> >>
> >>
> https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld#L179-L184
> >>
> >>
> >> You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram
> >>
> >> David
> >>
> >> -----Original Message-----
> >> From: Tim Hardisty [mailto:TimH@JTi.uk.com]
> >> Sent: Tuesday, June 08, 2021 4:23 AM
> >> To: dev@nuttx.apache.org
> >> Subject: Re: Memory locations
> >>
> >>
> >> On 07/06/2021 19:06, Nathan Hartman wrote:
> >>> On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:
> >>>> I will, I believe, need to declare - place - MCAN related
> >>>> structures such
> >>>> that they (or at least some elements of them) are in SRAM.
> >>>>
> >>> Yes. It is possible. It is done by adding attributes in the code which
> >>> tell the compiler that an object should be located at a particular
> >>> address or section.
> >> I have added this to my linker script (and other variations on that
> >> theme, all of which compile OK with no warnings or errors)
> >>
> >> .isramdata :
> >> {
> >> } > isram
> >>
> >> and declared
> >>
> >> static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
> >> __attribute__((section(".isramdata"))) = {0};
> >> But it does not place the array in isram :(
> >> system.map states: 20053fc4 D g_mcan0_msgram
> >> which is confirmed by the debugger and an info debug message
> >> Is there anything overruling this? Or a silly mistake, given my
> >> inexperience with linker scripts?
> >> Any guidance much appreciated!
> >
>
RE: Memory locations
Posted by Tim <Ti...@JTi.uk.com.INVALID>.
Thanks for everyone's help on this. All working now.
It transpires the msgram can be in SDRAM not just in ISRAM so the solution is much more like the samV71 using cached memory, but it is handled a little differently in a few places of course.
No thanks AT ALL to the Atmel datasheet which says: "The MSBs [bits 31:16] of the CAN Message RAM for CAN0 and CAN1 are configured in 0x00200000". I took "in" to mean "as". The statement makes even less sense anyway, as they are actually configured in a Special Function Register which is not referenced in the MCAN section at all...and default to 0x200020 in actual fact! So, much time was wasted :(
But boy have I learned a lot these last few weeks LOL.
Re: Memory locations
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Jun 8, 2021 at 9:34 AM Tim Hardisty <Ti...@jti.uk.com.invalid> wrote:
>
>
> On 08/06/2021 14:18, Sebastien Lorquet wrote:
> > what I would check here (just a live thought process)
> >
> > * check that the ld file is actually used (ld file is pointed by main
> > Make.defs IIRC) (easy: just add garbage in it and verify build actually
> > breaks)
> >
>
> You, sir, have earned the cigar! Garbage added, didn't complain...lulled
> into a false sense of security because VScode coloured it all so nicely
> as *it* had found the declarations in *a* linker script no problem at
> all, just not the right one.
I never *ever* trust any IDE's or editor's syntax coloring!! They
interpret the project using their own built-in logic and that can and
does sometimes produce different results than the actual build system.
Glad you found it :-)
Nathan
Re: Memory locations
Posted by Tim Hardisty <Ti...@JTi.uk.com.INVALID>.
On 08/06/2021 14:18, Sebastien Lorquet wrote:
> what I would check here (just a live thought process)
>
> * check that the ld file is actually used (ld file is pointed by main
> Make.defs IIRC) (easy: just add garbage in it and verify build actually
> breaks)
>
You, sir, have earned the cigar! Garbage added, didn't complain...lulled
into a false sense of security because VScode coloured it all so nicely
as *it* had found the declarations in *a* linker script no problem at
all, just not the right one.
It's using uboot.ld not dramboot.ld and I was editing the latter. Doh!
Complete idiot!!!
Thank you all who helped me out for your patience!
Re: Memory locations
Posted by Sebastien Lorquet <se...@lorquet.fr>.
what I would check here (just a live tought process)
* check that the ld file is actually used (ld file is pointed by main
Make.defs IIRC) (easy: just add garbage in it and verify build actually
breaks)
* check that the driver source with the definition is being recompiled
* check that the object file that contains the isram based definition
actually shows the use of the new section
* make distclean, restart with a fresh build tree, rebuild all
* reboot machine if possible (im not joking)
Seems obvious, but sometimes bugs are hiding where we're assuming
they're not
Sebastien
Le 08/06/2021 à 15:12, Tim Hardisty a écrit :
> Thanks, but still no cigar :(
>
> I have tried:
>
> .isramdata_reserve (NOLOAD) :
> {
> *(.isramdata)
> . = ALIGN(4);
> _isramdata_heap_start = ABSOLUTE(.);
> } > isram
>
> and also just
>
> .isramdata(NOLOAD) :
> {
> *(.isramdata)
> } > isram
>
> along with trying
>
> staticuint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
> aligned_data(MCAN_ALIGN) locate_data(".isramdata");
> where MCAN_ALIGN is ARMV7A_DCACHE_LINESIZE, which is 32
> or
> static uint32_t g_mcan0_msgram[MCAN0_MSGRAM_WORDS] __attribute__
> ((section (".isramdata")));
> and all methods still report this as in SDRAM not ISRAM
> On 08/06/2021 13:33, David Sidrane wrote:
>> Here is a working example.
>>
>>
>> https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32h7/stm32_spi.c#L715-L716
>>
>>
>> https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld#L179-L184
>>
>>
>> You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram
>>
>> David
>>
>> -----Original Message-----
>> From: Tim Hardisty [mailto:TimH@JTi.uk.com]
>> Sent: Tuesday, June 08, 2021 4:23 AM
>> To: dev@nuttx.apache.org
>> Subject: Re: Memory locations
>>
>>
>> On 07/06/2021 19:06, Nathan Hartman wrote:
>>> On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:
>>>> I will, I believe, need to declare - place - MCAN related
>>>> structures such
>>>> that they (or at least some elements of them) are in SRAM.
>>>>
>>> Yes. It is possible. It is done by adding attributes in the code which
>>> tell the compiler that an object should be located at a particular
>>> address or section.
>> I have added this to my linker script (and other variations on that
>> theme, all of which compile OK with no warnings or errors)
>>
>> .isramdata :
>> {
>> } > isram
>>
>> and declared
>>
>> static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
>> __attribute__((section(".isramdata"))) = {0};
>> But it does not place the array in isram :(
>> system.map states: 20053fc4 D g_mcan0_msgram
>> which is confirmed by the debugger and an info debug message
>> Is there anything overruling this? Or a silly mistake, given my
>> inexperience with linker scripts?
>> Any guidance much appreciated!
>
Re: Memory locations
Posted by Tim Hardisty <Ti...@JTi.uk.com.INVALID>.
Thanks, but still no cigar :(
I have tried:
.isramdata_reserve (NOLOAD) :
{
*(.isramdata)
. = ALIGN(4);
_isramdata_heap_start = ABSOLUTE(.);
} > isram
and also just
.isramdata(NOLOAD) :
{
*(.isramdata)
} > isram
along with trying
staticuint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
aligned_data(MCAN_ALIGN) locate_data(".isramdata");
where MCAN_ALIGN is ARMV7A_DCACHE_LINESIZE, which is 32
or
static uint32_t g_mcan0_msgram[MCAN0_MSGRAM_WORDS] __attribute__
((section (".isramdata")));
and all methods still report this as in SDRAM not ISRAM
On 08/06/2021 13:33, David Sidrane wrote:
> Here is a working example.
>
>
> https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32h7/stm32_spi.c#L715-L716
>
> https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld#L179-L184
>
> You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram
>
> David
>
> -----Original Message-----
> From: Tim Hardisty [mailto:TimH@JTi.uk.com]
> Sent: Tuesday, June 08, 2021 4:23 AM
> To: dev@nuttx.apache.org
> Subject: Re: Memory locations
>
>
> On 07/06/2021 19:06, Nathan Hartman wrote:
>> On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:
>>> I will, I believe, need to declare - place - MCAN related structures such
>>> that they (or at least some elements of them) are in SRAM.
>>>
>> Yes. It is possible. It is done by adding attributes in the code which
>> tell the compiler that an object should be located at a particular
>> address or section.
> I have added this to my linker script (and other variations on that
> theme, all of which compile OK with no warnings or errors)
>
> .isramdata :
> {
> } > isram
>
> and declared
>
> static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
> __attribute__((section(".isramdata"))) = {0};
> But it does not place the array in isram :(
> system.map states: 20053fc4 D g_mcan0_msgram
> which is confirmed by the debugger and an info debug message
> Is there anything overruling this? Or a silly mistake, given my
> inexperience with linker scripts?
> Any guidance much appreciated!
RE: Memory locations
Posted by David Sidrane <Da...@nscdg.com>.
Here is a working example.
https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32h7/stm32_spi.c#L715-L716
https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld#L179-L184
You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram
David
-----Original Message-----
From: Tim Hardisty [mailto:TimH@JTi.uk.com.INVALID]
Sent: Tuesday, June 08, 2021 4:23 AM
To: dev@nuttx.apache.org
Subject: Re: Memory locations
On 07/06/2021 19:06, Nathan Hartman wrote:
> On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:
>> I will, I believe, need to declare - place - MCAN related structures such
>> that they (or at least some elements of them) are in SRAM.
>>
> Yes. It is possible. It is done by adding attributes in the code which
> tell the compiler that an object should be located at a particular
> address or section.
I have added this to my linker script (and other variations on that
theme, all of which compile OK with no warnings or errors)
.isramdata :
{
} > isram
and declared
static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
__attribute__((section(".isramdata"))) = {0};
But it does not place the array in isram :(
system.map states: 20053fc4 D g_mcan0_msgram
which is confirmed by the debugger and an info debug message
Is there anything overruling this? Or a silly mistake, given my
inexperience with linker scripts?
Any guidance much appreciated!
Re: Memory locations
Posted by Tim Hardisty <Ti...@JTi.uk.com.INVALID>.
On 07/06/2021 19:06, Nathan Hartman wrote:
> On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:
>> I will, I believe, need to declare - place - MCAN related structures such
>> that they (or at least some elements of them) are in SRAM.
>>
> Yes. It is possible. It is done by adding attributes in the code which
> tell the compiler that an object should be located at a particular
> address or section.
I have added this to my linker script (and other variations on that
theme, all of which compile OK with no warnings or errors)
.isramdata :
{
} > isram
and declared
static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
__attribute__((section(".isramdata"))) = {0};
But it does not place the array in isram :(
system.map states: 20053fc4 D g_mcan0_msgram
which is confirmed by the debugger and an info debug message
Is there anything overruling this? Or a silly mistake, given my
inexperience with linker scripts?
Any guidance much appreciated!
Re: Memory locations
Posted by Nathan Hartman <ha...@gmail.com>.
On Mon, Jun 7, 2021 at 12:24 PM Tim <Ti...@jti.uk.com.invalid> wrote:
>
> This is probably not really a NuttX question per se, but it relates to
> getting the MCAN interface for a sama5d2 to work properly. And you are all
> such knowledgable and helpful people :)
>
>
>
> The MCAN controllers assume the base address of the message ram is at
> 0x200000+offsets. 0x200000 is the internal SRAM whereas everything else is
> in DDR from 0x2000000. I will readily confess that this side of programming
> is my very weakest!!
>
>
>
> I will, I believe, need to declare - place - MCAN related structures such
> that they (or at least some elements of them) are in SRAM.
>
>
>
> Is that possible? "CONFIG_MM_REGIONS" related maybe?
Yes. It is possible. It is done by adding attributes in the code which
tell the compiler that an object should be located at a particular
address or section. If in a section, then the section needs to be
declared in the linker script.
See the docstring of gran_initialize() in mm/mm_gran/mm_graninit.c for
an explanation.
This StackOverflow question (and answers) might be helpful:
https://stackoverflow.com/questions/18347122/attribute-sectionname-usage
Be mindful of making sure that nothing will overlap the same area of
memory. For an example where I ran into that kind of gotcha:
https://github.com/apache/incubator-nuttx/pull/3198
and the discussion linked from there:
https://lists.apache.org/thread.html/recf2bb9043f8c9f53c10917e2adb2ec64fe35dc5e6f9a695a7ac6ecc%40%3Cdev.nuttx.apache.org%3E
Don't know whether you need to be concerned with CONFIG_MM_REGIONS or not.
Hope this helps!
Nathan