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

[Aaron Williams]

Hi Wolfgang,

On Wednesday, November 6, 2019 7:06:17 AM PST Wolfgang Denk wrote:
> Dear Aaron,
> 
> In message 
<BYAPR18MB24402A81E226896D208669F5B17E0 at BYAPR18MB2440.namprd18.prod.outlook.com> 
you wrote:
> > > Definitely not.  You could not implement any of this without heavily
> > > relyin on and deriving from internal interfaces of U-Boot which are
> > > not exported for non-GPL use.
> > 
> > See
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.gnu.org_licenses
> > _old-2Dlicenses_gpl-2D2.0-2Dfaq.en.html-23GPLInProp-3D&d=DwIDaQ&c=nKjWec2b
> > 6R0mOyPaz7xtfQ&r=3yfMNumMHGMnOfmVc0dViBi3fJfF8ZXRL_aRWSIGwm4&m=a19tqjpYreP
> > S1AEd1tHmUya1hcqvHmvs57fTB9c5I50&s=rp_kzh8HU_FV56RrXpf-0DCuegF0rrporRqWwdT
> > MiR0&e= rietarySystem
> > 
> > This behaves exactly in the manner that is permitted by the GPL.
> > They are completely separate programs.
> 
> Are they?
> 
> You wrote:
> 
> "There is no linking. Only a call table descriptor is published in a
> named block of memory."
> 
> I can only interpret from that that there is a call table, where your
> applications call into interfaces that have not been exported for
> non-GPL use.  This is not what I call "completely separate".
> 
> 
> Best regards,
> 
> Wolfgang Denk

Calling directly into U-Boot would be bad. We don't do that. It wouldn't work 
anyway on our 32-bit bootloader due to the required TLB mapping.

There is no call table. There is a single XKPhys address that points to some 
assembly code that saves the state of the calling application and sets up the 
memory mapping and stack for U-Boot (we map it to 0xFFFFFFFFC0000000) then 
look at an opcode that's passed and parameters. From there it performs one of 
several functions based on the opcode. On the way out the reverse is done, the 
state is restored and the TLB restored before returning to the outside 
application. The calling application has its own virtual memory map, so that 
has to be saved and restored on entry by the assembly code as well.

Since U-Boot uses a TLB for mapping, it's just not possible for an outside 
application to call into U-Boot using a function table, so everything must go 
through the one assembly function. The old U-Boot code was written before EFI 
support was added. It looks like I'll be removing it anyway, though. We have 
never exported any U-Boot functions save for the assembly code and the API 
functionality. The API functionality was not usable by our applications since 
our applications were typically 64-bit whereas our old U-Boot was 32-bit 
running in mapped memory (0xFFFFFFFFC0000000/0xC0000000) and physically 
located at the top of physical memory.

-Aaron