[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Jeff Mann]

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
 #

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[David Hawkins]

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

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Jeff Mann]

> 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. 

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
For every complex problem, there is a solution that is simple,  neat,
and wrong.                                               - Mark Twain

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[David Hawkins]

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

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Timur Tabi]

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.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Jeff Mann]

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

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Timur Tabi]

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.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A girl with a future avoids the man with a past.
                                   -- Evan Esar, "The Humor of Humor"

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Timur Tabi]

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.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Q:  What's a light-year?
A:  One-third less calories than a regular year.

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[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

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There is a biblical analogy I'd like to draw here.   Casts are to C++
Programmers what the apple was to Eve.         - Scott Douglas Meyers

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Timur Tabi]

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.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Artificial Intelligence is no match for natural stupidity.

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Timur Tabi]

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.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You can love it, change it, or leave it.    There is NO other option.
But do not complain - it is your own choice...                  -- wd

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Jerry Van Baren]

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

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Timur Tabi]

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.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never underestimate the bandwidth of a station wagon full of tapes.
                                -- Dr. Warren Jackson, Director, UTCS

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Timur Tabi]

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.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Ulf Samuelsson]

> 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:
>
> 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.
>


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.

> 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?
>

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 

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Jerry Van Baren]

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:
>>
>> 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.
> 
> 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...

>> 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?
>>
> 
> 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>

<http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=README;h=90ef2c2eba66be9d011c84f34ca44cc637b76095;hb=HEAD#l3257>

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.

API:
<http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=include/exports.h;h=8f7f61703c6c47519794996d65931018b3216d86;hb=HEAD>

Examples:
<http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=tree;f=examples;h=3b95ec59ee8e58fc459596dfd32b3c3b2a881d77;hb=HEAD>

>> Timur Tabi
>> Linux Kernel Developer @ Freescale
> 
> Best Regards
> Ulf Samuelsson 

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,    CEO: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"That unit is a woman."
"A mass of conflicting impulses."
	-- Spock and Nomad, "The Changeling", stardate 3541.9

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[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.

> 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.

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

-- 
DENX Software Engineering GmbH,    CEO: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Beware of bugs in the above code; I have only proved it correct, not
tried it."                                             - Donald Knuth

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Ulf Samuelsson]

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

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Timur Tabi]

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.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Stefan Roese]

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
=====================================================================

[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Either one of us, by himself, is expendable.  Both of us are not.
	-- Kirk, "The Devil in the Dark", stardate 3196.1