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@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!