Open martinomburajr opened 3 years ago
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @therealprof (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.
I’m not a maintainer, so take what I have to say with a grain of salt and it really is just a question, not necessarily my point of view.
The assumption is that we have no idea what MCU is being targeted when a user runs cargo generate
and the user must update the linker script themselves. So, should this be “fixed” at all?
I think there’s a very good argument that qemu should work out of the box. I’m just raising the question.
I think we should probably just stub the memory.x
values out and add some comments about the need for the developer to set them? There's no telling what they should be on random chips, which I think is what this crate is about?
Changes the default
FLASH : ORIGIN
to start at0x08000000
for the LM3S6965 as the original value of0x00000000
does not work when runningarm-none-eabi-gdb -q target/thumbv7em-none-eabihf/debug/examples/hello
See #102
Closes #102