First you should verify whether you mean SDRAM or SRAM. I don't think this microcontroller supports SDRAM and I suspect you should plan to use an external SRAM.
Refer to the microcontroller documentation for examples on how to connect the microcontroller to the external SRAM and flash. You could also find an evaluation board that contains external memories and reference the eval board's schematic.
You will need to configure the microcontroller's External Memory Controller in order for the microcontroller to be able to use the external memories. Refer to the microcontroller's User Guide for details on how to configure the External Memory Controller. Basically each memory will be associated with a chip select pin and you will have to configure all the settings associated with the chip selects that you are using. Typically the External Memory Controller gets configured with some instructions in the startup code for your application. (It's configured by the startup code so that the external memories are accessible sooner rather than later.) You will likely have to provide, or at least customize, this portion of the startup code. Here again, if you can find an eval board with external memories then the example program that comes with the eval board will be a great reference.
Once the External Memory Controller is configured properly, the microcontroller should be able to read and write to the external SRAM without any additional driver code. The microcontroller should also be able to read from the external flash without any special driver code. However, writing to the external flash will require some special driver code that you will have to incorporate in your program. Refer to the flash part's datasheet for the erase and program algorithms that are required to reprogram the flash. Once again, an eval board example would be a good reference.
(If you don't need to reprogram the external flash at run time then you may not need the flash driver code. For example, you may be able to get by with reprogramming the flash via JTAG with a special flash programming application on your PC.)
I'm not familiar with the internal bootloader provided with this microcontroller. I suspect it reads code from the UART and copies it into internal SRAM and then executes it. I doubt that this bootloader will support your external memories automatically. But you may be able to get the source code for the internal bootloader and then customize it by adding support for your external memories.
Ok, let's first define some terms and the differences between them.
This is a small program coded into the chip's Flash or PROM. Its purpose is to allow you to install a program from outside into the Flash or other internal storage. Apart from that it is usually completely passive and doesn't affect your running program in any way.
This is a small program coded into the chip's Flash or PROM. It is usually installed using the bootloader originally if one exists, or it can take the place of a bootloader and also perform the functions associated with that. It's main function is to load a program from some storage medium - be that flash, SD card, or whatever - and execute it. It often also provides some IO facilities, such as routines for accessing the console. Loaders also often provide a configuration environment with NVRAM (often just a block of Flash) for storing system settings.
As you can see a loader is far more complex than a bootloader.
So they are just both concerned with getting your program into the right place, be that into Flash or RAM, depending on a) how your program is written, and b) what your system is designed to do. That is the "loading" phase of the program. With the bootloader the "loading" is done once by you when you burn your program into the chip. With the loader it is done every time at reset (if needed).
Then control is transferred to your program - be that in RAM (with the loader) or Flash (with either the loader or the bootloader). From then on everything else that happens is purely down to what your program does.
If you happened to write your program in C, then you will have certain C conventions and C library code in place. One of those conventions is the concept of the .data, .bss, etc. C library code manages those sections for you, copying data from .rodata into .data (or wherever for your system) if you are executing from Flash, blanking .bss, etc. That routine is called "crt0", or C Run-Time stage 0, and is responsible for the initialization of your program and passing control to the main() function.
If you didn't write your program in C - say you wrote it in Assembly, then what happens when control is passed to your program is entirely up to you. You might decide to have some block of RAM set aside for global variables. You may not. It's entirely up to you.
So in general, once control has been passed to your program, what happens then is entirely down to your program.
As for setting things like clocks and such, well, that depends entirely on the chip. Most of them have the basic clock settings stored in flash and are loaded up at power-on before anything else happens. On some chips they form part of the bootloader, on some they are separate, etc. Some chips provide a way of adjusting the clock from software, some don't. If they do, then when that would happen is anyone's guess. The bootloader may set the clock, or maybe a loader, or even your own program might set a specific clock speed.
For the stack pointer, each environment in the boot sequence is a separate system in its own right. Typically the bootloader or loader would set the stack pointer for its own usage. Then when control is passed to your program the stack pointer will be re-initialized by your program to suit its own needs. Once your program executes the bootloader or loader as good as doesn't exist any more. Yes, there may be the ability to call functions based in the loader (like a PC'S BIOS calls) but the loader is no longer running as such.
Best Answer
The SFR space refers to physical device registers. It has 128 words worth of addresses, but not all of that is actually implemented. What is implemented is built in discrete flip flops that are directly connected to the peripherals and I/O ports. The SFRs sit on the device internal data bus. They are physically located all over the chip, local to the peripherals that they are connected to. This address space is also orthogonal to the RAM address space as it is accessed with different instructions and/or different addressing modes.