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 > <byapr18mb24402a81e226896d208669f5b1...@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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot