The default linker script doesn't seem to use SRAM1 on the 9G20 for any purpose while running the program from SDRAM. Any ideas why?

In what context?

AT91BootStrap parks the stack there.
RomBoot only loads SRAM0 from the boot device.

A lot of the code examples are more generic in nature to permit their use across a broad range of SAM9 parts with disparate memory configurations.

Beyond the fact that adding it complicates things, there isn't any reason why you couldn't add it, or use it, in your specific application.

Generally you'd want to use the fast, single cycle, chip-ram for code and operations you want to be high performance. Using it for stacks, MMU/Page Tables, DMA buffers, USB/Ethernet/Video buffers, etc. offers the biggest benefits. In simple implementations such allocations would be defined statically, and not necessarily by the compiler/linker.

Thanks for the prompt reply.

I'm referring to the linker scripts for the 9G20 from at91lib 1.5 (at91lib\boards\at91sam9g20-ek\at91sam9g20\).
http://www.atmel.com/dyn/resources/prod ... _v8476.zip

norflash.lds places the BSS and stack(0x301000) on SRAM1, sram.lds places the BSS there and the stack at 0x304000 which looks like an unused memory location! (Figure 8-1 from AT91SAM9G20)
In later versions both of them do this. Any idea how this still works?

Irrespective of that, sdram.lds never seems to use the entire SRAM1. The only reason I see why SRAM1 wasn't used is that placing most sections in the SDRAM lifts the size limitation of the SRAM.

So I'm wondering if its possible in linker scripts to specify a section to be split between two memory areas? For example, how do I make my stack start at SRAM1 and let it overflow into SDRAM?

0x301000 is a legacy from the 9260, which had 4KB SRAMs

0x304000 is correct address for the 9G20 (top of SRAM1), remember the stack DESCENDS, the push pre-decrements.

The stack can't spill between memory regions, well at least not unless you virtualize them with the MMU.

That's true! I'll correct my linker scripts to the correct address.
I'd have to set up the page tables in the startup code to be able to make memory locations contiguous. I'd prefer setting up the MMU at a later stage to keep things flexible.

So apart from the stack, is it possible to spread another section across memories without remapping memories with virtual memory?

I'm more used to scatter files, GNU/GCC is less suited to embedded development. I'm not sure it's fluid enough to allow you to automatically span sparse memory regions, but the scripts should permit you to control where certain things go. ATMEL uses a certain style, other examples out there use a more complex style. It also assumes the stack just descends into the remaining space, with no real checks/limitations.

http://www.math.utah.edu/docs/info/ld_3.html

What you'd want to do is get the compiler/assembler to use different segment names (ie variants of .text, .data) and define which memory sections those go to in the linker script.

Alternatively, you should be able to manually steer specific object(s) in to specific sections.
{ afile.o bfile.o cfile.o }

The other consideration is that the ATMEL SAM9 designs assume a staged boot. The SRAMs work at boot time, but the SDRAM has to be initialized to your specific board, and the NAND, NOR and data flashes all have there specific unique characteristics. Thus creating a monolithic application that fill all possible memories at startup isn't exactly practical.

You could also statically allocate specific regions for certain tasks/stacks, or implement a dynamic memory allocation scheme to be aware of different regions, and speeds of RAM. The stack is typically use as a highly efficient allocator of local variables, so committing a single SRAM region to be the stack, or stacks (RTOS), is a viable plan.

Stacks without checks: That was also one of my concerns once you pointed out that it descends.

Having to make new segments to be used in SRAM1 is what I was afraid of.
For placing specific .o files in one section, I'll need to exclude their parts from the .fixed section. I don't know if its actually possible to exclude certain things from the * wildcard.

I am using AT91Bootstrap so my SDRAM is up and running when the real application starts.

Can you please point me to some of the more advanced linker scripts used in examples? I would very much like a size-limited stack.

GNU/GCC aren't really my preference.

A system can have multiple stacks, especially with an RTOS, making stackchk type calls isn't always viable. You need to manually or mechanically analyze your code, and the call trees to determine a maximal/worst case stack depth, and allocate a suitable size stack. You can also look at this at run-time by placing patterns in the stack memory you can view from your debugger, and you can add guard zones under the stack, and monitor those for containment breaches.

Even when you define specific stack sizes, like in Keil, you can still have issues of the stack crashing into the heap or static initialized space if the stack is inadequate. Certainly there are plenty of examples I've seen where the stack is insufficient to sustain hogs like scanf/printf.

About half way down is an exclusion example
http://www.johanforrer.net/BLACKFIN/index.html

I think WinARM has some more complex scripts, AVR examples have some, and the web is full of assorted stuff. O'Reilly probably has a tome on linker scripts, the topic is complex. Finding some on-point examples is probably the best way to start, but looking at a broad selection will help give you some scope of the topic.

Remember that AT91BootStrap is in SRAM, so most of the code/image you want to load needs to go into the SDRAM first. You might want to look at how the C Startup code is running (ie before it gets to main), clearing the heap, initializing the statics, etc.

Again consider how booting is staged, AT91BootStrap goes into SRAM, uBoot gets planted at the end of SDRAM, and it loads the linux kernel in the forward part of the SDRAM. If you are using AT91BootStrap to load a generic application out of NAND into SDRAM, the front would be the place to start. The application would then need to shadow the vectors (interrupts) into the first SRAM, and make sure that the SRAM was remapped at zero.