[U-Boot] Porting u-boot to flash micro with proprietary (non-GPL) flash programming library

[Ulf Samuelsson]

Den 2019-01-14 kl. 17:55, skrev Ulf Samuelsson:
No Answer, so I am resending.

Question is:
How to port U-Boot to a flash microprocessor, where the vendor
does not supply source code to the library to program the internal flash 
without violating GPL?

Best Regards
Ulf Samuelsson

> I am working in a project where we are considering using U-Boot as a 
> bootloader for a flash microcontroller with an ARM Cortex-Rx core.
> The chip is currently not supported by U-Boot.
> 
> The processor will not be running linux.
> 
> Our board will use
> •    On Chip Flash
> •    External Parallel Flash
> •    External SPI Flash
> 
> Problem:
> To program the internal flash, we need to use the a library from the CPU 
> vendor which is only supplied to us in binary form.
> 
> Their license forbids us to link that library to open source code in a 
> way that “contaminates” their code with GPL.
> 
> GPL forbids code to be linked with non-GPL code.
> 
> There are a few common exceptions to GPL when running linux.
> 1.    Linking with a shared library is OK.
> 2.    Using a device driver which was originally written for another
>          OS. (I think this has been primarily used for graphics drivers)
> 
> Right now, our idea is to do runtime linking to the flash programming 
> library similar to a shared library.
> 
> For various reasons, we plan to have our own first level bootloader 
> which has very simple functionality, and this will be contain the vendor 
> flash programming library.
> 
> U-boot, can when started, query the first level bootloader for the 
> location of the entry points in the library and use the result to fill 
> in a struct containing the address of the entry points. As far as I 
> understand, this will not be static linking, so this should be allowed 
> in GPL.
> 
> Q:    Is this a reasonable approach to the problem?
> 
> Even if acceptable, there may be several ways of implementing this.
> Here is what I can think of:
> ======================================================================
> 1) CALLING THROUGH AN EXTERNAL CALL TABLE
> The first level bootloader has a call table containing the absolute
> addresses of the flash library entry points.
> The u-boot driver will declare the table external, and define the table 
> in the linker command file.
> u-boot needs a header file describing the call table (probably 
> implemented as a struct)
> 
> ======================================================================
> 2) COPYING A STRUCT FROM A KNOWN ADDRESS IN THE FIRST LEVEL BOOTLOADER
> 
> The simplest way I can envision, is that the first level bootloader has 
> a struct containing an field for each entrypoint. The field contains the 
> absolute address of the entry point.
> 
> The struct is copied into an u-boot datastructure as is.
> u-boot can call any entry by an indirect call.
> 
>    (*externallib.function1)(<parameters>);
> 
> For this to work, u-boot needs to know the absolute address of the table 
> inside the first level bootloader.
> Both u-boot and the first level bootloader will contain a definition of 
> the struct in a header file.
> 
> 
> ======================================================================
> 3) COPYING A STRUCT FROM AN UNKNOWN ADDRESS THROUGH A SUPERVISOR CALL.
> The first level bootloader will reside in flash at the reset address. It 
> has a supervisor call exception vector. A specific supervisor call can
> return the address of the struct above.
> 
> With this method, U-boot does not need to have internal knowledge of 
> where the struct is located in the first level bootloader.
> 
> It does need to have a header file describing the struct.
> 
> ======================================================================
> 4) CREATING A CALL TABLE BY QUERYING FOR EACH ENTRY.
> 
> This assumes that u-boot should not have any knowledge of a struct. 
> Instead a supervisor call is implemented which sends a parameter 
> defining which entry point of interest. The supervisor call returns the 
> absolute address of the entry point.
> 
> ======================================================================
> Q:    Are any of the methods above violating the GPL license?
> ======================================================================
> Q:    Is there another method which is recommended to handle the problem 
> with proprietary vendor flash libraries?
> ======================================================================
> Q:    If a processor contains functionality in a bootROM, for which 
> source is not available. How can that be used in u-boot?
> 


-- 
Best Regards
Ulf Samuelsson