Update memory.x

[martinomburajr]

Changes the default FLASH : ORIGIN to start at 0x08000000 for the LM3S6965 as the original value of 0x00000000 does not work when running arm-none-eabi-gdb -q target/thumbv7em-none-eabihf/debug/examples/hello

See #102

Closes #102

[rust-highfive]

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.

[rubberduck203]

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.

[BartMassey]

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?