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 -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Many companies that have made themselves dependent on [the equipment of a certain major manufacturer] (and in doing so have sold their soul to the devil) will collapse under the sheer weight of the un- mastered complexity of their data processing systems. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot