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