Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle multiple RAM regions #3

Open
MathiasKoch opened this issue Sep 21, 2020 · 5 comments
Open

Handle multiple RAM regions #3

MathiasKoch opened this issue Sep 21, 2020 · 5 comments
Labels
difficulty: medium Somewhat difficult to solve priority: low status: needs design This feature needs design work to move forward type: enhancement New feature or request

Comments

@MathiasKoch
Copy link

Currently this only checks for overflows in single-ram region called RAM.

Eventually it would be awesome to support multi region layouts like:

MEMORY
{
    RAM             : org = 0x20000000, len = 96k      /* SRAM1 */
    RAM2            : org = 0x10000000, len = 32K      /* SRAM2 */
}

The "line-by-line" parser only looks for RAM: org = ..., but I am not sure if this is the actual blocker?

Also minor side issue;
This line:

bail!("MEMORY.RAM found after scanning linker scripts");

Should probably read MEMORY.RAM not found after scanning linker scripts ? Missing the not

@japaric
Copy link
Member

japaric commented Sep 21, 2020

Eventually it would be awesome to support multi region layouts like:

What kind of layout do you have in mind? For instance, if you place the stack in RAM2 and the rest of sections in RAM then already have stack overflow protection and flip-link should be a no-op.

This definitively seems doable but we need to list the potential arrangements of stack, static variables and heap. Also more than 2 RAM regions seems possible though I'm not sure cortex-m-rt supports that particularly well.

@japaric japaric added the type: enhancement New feature or request label Sep 21, 2020
@japaric
Copy link
Member

japaric commented Sep 21, 2020

if you place the stack in RAM2 and the rest of sections in RAM then already have stack overflow protection and flip-link should be a no-op.

if we rely solely on standard sections like .bss and .data we may miss the cases where the user puts a custom section (.my_section) in RAM2 -- that could result in a collision. Perhaps we should look at the addresses of symbols instead of at the sections in that (2 RAM regions) case?

@MathiasKoch
Copy link
Author

Ohh

You are totally right! I was waaay to fast on an early monday morning! Totally forgot we are only talking about stack. Please disregard this issue! Feel free to close.

@japaric
Copy link
Member

japaric commented Sep 21, 2020

I'm going to leave this open because I think we want to "support" at least the 2 RAM region configuration. By support I mean flip-link should not error and panic and it should produce a binary that won't result in memory corruption due to stack overflow (even if that means doing nothing = linking normally).
Also, I'm not sure what the behavior is in the 2 RAM regions case; that's an scenario I haven't really tested.

@MathiasKoch
Copy link
Author

In my case i am using both ram regions, but only for static queues and buffers:

#[init(None)]
#[link_section = ".ram2"]
res_queue: Option<ResQueue<AtatRxBufLen, consts::U5>>,
#[init(None)]
#[link_section = ".ram2"]
urc_queue: Option<UrcQueue<AtatRxBufLen, consts::U10>>,
#[init(None)]
#[link_section = ".ram2"]
com_queue: Option<ComQueue<consts::U3>>,

// Cellular Socket Buffer
#[init(None)]
#[link_section = ".ram2"]
socket_set: Option<SocketSet<consts::U2, consts::U2048>>,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty: medium Somewhat difficult to solve priority: low status: needs design This feature needs design work to move forward type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants