Add Neotron Pico compatible linker script.

Author: thejpster

README.md

@@ -22,6 +22,19 @@ This OS is a work in progress. We intend to support:
 Your board will need an appropriate Neotron BIOS installed, and you need to have OpenOCD running for your particular board. You also need to set the linker 
 arguments so you link the binary to suit the memory available on your system.
 
+### Build Instructions for the Neotron Pico
+
+The Neotron Pico has some special memory requirements - in particular, the
+flash lives at `0x1000_0000` and not `0x0000_0000`. There is 1920 KiB of
+flash, and 240 KiB of RAM available.
+
+```
+$ git clone https://github.com/neotron-compute/Neotron-OS.git
+$ cd Neotron-OS
+$ git submodule update --init
+$ RUSTFLAGS="-C link-arg=-Tneotron-os-pico.ld" cargo build --release --target=thumbv6m-none-eabi
+```
+
 ### Build Instructions for 256K RAM systems
 
 Systems which reserve the second 512 KiB of Flash and first 256 KiB of SRAM

neotron-os-pico.ld

@@ -0,0 +1,157 @@
+/* # Developer notes
+
+- Symbols that start with a double underscore (__) are considered "private"
+
+- Symbols that start with a single underscore (_) are considered "semi-public"; they can be
+  overridden in a user linker script, but should not be referred from user code (e.g. `extern "C" {
+  static mut __sbss }`).
+
+- `EXTERN` forces the linker to keep a symbol in the final binary. We use this to make sure a
+  symbol if not dropped if it appears in or near the front of the linker arguments and "it's not
+  needed" by any of the preceding objects (linker arguments)
+
+- `PROVIDE` is used to provide default values that can be overridden by a user linker script
+
+- On alignment: it's important for correctness that the VMA boundaries of both .bss and .data *and*
+  the LMA of .data are all 4-byte aligned. These alignments are assumed by the RAM initialization
+  routine. There's also a second benefit: 4-byte aligned boundaries means that you won't see
+  "Address (..) is out of bounds" in the disassembly produced by `objdump`.
+*/
+
+/* Provides information about the memory layout of the device */
+MEMORY
+{
+    /* The BIOS gets the first 128 KiB of Flash, leaving 1920 KiB for the OS */
+    FLASH (rx)  : ORIGIN = 0x10020000, LENGTH = 0x1E0000
+    /*
+     * The RP2040 has 256 KiB of SRAM striped across four banks (for high
+     * performance), plus a fifth bank containing another 8 KiB of RAM. The
+     * BIOS is at the top of the high-performance RAM. We get the lower part.
+     */
+    RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 0x3C000
+    /* The SDRAM holds the LCD framebuffers */
+}
+
+/* # Entry point = what the BIOS calls to start the OS */
+ENTRY(entry_point);
+EXTERN(__RESET_VECTOR);
+
+/* # Sections */
+SECTIONS
+{
+
+  /* ## Sections in FLASH */
+  .entry_point ORIGIN(FLASH) :
+  {
+      KEEP(*(.entry_point))
+  } > FLASH
+
+  PROVIDE(_stext = ADDR(.entry_point) + SIZEOF(.entry_point));
+
+  /* ### .text */
+  .text _stext :
+  {
+    *(.text .text.*);
+    *(.HardFaultTrampoline);
+    *(.HardFault.*);
+  } > FLASH
+
+  /* ### .rodata */
+  .rodata : ALIGN(4)
+  {
+    *(.rodata .rodata.*);
+
+    /* 4-byte align the end (VMA) of this section.
+       This is required by LLD to ensure the LMA of the following .data
+       section will have the correct alignment. */
+    . = ALIGN(4);
+  } > FLASH
+
+  /* ## Sections in RAM */
+  /* ### .data */
+  .data : ALIGN(4)
+  {
+    . = ALIGN(4);
+    __sdata = .;
+    *(.data .data.*);
+    . = ALIGN(4); /* 4-byte align the end (VMA) of this section */
+    __edata = .;
+  } > RAM AT > FLASH
+
+  /* LMA of .data */
+  __sidata = LOADADDR(.data);
+
+  /* ### .bss */
+  .bss : ALIGN(4)
+  {
+    . = ALIGN(4);
+    __sbss = .;
+    *(.bss .bss.*);
+    . = ALIGN(4); /* 4-byte align the end (VMA) of this section */
+    __ebss = .;
+  } > RAM
+
+  /* ### .uninit */
+  .uninit (NOLOAD) : ALIGN(4)
+  {
+    . = ALIGN(4);
+    *(.uninit .uninit.*);
+    . = ALIGN(4);
+  } > RAM
+
+  /* Place the heap right after `.uninit` */
+  . = ALIGN(4);
+  __sheap = .;
+
+  /* ## .got */
+  /* Dynamic relocations are unsupported. This section is only used to detect relocatable code in
+     the input files and raise an error if relocatable code is found */
+  .got (NOLOAD) :
+  {
+    KEEP(*(.got .got.*));
+  }
+
+  /* ## Discarded sections */
+  /DISCARD/ :
+  {
+    /* Unused exception related info that only wastes space */
+    *(.ARM.exidx);
+    *(.ARM.exidx.*);
+    *(.ARM.extab.*);
+  }
+}
+
+/* Do not exceed this mark in the error messages below                                    | */
+/* # Alignment checks */
+ASSERT(ORIGIN(FLASH) % 4 == 0, "
+ERROR(cortex-m-rt): the start of the FLASH region must be 4-byte aligned");
+
+ASSERT(ORIGIN(RAM) % 4 == 0, "
+ERROR(cortex-m-rt): the start of the RAM region must be 4-byte aligned");
+
+ASSERT(__sdata % 4 == 0 && __edata % 4 == 0, "
+BUG(cortex-m-rt): .data is not 4-byte aligned");
+
+ASSERT(__sidata % 4 == 0, "
+BUG(cortex-m-rt): the LMA of .data is not 4-byte aligned");
+
+ASSERT(__sbss % 4 == 0 && __ebss % 4 == 0, "
+BUG(cortex-m-rt): .bss is not 4-byte aligned");
+
+ASSERT(__sheap % 4 == 0, "
+BUG(cortex-m-rt): start of .heap is not 4-byte aligned");
+
+/* # Position checks */
+
+/* ## .text */
+ASSERT(_stext + SIZEOF(.text) < ORIGIN(FLASH) + LENGTH(FLASH), "
+ERROR(cortex-m-rt): The .text section must be placed inside the FLASH memory.
+Set _stext to an address smaller than 'ORIGIN(FLASH) + LENGTH(FLASH)'");
+
+/* # Other checks */
+ASSERT(SIZEOF(.got) == 0, "
+ERROR(cortex-m-rt): .got section detected in the input object files
+Dynamic relocations are not supported. If you are linking to C code compiled using
+the 'cc' crate then modify your build script to compile the C code _without_
+the -fPIC flag. See the documentation of the `cc::Build.pic` method for details.");
+/* Do not exceed this mark in the error messages above                                    | */