[U-Boot-Users] U-Boot not responding back to ARP requests?

[U-Boot-Users] U-Boot not responding back to ARP requests?

[Robin Getz]

All:

I was doing some debugging of some networking issues I am seeing, and saw
something that I thought was strange. I am seeing the following:

If I set things up as U-Boot = 192.168.0.3 and cross over cable to U-boot 
on 192.168.0.2

 From U-boot, if I ping 192.168.0.2

The ethereal dump is something like:

U-Boot Broadcasts -> Who has 192.168.0.2? Tell 192.168.0.3
Server Reply      -> I do (192.168.0.3 is at aa.bb.cc.dd.ff.gg)
U-boot IMCP       -> ping request
Server IMCP       -> ping reply

And now U-boot stops, and goes back to the command prompt. (like it should)

Now the Server starts asking:

Server Broadcasts -> who has 192.168.0.3? Tell 192.168.0.2
Server Broadcasts -> who has 192.168.0.3? Tell 192.168.0.2
Server Broadcasts -> who has 192.168.0.3? Tell 192.168.0.2
It does that three times (once a second) every time that it sees a packet.

My question is - shouldn't U-Boot respond? I don't see it in the code (I 
see the rarp handler, but not a arp handler).

My problem is that I have many U-boot boards on the same network, and the 
network is being flooded with ARP traffic, as the routers try to figure out 
the U-Boot MAC<->IP associations.

Thanks
-Robin

[U-Boot-Users] U-Boot not responding back to ARP requests?

[Wolfgang Denk]

Dear Robin,

in message <6.1.1.1.0.20040926124409.01e178d0@wheresmymailserver.com> you wrote:
> 
> I was doing some debugging of some networking issues I am seeing, and saw
> something that I thought was strange. I am seeing the following:

It's normal.

> And now U-boot stops, and goes back to the command prompt. (like it should)

At  this   point,   please   remember   that   U-Boot   is   strictly
single-tasking, and that it usually uses polled device drivers only.

> Now the Server starts asking:
> 
> Server Broadcasts -> who has 192.168.0.3? Tell 192.168.0.2
> Server Broadcasts -> who has 192.168.0.3? Tell 192.168.0.2
> Server Broadcasts -> who has 192.168.0.3? Tell 192.168.0.2
> It does that three times (once a second) every time that it sees a packet.

Why does your server do that? It just TALKED with 192.168.0.2, so  it
should  really  be able to remember which MAC address it used to send
the ICMP replies to.

> My question is - shouldn't U-Boot respond? I don't see it in the code (I 
> see the rarp handler, but not a arp handler).

Why should U-Boot respond? It has completed it's  network  task,  and
shut down the network driver. It does not even attemot to receive any
packets from the network any more.

> My problem is that I have many U-boot boards on the same network, and the 
> network is being flooded with ARP traffic, as the routers try to figure out 
> the U-Boot MAC<->IP associations.

For U-Boot this is a S.E.P. (Somebody Else's  Problem).  U-Boot  does
not care about this (and there is no reason why it should).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Where there's no emotion, there's no motive for violence.
	-- Spock, "Dagger of the Mind", stardate 2715.1

[U-Boot-Users] GPL Licensing issues

[Robin Getz]

The files in the examples directory - since everything needs to be linked 
to u-boot to work, and u-boot is released under the GPL, does that mean 
that custom user applications are also under the GPL - or do you use 
Linus's relationship of kernel/application separation?

Either is OK - I was just going to be talking to some people and wanted to 
make sure they understood things about how to keep their secret sauce to 
them selves.

I assume that if it does use U-Boot functions, then the application is a 
derivative work, and should be covered under the GPL (must make available 
source, per the GPL). If the application does not use any U-boot functions, 
it would not be classified a derivative work - because it could be stand 
alone program, and burned into flash without U-boot to load it.

I thought I would get the contributors/maintainers aspects before I started 
spreading nasty rumors and untruths - so can someone clarify things for me?

-Robin

[U-Boot-Users] GPL Licensing issues

[Marc Leeman]

> The files in the examples directory - since everything needs to be linked
> to u-boot to work, and u-boot is released under the GPL, does that mean
> that custom user applications are also under the GPL - or do you use
> Linus's relationship of kernel/application separation?

Didn't linux say that linking involves using the GPL. I remember a
discussion about this very topic a couple of months ago on the lkml
(about the nvidia modules).

As far as I am concerned, including GPL header files makes your
application GPL (since you implicitly verbatim copy code).

This being said, I have problems convincing collegues who are
convinced that they write a piece of 'original' code and don't want to
make it public...

-- 
ash nazg durbatul?k, ash nazg gimbatul,
ash nazg thrakatul?k agh burzum-ishi krimpatul

[U-Boot-Users] GPL Licensing issues

[Wolfgang Denk]

In message <6.1.1.1.0.20040926174406.01e1d130@wheresmymailserver.com> you wrote:
> The files in the examples directory - since everything needs to be linked 
> to u-boot to work, and u-boot is released under the GPL, does that mean 
> that custom user applications are also under the GPL - or do you use 
> Linus's relationship of kernel/application separation?

Standalone applications only use exported U-Boot  services.  They  do
not  have  to  be linked against any U-Boot code. So ther eis no need
for  standalone  applications  to  be  GPLed  -  exactly   like   the
kernel/application separation in Linux.

> Either is OK - I was just going to be talking to some people and wanted to 
> make sure they understood things about how to keep their secret sauce to 
> them selves.

See http://www.denx.de/twiki/bin/view/UBootdoc/Presentation for some
materrial I prepared for soem U-Boot presentations myself; it covers
this topic in
http://www.denx.de/twiki/bin/view/UBootdoc/StandalonePrograms

> I assume that if it does use U-Boot functions, then the application is a 
> derivative work, and should be covered under the GPL (must make available 

But standalone applications doe not use U-Boot functions by  linking,
only through the exported interface. Just like Linux system calls.

> source, per the GPL). If the application does not use any U-boot functions, 
> it would not be classified a derivative work - because it could be stand 
> alone program, and burned into flash without U-boot to load it.

No. You can burn it into flash, but you still need U-boot to run it -
like you need  a  Linux  kernel  to  run  a  proprietary  application
program.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I am an atheist, thank God!

[U-Boot-Users] GPL Licensing issues

[Wolfgang Denk]

In message <1f729c4804092623274a63a453@mail.gmail.com> you wrote:
>
> As far as I am concerned, including GPL header files makes your
> application GPL (since you implicitly verbatim copy code).

Header files contain interfaces, not code.

Code is in source files per definition :-)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
In any group of employed individuals the only naturally  early  riser
is  _always_  the office manager, who will _always_ leave reproachful
little notes ... on the desks of their subordinates.
                                - Terry Pratchett, _Lords and Ladies_

