Im studying some assembly code, but i dont get why the usually point SP to program entry point or other random position. For example this bare metal code for raspberry pi , points to 0x80000000 but .text is mapped to 0x8000, is there any reason?
As far as why point at the entry point:
The better question is why do Linux kernel loaders load the kernel somewhere other than zero.
Depending on the era of Linux kernel habit (for arm embedded systems)(or specific ports), some non-zero address like 0x8000, 0x80000, etc may be the entry point for a Linux kernel. This leaves room for a DTB for example. But if writing bare-metal, where none of that matters you simply have 0x8000 or more bytes of memory just sitting there, of which maybe 32 bytes or so are your exception table.
So setting the stack pointer to 0x8000 for a system where your bare metal by default (without making additional changes to the system to change the entry point (to 0x00000000 for example)) entry point is. This allows you almost 0x8000 bytes for stack as well as the proper entry point (for the system).
This also allows for public examples that might just work where you do not have to say try to determine the total amount of memory, which even if you know how much is on the board, there is still a control that you can modify to change the ratio between the GPU and ARM.
In general you need to set a place for the stack pointer, you can overcomplicate with linker scripts and try to control where it is and fix its size(ish, from a linker perspective, not reality). Or you can have crashes and re-tune the code every time the next system comes out with more memory. Or put it at say 0x10000 or some address that works on all variations of the platform. And deal with that.
This is a very clean solution that allows for public examples, the code loads where the kernel does so no extra work there to have to explain that. And the stack pointer works down from the entry point since there is plenty of thus far unused space there.
As far as the specific example shown. Just point at top of memory, which is the most common place you will find the stack pointer. Granted these boards sell with different amounts of memory so giving 2GB was possibly the smallest size for that era board.
In general you point somewhere that you have some amount of room below (remember on the arm the address you are pointing at is not actually used it subtracts first, so 0x8000 the first entry is at 0x7FFC).
Typically/traditionally you put the stack pointer at the top of memory, the heap starts at the end of data and code and grows upward, and you do your system engineering to prevent them from colliding. The top of memory for a platform like you have shown varies you can get 2GB or 4GB cards, so how do you write an example to share, if you put 4GB on a 2GB card it may crash (fail) or wrap (dumb luck). If the blink the led example is only a few hundred bytes and the stack usage is in the tens of bytes, then you can point it a thousand some bytes above the entry point. Or in the case of the pi or other where the Linux entry point defaults well into memory you can point at the entry point and have all that space. A use case you see with complicated linker scripts (these make zero sense to me) is to allocate a fixed sized stack and let the linker place it in memory space and then point to that.
All three of these common solutions are fine, you just happen to be asking about two of them. "Why" questions like this have no fixed answer, other than, because that is how they did it. The stack has to be somewhere, as the bare-metal programmer you get to pick where yours is, and with your specific experiences over time and the portability or reusability (or lack of) of your code may factor into what you choose on your next project.
Depending on your view (glass half empty or half full) there is no right answer and/or there is no wrong answer . There are different ways to do it and they each work for at least one use case (hopefully).