[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory
U-Boot Users:
I want to add a featue to the makefile configuration so that a user can compile u-boot including a directory that gets compiled as a stand alone program. I propose that users can enter a directory when configuring the board, for example
make BOARD_config SA=my_stand_alone_prog_dir
so that the user can specify a directory to be compiled with u-boot. As you can see, the SA directory is added to the mkconfig.mk file and then included as a SUBDIRS when compiling. The purpose of this option is to allow a user to *easily* include a directory containing a stand alone program.
Is this an appropreate feature? Should this be done differently? After implementing changes from your comments, I'll properly document this option and send an appropreate patch.
-Jeffrey
----------Proposed patch------------
diff --git a/Makefile b/Makefile index 9a27bc2..26cf02a --- a/Makefile +++ b/Makefile @@ -231,6 +231,11 @@ # The "tools" are needed early, so put t # Don't include stuff already done in $(LIBS) SUBDIRS = tools \ examples +# Include a directory with a stand alone program in it if the user has +# configured u-boot for it. +ifeq ($(COMPILE_STAND_ALONE),y) +SUBDIRS += $(STAND_ALONE_DIR) +endif
.PHONY : $(SUBDIRS)
diff --git a/mkconfig b/mkconfig index c3e4cea..da6e2c8 --- a/mkconfig +++ b/mkconfig @@ -72,6 +72,11 @@ echo "BOARD = $4" >> config.mk
[ "$6" ] && [ "$6" != "NULL" ] && echo "SOC = $6" >> config.mk
+if [ -n "$SA" ]; then + echo "COMPILE_STAND_ALONE = y" >> config.mk + echo "STAND_ALONE_DIR = ${SA}" >> config.mk +fi + # # Create board specific header file #
Hi Jeff,
I want to add a featue to the makefile configuration so that a user can compile u-boot including a directory that gets compiled as a stand alone program.
This sounds like a good idea. I am developing a custom MPC8349E board that I'll submit a U-Boot patch for when its done. I also plan to build a test-suite that executes as a u-boot stand-alone application. Its not clear to me that such a test suite should also be added into the U-Boot source, since its board-specific; more so than whatever changes to the current MPC8349E support I need to get the board booted. Although, I have no intention of hiding the test-suite source code.
I figured I'd submit the board support patch, and then just maintain the test-suite locally, with an email reference in a u-boot README to anyone who wanted to get access to the test-suite code. Of course, if lots of people build test suites using U-Boot, and there is common code, I'd be happy to use it. I just haven't looked for it in the source yet. The test suite would involve programming Altera FPGAs with FPGA configurations, running pin-to-pin tests, etc.
So is this the intention of your proposal, or just another use-case your proposal would support?
Cheers Dave
This sounds like a good idea. I am developing a custom MPC8349E board that I'll submit a U-Boot patch for when its done. I also plan to build a test-suite that executes as a u-boot stand-alone application. Its not clear to me that such a test suite should also be added into the U-Boot source, since its board-specific; more so than whatever changes to the current MPC8349E support I need to get the board booted. Although, I have no intention of hiding the test-suite source code.
You can put it in the board folder and have a separate make rule to choose when to compile it. In my case, though, the diagnostic tests never reach a finished state and really are only for our produtction testing.
I figured I'd submit the board support patch, and then just maintain the test-suite locally, with an email reference in a u-boot README to anyone who wanted to get access to the test-suite code. Of course, if lots of people build test suites using U-Boot, and there is common code, I'd be happy to use it. I just haven't looked for it in the source yet. The test suite would involve programming Altera FPGAs with FPGA configurations, running pin-to-pin tests, etc.
So is this the intention of your proposal, or just another use-case your proposal would support?
Actually, that is almost my exact intention.
You'll see in an e-mailed patch to this list earlier this week (I think, maybe it was last week), I started adding finctions to the exports function. I'd like to better document the stand alone programs feature. Also if there is intrest and if I have time, I'll look at putting together a barebone test suite starter package with instructions.
In message 4630F14C.8020705@ovro.caltech.edu you wrote:
This sounds like a good idea. I am developing a custom MPC8349E board that I'll submit a U-Boot patch for when its done. I also plan to build a test-suite that executes as a u-boot stand-alone application. Its not clear to me that such a test suite should also be added into the U-Boot source, since its board-specific; more so than whatever changes to the current
If you are willing to release your code under GPL, it is definitely welcome to be added to the U-Boot source tree. In cases whwere this code is board-specific it makes sense to add it to the specfic board directory. Thi shas been done before in similar cases.
I figured I'd submit the board support patch, and then just maintain the test-suite locally, with an email reference in a u-boot README to anyone who wanted to get access to the test-suite code. Of course, if lots of people build test suites using U-Boot, and there is common code, I'd be happy to use it. I just haven't looked for it in the source yet.
There are several test utilities, but no general infrastructure yet.
Best regards,
Wolfgang Denk
Hi Wolfgang,
This sounds like a good idea. I am developing a custom MPC8349E board that I'll submit a U-Boot patch for when its done. I also plan to build a test-suite that executes as a u-boot stand-alone application. Its not clear to me that such a test suite should also be added into the U-Boot source, since its board-specific; more so than whatever changes to the current
If you are willing to release your code under GPL, it is definitely welcome to be added to the U-Boot source tree. In cases whwere this code is board-specific it makes sense to add it to the specfic board directory. Thi shas been done before in similar cases.
I figured I'd submit the board support patch, and then just maintain the test-suite locally, with an email reference in a u-boot README to anyone who wanted to get access to the test-suite code. Of course, if lots of people build test suites using U-Boot, and there is common code, I'd be happy to use it. I just haven't looked for it in the source yet.
There are several test utilities, but no general infrastructure yet.
Ok, good to know. That is the direction I will go once I get back to the software design. I need to get the hardware done first :)
Dave
Jeff Mann wrote:
U-Boot Users:
I want to add a featue to the makefile configuration so that a user can compile u-boot including a directory that gets compiled as a stand alone program. I propose that users can enter a directory when configuring the board, for example
make BOARD_config SA=my_stand_alone_prog_dir
I like this idea, but can't you already do this in the Makefile, but just adding stuff to the rule for BOARD_config?
For the MPC8349E-mITX, Freescale's BSP ships with a closed-source binary firmware for the 5-port Ethernet switch. It would be great if the denx.de version of U-Boot could automatically add support for this binary if it existed in the development tree. The idea would be that u-boot.bin would include this binary.
I want to add a featue to the makefile configuration so that a user can compile u-boot including a directory that gets compiled
as a stand
alone program. I propose that users can enter a directory when configuring the board, for example
I like this idea, but can't you already do this in the Makefile, but just adding stuff to the rule for BOARD_config?
Yes, but the point of this in my case is that I compile a diagnostic utility used to test boards at our office. It does not get shipped with the board and so having a config rule just for these types of things just clutters the makefile. It would be a better solution for us and our customers if we could just copy an additional folder into the u-boot directory and add it to the list of compiled subdirectories when using the BOARD_config rule.It is also possible to use the command:
make BOARD_config SA=../my_stand_alone_prog_dir
To compile a stand alone program in the parent directory of u-boot. (which is how I use it to compile my doagnostic tools with u-boot.)
For the MPC8349E-mITX, Freescale's BSP ships with a closed-source binary firmware for the 5-port Ethernet switch. It would be great if the denx.de version of U-Boot could automatically add support for this binary if it existed in the development tree. The idea would be that u-boot.bin would include this binary.
So you comile both at once? That is soft of what I am going for, but I compile u-boot stand-alone-programs like the ones in the examples folder.
-Jeffrey
Jeff Mann wrote:
So you comile both at once? That is soft of what I am going for, but I compile u-boot stand-alone-programs like the ones in the examples folder.
No, in our case, the binary is provided to us as-is. We just need to put it on the flash image. Basically, Freescale has two development directions: the open source repositories, like the ones on denx.de and kernel.org, and the BSPs. One problem I'm trying to address is that the BSPs typically have stuff that you won't find on the external repos, like this binary. There's no way I can provide the binary in the denx.de repo, so the next best thing is to make its inclusion automatic. If the binary exists, then the code from denx.de will process it. Otherwise, it won't.
In message 4630FC72.6050700@freescale.com you wrote:
No, in our case, the binary is provided to us as-is. We just need to put it on the flash image. Basically, Freescale has two development directions: the open source repositories, like the ones on denx.de and kernel.org, and the BSPs. One problem I'm trying to address
This sounds as if you were moving on pretty thin ice. I don't know what you are doing, but you cannot create a U-Boot or Linux based "BSP" which is not also open source, or, to use the correct term, FRee Software under GPL.
is that the BSPs typically have stuff that you won't find on the external repos, like this
If it's U-Boot or Linux based, then it's GPL anyway.
binary. There's no way I can provide the binary in the denx.de repo, so the next best thing is to make its inclusion automatic. If the binary exists, then the code from
I my be reading you wrong, but this smells to me like trying to work around the GPL.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
I my be reading you wrong, but this smells to me like trying to work around the GPL.
Not at all. There is binary data that is provided to us on a file. We don't have whatever source code was used to create this binary. We put this file on flash, alongside u-boot.bin, the rootfs, and the kernel binary. They all occupy separate locations on flash. However, we do provide an 8MB file that contains a full copy of all of flash. This is used to restore flash to it's default state, in case the customer screws it up or something.
Despite the fact this flash image contains GPL and non-GPL code, there's no way it can be considered a GPL violation.
What I'm trying to do is make it so that any customer can download the latest U-Boot from denx.de, add the proprietary firmware binary to the source tree, and then build an image that can be flashed. This image would also automatically load the firmware into the hardware when its booted.
Today, the BSP team does a bunch manual work to make this happen. I'm trying to make the U-Boot on denx.de be the same as the U-Boot on the BSP.
In message 463108AB.3080905@freescale.com you wrote:
Despite the fact this flash image contains GPL and non-GPL code, there's no way it can be considered a GPL violation.
Yes, it can, if U-Boot depends on and calls code from that non-GPL image.
Best regards,
Wolfgang Denk
In message 4630F30E.4040005@freescale.com you wrote:
For the MPC8349E-mITX, Freescale's BSP ships with a closed-source binary firmware for the 5-port Ethernet switch. It would be great if the denx.de version of U-Boot could automatically add support for this binary if it existed in the development tree. The idea would be that u-boot.bin would include this binary.
You cannot link non-GPL code into U-Boot.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
You cannot link non-GPL code into U-Boot.
What if I use mkimage to merge u-boot.bin with proprietaryfirmware.bin?
If that doesn't work, what if I burn u-boot.bin into flash at some location, and then burn proprietaryfirmware.bin into flash at another location, and then I create an an image file by copying all of flash?
It depends on how you define linking. I would say that taking two binaries, one from GPL code and one from non-GPL code, and just merging them into another binary, that cannot be a GPL violation.
In message 463106E6.20203@freescale.com you wrote:
You cannot link non-GPL code into U-Boot.
What if I use mkimage to merge u-boot.bin with proprietaryfirmware.bin?
Will U-Boot at any time call any functions or jump to any entry points or otherwise execute any code in this firmare image?
It depends on how you define linking. I would say that taking two binaries, one from GPL code and one from non-GPL code, and just merging them into another binary, that cannot be a GPL violation.
You are right. If the images are indeed independent, and U-Boot does not run any code in the "other" one, then this is fine.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 463106E6.20203@freescale.com you wrote:
You cannot link non-GPL code into U-Boot.
What if I use mkimage to merge u-boot.bin with proprietaryfirmware.bin?
Will U-Boot at any time call any functions or jump to any entry points or otherwise execute any code in this firmare image?
No. I'll have to check, but I believe the application that loads the firmware into the hardware is open source.
But even if the application were non-GPL, how would running it be a GPL violation? If I load the application into memory, and just execute it, and the application runs without calling U-Boot code, and then the application exits, that's not a GPL violation.
In message 4631093C.7060002@freescale.com you wrote:
But even if the application were non-GPL, how would running it be a GPL violation? If I load the application into memory, and just execute it, and the application runs without calling U-Boot code, and then the application exits, that's not a GPL violation.
You agree that static linking against a non-GPL library is illegal?
What does static linking against a NON-GPL library mean? You combine the U-Boot image and the library image in some way, or load the library image into memory, then you call a function from that library, and just execute it, and that library function runs without calling U-Boot code, and then the library function returns, that's ... ...a GPL violation.
Agreed? Then compare my text against your text a few lines above, and tell me the difference.
Running an application and calling a function is two very different things: U-Boot works perfectly fine without this application, and is just a helper to be able to load and atart and run it. But a binary firmware, which is needed for U-Boot to function properly, where U-Boot does not work correctly or with the full functionality if the firmware is not present, is a different thing.
BTW: this is just my view, and IANAL...
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 4631093C.7060002@freescale.com you wrote:
But even if the application were non-GPL, how would running it be a GPL violation? If I load the application into memory, and just execute it, and the application runs without calling U-Boot code, and then the application exits, that's not a GPL violation.
You agree that static linking against a non-GPL library is illegal?
What does static linking against a NON-GPL library mean? You combine the U-Boot image and the library image in some way, or load the library image into memory, then you call a function from that library, and just execute it, and that library function runs without calling U-Boot code, and then the library function returns, that's ... ...a GPL violation.
Agreed? Then compare my text against your text a few lines above, and tell me the difference.
Running an application and calling a function is two very different things: U-Boot works perfectly fine without this application, and is just a helper to be able to load and atart and run it. But a binary firmware, which is needed for U-Boot to function properly, where U-Boot does not work correctly or with the full functionality if the firmware is not present, is a different thing.
BTW: this is just my view, and IANAL...
Best regards,
Wolfgang Denk
If you look at the VSC7385 switch product brief: http://www.vitesse.com/products/product.php?number=VSC7385 you will see that it has a 8051-type supervisor processor. It looks to me like all Timur is doing is loading a binary blob into the switch's supervisor processor, which would not be a GPL issue.
Unfortunately, Vitesse feels their loader software is sooper sekret so I cannot download a copy to see what the licensing terms are. If that is _not_ GPL, there may be an issue, but only with the loader software. If the loader software is stand-alone (can be run as a u-boot stand-alone application) it would not be a GPL issue since the u-boot license explicitly allows that.
IANAL (and have been reading too much groklaw) gvb
Wolfgang Denk wrote:
In message 4631093C.7060002@freescale.com you wrote:
But even if the application were non-GPL, how would running it be a GPL violation? If I load the application into memory, and just execute it, and the application runs without calling U-Boot code, and then the application exits, that's not a GPL violation.
You agree that static linking against a non-GPL library is illegal?
Yes, but just merging two binaries into a new binary isn't "linking", IMHO. For there to be linking, project A must include parts of project B. Just having A make a function call to B is not linking, otherwise proprietary applications would never be able to make syscalls into the kernel.
What does static linking against a NON-GPL library mean? You combine the U-Boot image and the library image in some way, or load the library image into memory, then you call a function from that library, and just execute it, and that library function runs without calling U-Boot code, and then the library function returns, that's ... ...a GPL violation.
Well, I'm not lawyer, and so I don't really know for sure, but I would disagree. After all, calling the library function is nothing more than loading a number into the PC register. I don't really see how that alone can be considered linking.
Running an application and calling a function is two very different things: U-Boot works perfectly fine without this application, and is just a helper to be able to load and atart and run it. But a binary firmware, which is needed for U-Boot to function properly, where U-Boot does not work correctly or with the full functionality if the firmware is not present, is a different thing.
U-Boot works just fine without this binary firmware. This particular firmware just enables the 2nd Ethernet port so that the Linux driver can load.
In message 463112C4.50603@freescale.com you wrote:
You agree that static linking against a non-GPL library is illegal?
Yes, but just merging two binaries into a new binary isn't "linking", IMHO. For there to be linking, project A must include parts of project B. Just having A make a function call to B is not linking, otherwise proprietary applications would never be able to make syscalls into the kernel.
Merging two binaries into one, so that A can make function calls into B *is* linking if the function of A depends on the results of the function calls of B.
Linux system calls is an explicitely exported interface so it is OK to use this from application code.
What does static linking against a NON-GPL library mean? You combine the U-Boot image and the library image in some way, or load the library image into memory, then you call a function from that library, and just execute it, and that library function runs without calling U-Boot code, and then the library function returns, that's ... ...a GPL violation.
Well, I'm not lawyer, and so I don't really know for sure, but I would disagree. After all, calling the library function is nothing more than loading a number into the PC register. I don't really see how that alone can be considered linking.
Please do yourself a favour and re-read the GPL.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
I really don't want to be arguing the GPL, but I am interested in a technical solution to a problem that is also legally permissible.
Merging two binaries into one, so that A can make function calls into B *is* linking if the function of A depends on the results of the function calls of B.
How do you determine "depends"? If B enables the 2nd Ethernet port, but you never actually use it, then A doesn't really depend on B. Takes these two scenarios:
1) U-Boot runs the binary application that enables Ethernet 2, but it doesn't load the driver for Ethernet 2. Therefore, the functioning of U-Boot does not depend on the binary.
1) U-Boot runs the binary application that enables Ethernet 2, and it loads the driver for Ethernet 2. Therefore, the U-Boot can do Ethernet I/O on this device.
By your definition, scenario #1 is not a GPL violation, but scenario #2 is. So I can merge my closed-source proprietary binary in with GPL as long as I don't enabled the 2nd Ethernet port.
Linux system calls is an explicitely exported interface so it is OK to use this from application code.
So it's okay for a non-GPL binary to call GPL code, but not the other way around?
Please do yourself a favour and re-read the GPL.
I don't think just reading the GPL is enough to understand it. Some parts of it are vague, and their interpretations are debatable.
Wolfgang Denk wrote:
I really don't want to be arguing the GPL, but I am interested in a technical solution to a problem that is also legally permissible.
If you follow the rule that you cannot execute U-Boot code after you have executed non GPL code you will most likely not violate GPL.
Your technical solutions are obvious:
* Explain your problem to code owner and request code to be GPL. * Drop the code, ask for interface info, and rewrite GPL code from scratch * Write a program which calls the loader function, and then calls U-Boot. This can be non-GPL.
What you can't do is to have U-boot call a subroutine inside the non-GPL code, nor can you from non-GPL code jump to any point except the start of u-boot.
Merging two binaries into one, so that A can make function calls into B *is* linking if the function of A depends on the results of the function calls of B.
How do you determine "depends"? If B enables the 2nd Ethernet port, but you never actually use it, then A doesn't really depend on B. Takes these two scenarios:
- U-Boot runs the binary application that enables Ethernet 2, but it
doesn't load the driver for Ethernet 2. Therefore, the functioning of U-Boot does not depend on the binary.
Your violation occurs when you make a subroutine call. A pure jump which never returns is no violation.
If you, from U-boot enable some H/W using call to non-GPL code, and then jump to an application which uses the H/W, then again you have violated the GPL.
- U-Boot runs the binary application that enables Ethernet 2, and it
loads the driver for Ethernet 2. Therefore, the U-Boot can do Ethernet I/O on this device.
By your definition, scenario #1 is not a GPL violation, but scenario #2 is. So I can merge my closed-source proprietary binary in with GPL as long as I don't enabled the 2nd Ethernet port.
Linux system calls is an explicitely exported interface so it is OK to use this from application code.
So it's okay for a non-GPL binary to call GPL code, but not the other way around?
U-Boot does not have any explicitly exported interfaces except its entry point. If you in any way make the address of a subroutine inside U-boot available to another application you link the application with U-Boot and the application must be GPL. You can jump to a binary which loads non-GPL stuff into another MCU but you cant return to u-boot.
Timur Tabi Linux Kernel Developer @ Freescale
Best Regards Ulf Samuelsson
Ulf Samuelsson wrote:
Wolfgang Denk wrote:
I really don't want to be arguing the GPL, but I am interested in a technical solution to a problem that is also legally permissible.
If you follow the rule that you cannot execute U-Boot code after you have executed non GPL code you will most likely not violate GPL.
Your technical solutions are obvious:
- Explain your problem to code owner and request code to be GPL.
- Drop the code, ask for interface info, and rewrite GPL code from scratch
- Write a program which calls the loader function, and then calls U-Boot. This can be non-GPL.
What you can't do is to have U-boot call a subroutine inside the non-GPL code, nor can you from non-GPL code jump to any point except the start of u-boot.
Not exactly true...
Merging two binaries into one, so that A can make function calls into B *is* linking if the function of A depends on the results of the function calls of B.
How do you determine "depends"? If B enables the 2nd Ethernet port, but you never actually use it, then A doesn't really depend on B. Takes these two scenarios:
- U-Boot runs the binary application that enables Ethernet 2, but it
doesn't load the driver for Ethernet 2. Therefore, the functioning of U-Boot does not depend on the binary.
Your violation occurs when you make a subroutine call. A pure jump which never returns is no violation.
If you, from U-boot enable some H/W using call to non-GPL code, and then jump to an application which uses the H/W, then again you have violated the GPL.
Not exactly true...
- U-Boot runs the binary application that enables Ethernet 2, and it
loads the driver for Ethernet 2. Therefore, the U-Boot can do Ethernet I/O on this device.
By your definition, scenario #1 is not a GPL violation, but scenario #2 is. So I can merge my closed-source proprietary binary in with GPL as long as I don't enabled the 2nd Ethernet port.
Linux system calls is an explicitely exported interface so it is OK to use this from application code.
So it's okay for a non-GPL binary to call GPL code, but not the other way around?
U-Boot does not have any explicitly exported interfaces except its entry point. If you in any way make the address of a subroutine inside U-boot available to another application you link the application with U-Boot and the application must be GPL. You can jump to a binary which loads non-GPL stuff into another MCU but you cant return to u-boot.
Not exactly true...
U-Boot has a documented application interface that non-GPL "stand alone" applications may call. This is equivalent to the linux system call API, that non-GPL applications may call. http://www.denx.de/wiki/UBootdoc/StandalonePrograms
3216 More About U-Boot Image Types: 3217 ------------------------------ 3218 3219 U-Boot supports the following image types: 3220 3221 "Standalone Programs" are directly runnable in the environment 3222 provided by U-Boot; it is expected that (if they behave 3223 well) you can continue to work in U-Boot after return from 3224 the Standalone Program.
Timur Tabi Linux Kernel Developer @ Freescale
Best Regards Ulf Samuelsson
Dear Ulf,
in message 002601c78903$64f47cc0$01c4af0a@Glamdring you wrote:
U-Boot does not have any explicitly exported interfaces except its entry point.
Yes, it does. The interface for standalone applications explicitely allows for non-GPL code. Please see the first 15 lines of the "COPYING" file that comes wioth the U-Boot code.
Best regards,
Wolfgang Denk
In message 46324857.2020904@freescale.com you wrote:
I really don't want to be arguing the GPL, but I am interested in a technical solution to a problem that is also legally permissible.
Merging two binaries into one, so that A can make function calls into B *is* linking if the function of A depends on the results of the function calls of B.
How do you determine "depends"? If B enables the 2nd Ethernet port, but you never actually use it, then A doesn't really depend on B. Takes these two scenarios:
Depends menas: does not work, or only in a restricted way, without it.
- U-Boot runs the binary application that enables Ethernet 2, but it doesn't load the
driver for Ethernet 2. Therefore, the functioning of U-Boot does not depend on the binary.
Yes, it does, as the function of Ethernet 2 obviously depends on this code.
Linux system calls is an explicitely exported interface so it is OK to use this from application code.
So it's okay for a non-GPL binary to call GPL code, but not the other way around?
Please read the specific licenses. Any code that only uses the exported interfaces can be run under control of the Linux operating system. But you must take care about which liraries you link against. They come with their own licenses; for example, glibc comes under LGPL which explicitely allows linking against Non-GPL code.
If GPL code can link against non-GPL stuff obviosly depends on the licensing of that stuff.
Please do yourself a favour and re-read the GPL.
I don't think just reading the GPL is enough to understand it. Some parts of it are vague, and their interpretations are debatable.
Then please ask a lawyer.
Best regards,
Wolfgang Denk
----- Original Message ----- From: "Timur Tabi" timur@freescale.com To: "Wolfgang Denk" wd@denx.de Cc: u-boot-users@lists.sourceforge.net; "Jeff Mann" MannJ@embeddedplanet.com Sent: Thursday, April 26, 2007 10:09 PM Subject: Re: [U-Boot-Users] Proposal for a make option to include an additional stand alone program directory
Wolfgang Denk wrote:
You cannot link non-GPL code into U-Boot.
What if I use mkimage to merge u-boot.bin with proprietaryfirmware.bin?
If that doesn't work, what if I burn u-boot.bin into flash at some location, and then burn proprietaryfirmware.bin into flash at another location, and then I create an an image file by copying all of flash?
It depends on how you define linking. I would say that taking two binaries, one from GPL code and one from non-GPL code, and just merging them into another binary, that cannot be a GPL violation.
If combining U-Boot with the switch binary results in that you can tftp from any of the 5 ports , and this is not possible without combining with the binary, then you are most likely violating the GPL.
If your version of u-boot has any knowledge about program locations within the closed binary, or vice versa, then you are most likely violating the GPL.
If u-boot is used to start your closed binary, then you are IMO, not violating GPL.
Best Regards Ulf Samuelsson
Ulf Samuelsson wrote:
----- Original Message ----- From: "Timur Tabi" timur@freescale.com To: "Wolfgang Denk" wd@denx.de Cc: u-boot-users@lists.sourceforge.net; "Jeff Mann" MannJ@embeddedplanet.com Sent: Thursday, April 26, 2007 10:09 PM Subject: Re: [U-Boot-Users] Proposal for a make option to include an additional stand alone program directory
Wolfgang Denk wrote:
You cannot link non-GPL code into U-Boot.
What if I use mkimage to merge u-boot.bin with proprietaryfirmware.bin?
If that doesn't work, what if I burn u-boot.bin into flash at some location, and then burn proprietaryfirmware.bin into flash at another location, and then I create an an image file by copying all of flash?
It depends on how you define linking. I would say that taking two binaries, one from GPL code and one from non-GPL code, and just merging them into another binary, that cannot be a GPL violation.
If combining U-Boot with the switch binary results in that you can tftp from any of the 5 ports , and this is not possible without combining with the binary, then you are most likely violating the GPL.
I think there's a lot of misunderstanding going on here, and it's probably my fault for not being clear. The non-GPL firmware is not run on the host processor. It is loaded into the memory of an on-board device.
What I was considering is making a change to the build process so that when the user built u-boot.bin, if the firmware binary were present, it would merge that into the u-boot.bin binary, for convenience.
If your version of u-boot has any knowledge about program locations within the closed binary, or vice versa, then you are most likely violating the GPL.
The binary is not being executed by U-Boot, it is being copied into device memory by U-Boot via a loader application. If the loader application is GPL, then I don't see how this is a GPL violation. However, if the loader is not GPL, then I'm not sure.
On Thursday 26 April 2007 23:04, Timur Tabi wrote:
I think there's a lot of misunderstanding going on here, and it's probably my fault for not being clear. The non-GPL firmware is not run on the host processor. It is loaded into the memory of an on-board device.
This seems to be the same as needed for the Intel IXP4xx NPE's (Network Processing Engines). These are on-chip co-processors used for ethernet communication. And Intel provides a binary image for these NPE's that is *not* released under a GPL compatible license. And here I know for sure that this makes is impossible to even "link" this binary into the U-Boot image by something like "#include "npe-binary.h".
What we have to do instead, is program this binary into a specific FLASH sector and load it from there into the NPE's. If you "dump" this complete FLASH image, or generate this combined image via some other tool, then it should be no problem.
What I was considering is making a change to the build process so that when the user built u-boot.bin, if the firmware binary were present, it would merge that into the u-boot.bin binary, for convenience.
If your version of u-boot has any knowledge about program locations within the closed binary, or vice versa, then you are most likely violating the GPL.
The binary is not being executed by U-Boot, it is being copied into device memory by U-Boot via a loader application. If the loader application is GPL, then I don't see how this is a GPL violation. However, if the loader is not GPL, then I'm not sure.
Please see above. The NPE-loader *is* GPL-compatible in this case and it is not possible to include the binary of the NPE's in the standard U-Boot build process.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
In message 463113F0.4010804@freescale.com you wrote:
this is a GPL violation. However, if the loader is not GPL, then I'm not sure.
If the loader is not GPL, then there is no doubt that it's a GPL violation.
Best regards,
Wolfgang Denk
participants (7)
-
David Hawkins -
Jeff Mann -
Jerry Van Baren -
Stefan Roese -
Timur Tabi -
Ulf Samuelsson -
Wolfgang Denk