Closed MabezDev closed 5 years ago
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?
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
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 :).
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.
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.
Oh and FYI https://github.com/thejpster/monotron/issues/6 is now closed :)
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.
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?