[U-Boot-Users] GPL Licensing issues

[Robin Getz]

wd at denx.de [mailto:wd at denx.de] wrote:
>Header files contain interfaces, not code.
>
>Code is in source files per definition :-)

Great - it is pretty clear in your on-line docs (thanks for the link):
http://www.denx.de/twiki/bin/view/UBootdoc/StandalonePrograms

[snip/snip]
=========
1.11. Standalone Programs
   Used for:
     - code that shall not be made available under GPL
=========

makes it pretty clear.

Thanks
-Robin

For those that are interested in Linus's comments about 
applications/kernel, see the COPYING file in your linux kernel source tree 
- or at:
http://www.kernel.org/pub/linux/kernel/COPYING

BTW - in mailman you can write a reg expression & set "Hold posts with 
header value matching a specified regexp" - to not let all the html mail 
through?

[U-Boot-Users] GPL Licensing issues

[Marc Leeman]

> Header files contain interfaces, not code.
> Code is in source files per definition :-)

In an ideal world with decent programmers, they are :)

In a something less than ideal world where ppl are bent on *cough*
optimising *cough* the code for reasons they only know, code can be
found anywhere...

Don't get me wrong, I fully agree with you, but in an environment
where engineers with an exclusive FPGA and hardware background write C
'firmware', one tends to see all kinds of code organisations :-/

As such, making the difference between *.c and *.h might not be the
best solution. But this is the OS vs FS software discussion again in
which I am not yet fully decided (I think)...

-- 
ash nazg durbatul?k, ash nazg gimbatul,
ash nazg thrakatul?k agh burzum-ishi krimpatul

[U-Boot-Users] GPL Licensing issues

[Marius Groeger]

On Mon, 27 Sep 2004, Marc Leeman wrote:

> Don't get me wrong, I fully agree with you, but in an environment
> where engineers with an exclusive FPGA and hardware background write C
> 'firmware', one tends to see all kinds of code organisations :-/

I'm not much of an EE, but I think it's too easy to always put the 
blame on those folks. I'm pretty sure there were some fine CS people 
involved in <asm/uaccess.h>... ;-)

Regards,
Marius

-- 
Marius Groeger <mgroeger@sysgo.com>
SYSGO AG                      Embedded and Real-Time Software
Voice: +49 6136 9948 0                  FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com

[U-Boot-Users] GPL Licensing issues

[Marc Leeman]

> I'm not much of an EE, but I think it's too easy to always put the
> blame on those folks. I'm pretty sure there were some fine CS people
> involved in <asm/uaccess.h>... ;-)

<off topic>
Nah, 

I am just taking a personal example and try to generalise it, has
nothing to do with CS vs EE (Our software group wants to implement a
feature in the controlling software to show graphically and in real
time the loads of all the processes of the processors on the boards;
says enough).

Some ppl are just excellent FPGA coders, and are convinced they
exhibit the same skills after writing 200 lines of C code: resulting
in a lot of and long #defines and a lot of 'simple' functions on *.h
files.

Happy debugging :-/
</off topic>

-- 
ash nazg durbatul?k, ash nazg gimbatul,
ash nazg thrakatul?k agh burzum-ishi krimpatul

[U-Boot-Users] GPL Licensing issues

[Doug Kehn]

--- Wolfgang Denk <wd@denx.de> wrote:

> 
> Header files contain interfaces, not code.
> 
> Code is in source files per definition :-)
> 

Could this distinction become blurred as 'inline'
functions appear in header files?

Regards.
...doug


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

[U-Boot-Users] GPL Licensing issues

[Wolfgang Denk]

In message <20040927124041.76928.qmail@web51908.mail.yahoo.com> you wrote:
> 
> > Code is in source files per definition :-)
> 
> Could this distinction become blurred as 'inline'
> functions appear in header files?

It could. But it should not. At least such ehaders should not be used
to  define  interfaces  which  are  expected  to   be   exported   to
applications.

Let's bring it to a point: U-Boot is GPLed, and this is a Good Thing (TM).

There are cases where propriatary code needs  to  be  used  (for  one
reason  or  another,  not all of them being good reasons), and U-Boot
facilitates this by means of standalone applications.

This is the intention. From  what  I  know,  standalone  applications
don't  need  to  include  any headers or link against any files which
might give reason do  even  remotely  consider  this  as  creating  a
"derived work".

I will add an appropriate comment to the  COPYING  file  (similar  to
what  Linus  uses for the Linux kernel) to make this absolutely clear
to everybody. [Checked in right now.] If anybody asks, just point him
to the COPYING file.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Life. Don't talk to me about life.      - Marvin the Paranoid Android