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

[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