Dear Aaron,
In message 1932577.QJWW3v3lL8@flash you wrote:
We do this relocation as well, however the way we do it is by changing a couple of TLB entries. This lets U-Boot begin execution from any memory location, be it flash, L2 cache or RAM. It also lets us statically link U-Boot to run at a fixed address, in our case 0xC0000000. The relocation happens
It seems you have missed the primary purpose of relocation. The interesting thing is not the start address, but the end address of U-Boot in memory, as we alsways try to place the U-Boot code and data at the very end of the available memory (and yes, this includes systems which can cam with different memory sizes). Additionally, we want to be able to reserve additional memry at the end of RAM, above U-Boot, so it can even be kept across warm boots. Features like protected RAM (PRAM), shared log buffers, shared video memory etc. come in to mind here.
This might be something to consider in the future on some platforms where "relocation" could be performed by just adjusting the TLB or page tables. MIPS makes this particularly easy.
This cannot be done, not without castrating U-Boot from a number of features that require allocation at the end of the available RAM, see above.
That's fine. The code is actually quite small. It has some custom APIs unique to our needs. We have need to call into the phy code from these applications. I don't know if this could work with the general API or not. One reason we did
What exactly do you need this for? Why don't you just link your code with the rest of U-Boot?
Best regards,
Wolfgang Denk