Linker origin address

[MabezDev]

Hi,

I am working on a project kind of similar to your monotron for my dissertation (a 'smart watch'), I would like to be able to run apps on my watch so I was wondering if you could answer a couple of questions:

• Firstly in the linker script for the apps you set the origin to ORIGIN = 0x20000DF4, As far As I can tell the monotron just loads the binary into RAM, converts the first 4 bytes into a function pointer and executes the rest of the app, so does this address have any meaning or is it just a random value?

• Secondly, Is there any particular reason the apps are not written in Rust?

[MabezDev]

Ah okay I think I've figured out why the address is relevant let app_addr = unsafe { &APPLICATION_RAM as *const _ } as usize; in monotron prints the address of the start of the application buffer, I guess you are just manually setting the address in the link script to that?

[thejpster]

That's right, 0x2000_0DF4 is the address of APPLICATION_RAM. I should probably munge the linker script so it's fixed at 0x2000_0000 and doesn't move around as I add global variables to the ROM.

The only reason there's no Rust userland is that the C userland was easier, so I did it first. In principle a Rust userland is perfectly possible, and on the list of things to do. See https://github.com/thejpster/monotron/issues/6

[MabezDev]

I'm currently trying to get a linker script to do just that, here's what I've got so far:

MEMORY
{
  FLASH : ORIGIN = 0x8000000, LENGTH = 256K 
  RAM : ORIGIN = 0x20000000, LENGTH = 32K
  APPDATA: ORIGIN = 0x20008000, LENGTH = 32K
}

...

SECTIONS
{
    .appspace :
    {
        KEEP(*(.appspace));
    } > APPDATA
}

then in rust I just have:

#[link_section = ".appspace"]
static mut APPLICATION_RAM: [u8; 24 * 1024] = [0u8; 24 * 1024];

But at the moment I am getting

note: rust-lld: error: section '.appspace' will not fit in region 'APPDATA': overflowed by 18446744073306832896 bytes

Anyway thanks for answer my questions, If I figure it out I'll be sure to submit some PR's so monotron can do the same :).

[MabezDev]

With the help of adamgrieg I got the custom linker sections working for my project, the basic gist is that the custom sections have to be included after the link.x file produced from cortex-m-rt.

Moving my custom section into a new .x file and including link.x at the top like so:

INCLUDE link.x

SECTIONS
{   
  .app_section :
  {
    KEEP(*(.app_section.data));
  } > APPDATA
}

and changing .cargo/config linker file:

"-C", "link-arg=-Tapp_link.x", # this was "-C", "link-arg=-Tlink.x",

now produces a binary where the APPLICATION RAM is at a fixed address.

You can see example here. You may recognise some of the code, as I have cannibalised it from monotron. Hope this helps.

[thejpster]

I had a thought, which might make this all simpler. Why don't I set the SRAM size on Monotron to 8192 bytes. I can then construct a slice::from_raw_parts(0x20002000, 24*1024) in the load routine (which is about the only time the OS ever needs the RAM). The linker address for applications is then fixed at 0x2000_2000.

[thejpster]

Oh and FYI https://github.com/thejpster/monotron/issues/6 is now closed :)

[MabezDev]

I think you are right, the faff required to do it in the linker script means it's probably just easier to use slice::from_raw_parts.

Oh and FYI thejpster/monotron#6 is now closed :)

Awesome, I'll check it out!

I guess I'll close this now too.