[U-Boot] [EXT] Re: Cavium/Marvell Octeon Support

[Wolfgang Denk]

Dear Aaron,

In message <1932577.QJWW3v3lL8 at 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: wd at 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