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

[Tom Rini]

On Wed, Nov 06, 2019 at 10:18:45PM +0000, Aaron Williams wrote:
> 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.

Alright, so I think here's the important thing to look at moving
forward.  In mainline U-Boot, the options for communication between
closed source components and U-Boot itself (where GPLv2 is the minimum
license) are either the defined ABI or making use of the EFI ABI.  We do
not want to add or support a 3rd method.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191106/7b136b09/attachment.sig>