On Thursday, October 31, 2019 3:36:10 AM PDT Wolfgang Denk wrote:
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 is exactly what we do. We use a high virtual address and always move it to the end of physical memory.
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?
We need it to obtain and modify the phy parameters. This is a custom 25G gearbox that needs a lot of hand holding. This may end up being a low priority (not the gearbox, but the API). It's only a few hundred lines of code (the API).
Best regards,
Wolfgang Denk
-Aaron