[U-Boot] Porting u-boot to flash micro with proprietary (non-GPL) flash programming library
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?
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: ======================================================================
- 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?
participants (1)
-
Ulf Samuelsson