From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Williams Date: Thu, 31 Oct 2019 17:59:44 +0000 Subject: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support In-Reply-To: <20191031103610.B4D7C240060@gemini.denx.de> References: <1932577.QJWW3v3lL8@flash> <20191031103610.B4D7C240060@gemini.denx.de> Message-ID: <2710076.TiSPtmOvtb@flash> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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