Patchwork [2/3] netbase: automatically bring up usb0 on beagleboard

login
register
mail settings
Submitter Paul Eggleton
Date April 15, 2011, 5 p.m.
Message ID <72ccbf03bcbec48a34d830c356e591a9139e3794.1302886579.git.paul.eggleton@linux.intel.com>
Download mbox | patch
Permalink /patch/2287/
State New, archived
Headers show

Comments

Paul Eggleton - April 15, 2011, 5 p.m.
From: Paul Eggleton <paul.eggleton@linux.intel.com>

Avoids manual configuration of the BeagleBoard xM's ethernet port (which
shows up as usb0).

Fixes [YOCTO #930]

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 .../netbase/netbase-4.45/beagleboard/interfaces    |   27 ++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
Saul Wold - April 15, 2011, 6:26 p.m.
On 04/15/2011 10:00 AM, Paul Eggleton wrote:
> From: Paul Eggleton<paul.eggleton@linux.intel.com>
>
> Avoids manual configuration of the BeagleBoard xM's ethernet port (which
> shows up as usb0).
>
> Fixes [YOCTO #930]
>
> Signed-off-by: Paul Eggleton<paul.eggleton@linux.intel.com>
> ---
>   .../netbase/netbase-4.45/beagleboard/interfaces    |   27 ++++++++++++++++++++
>   1 files changed, 27 insertions(+), 0 deletions(-)
>   create mode 100644 meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
>
I know this time would come!

So this is up for discussion in a big way!

There was some initial discussion at ELC this last week about what goes 
where and how layers are going to work moving forward.  I know that we 
are committed to the qemu* machines in oe-core (meta), and that 
currently meta-yocto contains a set of core HW (beagleboard among them), 
so the question then is should the HW specific stuff, such as this patch 
move to meta-yocto or some other layer?  There are a couple other 
recipes such as x-load and formfactor that contain HW specific files.

I believe and others will have to confirm this, that some distros may 
want to use these core files, but not via meta-yocto as a layer, or do 
those distros have these files modified differently (ie, not just 
copies, which would be bad).

This is all food for thought.

Sau!


> diff --git a/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces b/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
> new file mode 100644
> index 0000000..b6935c1
> --- /dev/null
> +++ b/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
> @@ -0,0 +1,27 @@
> +# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
> +
> +# The loopback interface
> +auto lo
> +iface lo inet loopback
> +
> +# Wireless interfaces
> +iface wlan0 inet dhcp
> +	wireless_mode managed
> +	wireless_essid any
> +	wpa-driver wext
> +	wpa-conf /etc/wpa_supplicant.conf
> +
> +iface atml0 inet dhcp
> +
> +# Wired or wireless interfaces
> +auto eth0
> +iface eth0 inet dhcp
> +iface eth1 inet dhcp
> +
> +# Ethernet/RNDIS gadget (g_ether) or LAN9514 on BeagleBoard xM
> +auto usb0
> +iface usb0 inet dhcp
> +
> +# Bluetooth networking
> +iface bnep0 inet dhcp
> +
Darren Hart - April 15, 2011, 10:37 p.m.
On 04/15/2011 10:00 AM, Paul Eggleton wrote:
> From: Paul Eggleton <paul.eggleton@linux.intel.com>
> 
> Avoids manual configuration of the BeagleBoard xM's ethernet port (which
> shows up as usb0).
> 
> Fixes [YOCTO #930]
> 
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
>  .../netbase/netbase-4.45/beagleboard/interfaces    |   27 ++++++++++++++++++++
>  1 files changed, 27 insertions(+), 0 deletions(-)
>  create mode 100644 meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
> 
> diff --git a/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces b/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
> new file mode 100644
> index 0000000..b6935c1
> --- /dev/null
> +++ b/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
> @@ -0,0 +1,27 @@
> +# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
> + 
> +# The loopback interface
> +auto lo
> +iface lo inet loopback
> +
> +# Wireless interfaces
> +iface wlan0 inet dhcp
> +	wireless_mode managed
> +	wireless_essid any
> +	wpa-driver wext
> +	wpa-conf /etc/wpa_supplicant.conf
> +
> +iface atml0 inet dhcp
> +
> +# Wired or wireless interfaces
> +auto eth0
> +iface eth0 inet dhcp
> +iface eth1 inet dhcp

Since we're adding a this specifically for the beagleboard, I don't see
the value of adding eth0 or eth1. I'm not sure about wifi and bluetooth,
I believe there are modules out there.

I suppose it doesn't hurt to have them there as examples.

> +
> +# Ethernet/RNDIS gadget (g_ether) or LAN9514 on BeagleBoard xM
> +auto usb0
> +iface usb0 inet dhcp
> +
> +# Bluetooth networking
> +iface bnep0 inet dhcp
> +
Gary Thomas - April 15, 2011, 10:43 p.m.
On 04/15/2011 04:37 PM, Darren Hart wrote:
>
>
> On 04/15/2011 10:00 AM, Paul Eggleton wrote:
>> From: Paul Eggleton<paul.eggleton@linux.intel.com>
>>
>> Avoids manual configuration of the BeagleBoard xM's ethernet port (which
>> shows up as usb0).
>>
>> Fixes [YOCTO #930]
>>
>> Signed-off-by: Paul Eggleton<paul.eggleton@linux.intel.com>
>> ---
>>   .../netbase/netbase-4.45/beagleboard/interfaces    |   27 ++++++++++++++++++++
>>   1 files changed, 27 insertions(+), 0 deletions(-)
>>   create mode 100644 meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
>>
>> diff --git a/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces b/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
>> new file mode 100644
>> index 0000000..b6935c1
>> --- /dev/null
>> +++ b/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
>> @@ -0,0 +1,27 @@
>> +# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
>> +
>> +# The loopback interface
>> +auto lo
>> +iface lo inet loopback
>> +
>> +# Wireless interfaces
>> +iface wlan0 inet dhcp
>> +	wireless_mode managed
>> +	wireless_essid any
>> +	wpa-driver wext
>> +	wpa-conf /etc/wpa_supplicant.conf
>> +
>> +iface atml0 inet dhcp
>> +
>> +# Wired or wireless interfaces
>> +auto eth0
>> +iface eth0 inet dhcp
>> +iface eth1 inet dhcp
>
> Since we're adding a this specifically for the beagleboard, I don't see
> the value of adding eth0 or eth1. I'm not sure about wifi and bluetooth,
> I believe there are modules out there.

eth1 yes, but doesn't the BeagleBoard xM have eth0?

>
> I suppose it doesn't hurt to have them there as examples.
>
>> +
>> +# Ethernet/RNDIS gadget (g_ether) or LAN9514 on BeagleBoard xM
>> +auto usb0
>> +iface usb0 inet dhcp
>> +
>> +# Bluetooth networking
>> +iface bnep0 inet dhcp
>> +
>
Darren Hart - April 15, 2011, 11:01 p.m.
On 04/15/2011 03:43 PM, Gary Thomas wrote:
> On 04/15/2011 04:37 PM, Darren Hart wrote:
>>
>>
>> On 04/15/2011 10:00 AM, Paul Eggleton wrote:
>>> From: Paul Eggleton<paul.eggleton@linux.intel.com>
>>>
>>> Avoids manual configuration of the BeagleBoard xM's ethernet port (which
>>> shows up as usb0).
>>>
>>> Fixes [YOCTO #930]
>>>
>>> Signed-off-by: Paul Eggleton<paul.eggleton@linux.intel.com>
>>> ---
>>>   .../netbase/netbase-4.45/beagleboard/interfaces    |   27 ++++++++++++++++++++
>>>   1 files changed, 27 insertions(+), 0 deletions(-)
>>>   create mode 100644 meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
>>>
>>> diff --git a/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces b/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
>>> new file mode 100644
>>> index 0000000..b6935c1
>>> --- /dev/null
>>> +++ b/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
>>> @@ -0,0 +1,27 @@
>>> +# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
>>> +
>>> +# The loopback interface
>>> +auto lo
>>> +iface lo inet loopback
>>> +
>>> +# Wireless interfaces
>>> +iface wlan0 inet dhcp
>>> +	wireless_mode managed
>>> +	wireless_essid any
>>> +	wpa-driver wext
>>> +	wpa-conf /etc/wpa_supplicant.conf
>>> +
>>> +iface atml0 inet dhcp
>>> +
>>> +# Wired or wireless interfaces
>>> +auto eth0
>>> +iface eth0 inet dhcp
>>> +iface eth1 inet dhcp
>>
>> Since we're adding a this specifically for the beagleboard, I don't see
>> the value of adding eth0 or eth1. I'm not sure about wifi and bluetooth,
>> I believe there are modules out there.
> 
> eth1 yes, but doesn't the BeagleBoard xM have eth0?

No. The onboard device is usb0.

--
Darren

> 
>>
>> I suppose it doesn't hurt to have them there as examples.
>>
>>> +
>>> +# Ethernet/RNDIS gadget (g_ether) or LAN9514 on BeagleBoard xM
>>> +auto usb0
>>> +iface usb0 inet dhcp
>>> +
>>> +# Bluetooth networking
>>> +iface bnep0 inet dhcp
>>> +
>>
>
Koen Kooi - April 16, 2011, 4:31 a.m.
Op 15 apr. 2011 om 20:26 heeft Saul Wold <sgw@linux.intel.com> het volgende geschreven:

> On 04/15/2011 10:00 AM, Paul Eggleton wrote:
>> From: Paul Eggleton<paul.eggleton@linux.intel.com>
>> 
>> Avoids manual configuration of the BeagleBoard xM's ethernet port (which
>> shows up as usb0).
>> 
>> Fixes [YOCTO #930]
>> 
>> Signed-off-by: Paul Eggleton<paul.eggleton@linux.intel.com>
>> ---
>>  .../netbase/netbase-4.45/beagleboard/interfaces    |   27 ++++++++++++++++++++
>>  1 files changed, 27 insertions(+), 0 deletions(-)
>>  create mode 100644 meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
>> 
> I know this time would come!
> 
> So this is up for discussion in a big way!
> 
> There was some initial discussion at ELC this last week about what goes where and how layers are going to work moving forward.  I know that we are committed to the qemu* machines in oe-core (meta), and that currently meta-yocto contains a set of core HW (beagleboard among them), so the question then is should the HW specific stuff, such as this patch move to meta-yocto or some other layer?  There are a couple other recipes such as x-load and formfactor that contain HW specific files.

It should live in the upstream beagleboard BSP layer, which currently is meta-texasinstruments
Richard Purdie - April 18, 2011, 7:05 a.m.
On Sat, 2011-04-16 at 06:31 +0200, Koen Kooi wrote:
> 
> Op 15 apr. 2011 om 20:26 heeft Saul Wold <sgw@linux.intel.com> het volgende geschreven:
> 
> > On 04/15/2011 10:00 AM, Paul Eggleton wrote:
> >> From: Paul Eggleton<paul.eggleton@linux.intel.com>
> >> 
> >> Avoids manual configuration of the BeagleBoard xM's ethernet port (which
> >> shows up as usb0).
> >> 
> >> Fixes [YOCTO #930]
> >> 
> >> Signed-off-by: Paul Eggleton<paul.eggleton@linux.intel.com>
> >> ---
> >>  .../netbase/netbase-4.45/beagleboard/interfaces    |   27 ++++++++++++++++++++
> >>  1 files changed, 27 insertions(+), 0 deletions(-)
> >>  create mode 100644 meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
> >> 
> > I know this time would come!
> > 
> > So this is up for discussion in a big way!
> > 
> > There was some initial discussion at ELC this last week about what
> goes where and how layers are going to work moving forward.  I know
> that we are committed to the qemu* machines in oe-core (meta), and
> that currently meta-yocto contains a set of core HW (beagleboard among
> them), so the question then is should the HW specific stuff, such as
> this patch move to meta-yocto or some other layer?  There are a couple
> other recipes such as x-load and formfactor that contain HW specific
> files.
> 
> It should live in the upstream beagleboard BSP layer, which currently
> is meta-texasinstruments

That is the goal, yes. It was agreed that until we sort out the layer
tooling, there would be some code in meta-yocto which would be a copy of
various upstream parts which includes beagleboard. Over time I'm hoping
to see these pieces converge, then we when get the tooling right it will
become automated.

Cheers,

Richard
Paul Eggleton - April 18, 2011, 9:12 a.m.
On Saturday 16 April 2011 00:01:30 Darren Hart wrote:
> On 04/15/2011 03:43 PM, Gary Thomas wrote:
> > eth1 yes, but doesn't the BeagleBoard xM have eth0?
> 
> No. The onboard device is usb0.

Looks like we're not the only ones confused by this:

https://bugs.launchpad.net/linux-linaro/+bug/622429
Paul Eggleton - April 18, 2011, 9:17 a.m.
On Friday 15 April 2011 19:26:43 Saul Wold wrote:
> There was some initial discussion at ELC this last week about what goes
> where and how layers are going to work moving forward.  I know that we
> are committed to the qemu* machines in oe-core (meta), and that
> currently meta-yocto contains a set of core HW (beagleboard among them),
> so the question then is should the HW specific stuff, such as this patch
> move to meta-yocto or some other layer?  There are a couple other
> recipes such as x-load and formfactor that contain HW specific files.

Ah, yes, you're right - we definitely don't want this file in oe-core. I should 
have pushed this particular patch to meta-yocto (in support of the 
basic/temporary beagleboard support we have there), so please ignore this one.

Cheers,
Paul
Koen Kooi - April 18, 2011, 9:30 a.m.
Op 18 apr 2011, om 11:17 heeft Paul Eggleton het volgende geschreven:

> On Friday 15 April 2011 19:26:43 Saul Wold wrote:
>> There was some initial discussion at ELC this last week about what goes
>> where and how layers are going to work moving forward.  I know that we
>> are committed to the qemu* machines in oe-core (meta), and that
>> currently meta-yocto contains a set of core HW (beagleboard among them),
>> so the question then is should the HW specific stuff, such as this patch
>> move to meta-yocto or some other layer?  There are a couple other
>> recipes such as x-load and formfactor that contain HW specific files.
> 
> Ah, yes, you're right - we definitely don't want this file in oe-core. I should 
> have pushed this particular patch to meta-yocto 

You mean meta-texasinstruments, right? Or do you yocto folks keep going to deny that there's an upstream layer for beagleboard support? If so, that doesn't bode well for manufacturers wanting to support their boards that overlap with boards in meta-yocto.
Richard Purdie - April 18, 2011, 9:53 a.m.
On Mon, 2011-04-18 at 11:30 +0200, Koen Kooi wrote:
> Op 18 apr 2011, om 11:17 heeft Paul Eggleton het volgende geschreven:
> 
> > On Friday 15 April 2011 19:26:43 Saul Wold wrote:
> >> There was some initial discussion at ELC this last week about what goes
> >> where and how layers are going to work moving forward.  I know that we
> >> are committed to the qemu* machines in oe-core (meta), and that
> >> currently meta-yocto contains a set of core HW (beagleboard among them),
> >> so the question then is should the HW specific stuff, such as this patch
> >> move to meta-yocto or some other layer?  There are a couple other
> >> recipes such as x-load and formfactor that contain HW specific files.
> > 
> > Ah, yes, you're right - we definitely don't want this file in oe-core. I should 
> > have pushed this particular patch to meta-yocto 
> 
> You mean meta-texasinstruments, right? Or do you yocto folks keep
> going to deny that there's an upstream layer for beagleboard support?

To quote my email from earlier today:

"""
> It should live in the upstream beagleboard BSP layer, which currently
> is meta-texasinstruments

That is the goal, yes. It was agreed that until we sort out the layer
tooling, there would be some code in meta-yocto which would be a copy of
various upstream parts which includes beagleboard. Over time I'm hoping
to see these pieces converge, then we when get the tooling right it will
become automated.
"""

which I'd hardly call denial. There is a plan indicated above which we
agreed to and we intend to follow unless there is a problem?

Cheers,

Richard
Koen Kooi - April 18, 2011, 10:48 a.m.
Op 18 apr 2011, om 11:53 heeft Richard Purdie het volgende geschreven:

> On Mon, 2011-04-18 at 11:30 +0200, Koen Kooi wrote:
>> Op 18 apr 2011, om 11:17 heeft Paul Eggleton het volgende geschreven:
>> 
>>> On Friday 15 April 2011 19:26:43 Saul Wold wrote:
>>>> There was some initial discussion at ELC this last week about what goes
>>>> where and how layers are going to work moving forward.  I know that we
>>>> are committed to the qemu* machines in oe-core (meta), and that
>>>> currently meta-yocto contains a set of core HW (beagleboard among them),
>>>> so the question then is should the HW specific stuff, such as this patch
>>>> move to meta-yocto or some other layer?  There are a couple other
>>>> recipes such as x-load and formfactor that contain HW specific files.
>>> 
>>> Ah, yes, you're right - we definitely don't want this file in oe-core. I should 
>>> have pushed this particular patch to meta-yocto 
>> 
>> You mean meta-texasinstruments, right? Or do you yocto folks keep
>> going to deny that there's an upstream layer for beagleboard support?
> 
> To quote my email from earlier today:
> 
> """
>> It should live in the upstream beagleboard BSP layer, which currently
>> is meta-texasinstruments
> 
> That is the goal, yes. It was agreed that until we sort out the layer
> tooling, there would be some code in meta-yocto which would be a copy of
> various upstream parts which includes beagleboard. Over time I'm hoping
> to see these pieces converge, then we when get the tooling right it will
> become automated.
> """
> 
> which I'd hardly call denial. There is a plan indicated above which we
> agreed to and we intend to follow unless there is a problem?


This 

>>>  I should 
>>> have pushed this particular patch to meta-yocto 

bit from Pauls email indicates a problem. Since that is not pushing to upstream first (implied by the use of 'copy'), but keeping fixes only in the yocto layer.
Richard Purdie - April 18, 2011, 11:04 a.m.
On Mon, 2011-04-18 at 12:48 +0200, Koen Kooi wrote:
> Op 18 apr 2011, om 11:53 heeft Richard Purdie het volgende geschreven:
> 
> > On Mon, 2011-04-18 at 11:30 +0200, Koen Kooi wrote:
> >> Op 18 apr 2011, om 11:17 heeft Paul Eggleton het volgende geschreven:
> >> 
> >>> On Friday 15 April 2011 19:26:43 Saul Wold wrote:
> >>>> There was some initial discussion at ELC this last week about what goes
> >>>> where and how layers are going to work moving forward.  I know that we
> >>>> are committed to the qemu* machines in oe-core (meta), and that
> >>>> currently meta-yocto contains a set of core HW (beagleboard among them),
> >>>> so the question then is should the HW specific stuff, such as this patch
> >>>> move to meta-yocto or some other layer?  There are a couple other
> >>>> recipes such as x-load and formfactor that contain HW specific files.
> >>> 
> >>> Ah, yes, you're right - we definitely don't want this file in oe-core. I should 
> >>> have pushed this particular patch to meta-yocto 
> >> 
> >> You mean meta-texasinstruments, right? Or do you yocto folks keep
> >> going to deny that there's an upstream layer for beagleboard support?
> > 
> > To quote my email from earlier today:
> > 
> > """
> >> It should live in the upstream beagleboard BSP layer, which currently
> >> is meta-texasinstruments
> > 
> > That is the goal, yes. It was agreed that until we sort out the layer
> > tooling, there would be some code in meta-yocto which would be a copy of
> > various upstream parts which includes beagleboard. Over time I'm hoping
> > to see these pieces converge, then we when get the tooling right it will
> > become automated.
> > """
> > 
> > which I'd hardly call denial. There is a plan indicated above which we
> > agreed to and we intend to follow unless there is a problem?
>
> This 
> 
> >>>  I should 
> >>> have pushed this particular patch to meta-yocto 
> 
> bit from Pauls email indicates a problem. Since that is not pushing to
> upstream first (implied by the use of 'copy'), but keeping fixes only
> in the yocto layer.

One step at a time. Getting pieces in roughly the right places is a good
start, then we can look at syncing up any differences.

I can start jumping up and down every time someone duplicates something
in meta-oe to be synced "later" if it would help? ;-)

I'd like to hope we can try and be a little less confrontational. A
simple request asking "could you ensure this gets submitted to
meta-texasinstruments" would have made things clear.

Cheers,

Richard
Koen Kooi - April 18, 2011, 11:17 a.m.
Op 18 apr 2011, om 13:04 heeft Richard Purdie het volgende geschreven:

> On Mon, 2011-04-18 at 12:48 +0200, Koen Kooi wrote:
>> Op 18 apr 2011, om 11:53 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Mon, 2011-04-18 at 11:30 +0200, Koen Kooi wrote:
>>>> Op 18 apr 2011, om 11:17 heeft Paul Eggleton het volgende geschreven:
>>>> 
>>>>> On Friday 15 April 2011 19:26:43 Saul Wold wrote:
>>>>>> There was some initial discussion at ELC this last week about what goes
>>>>>> where and how layers are going to work moving forward.  I know that we
>>>>>> are committed to the qemu* machines in oe-core (meta), and that
>>>>>> currently meta-yocto contains a set of core HW (beagleboard among them),
>>>>>> so the question then is should the HW specific stuff, such as this patch
>>>>>> move to meta-yocto or some other layer?  There are a couple other
>>>>>> recipes such as x-load and formfactor that contain HW specific files.
>>>>> 
>>>>> Ah, yes, you're right - we definitely don't want this file in oe-core. I should 
>>>>> have pushed this particular patch to meta-yocto 
>>>> 
>>>> You mean meta-texasinstruments, right? Or do you yocto folks keep
>>>> going to deny that there's an upstream layer for beagleboard support?
>>> 
>>> To quote my email from earlier today:
>>> 
>>> """
>>>> It should live in the upstream beagleboard BSP layer, which currently
>>>> is meta-texasinstruments
>>> 
>>> That is the goal, yes. It was agreed that until we sort out the layer
>>> tooling, there would be some code in meta-yocto which would be a copy of
>>> various upstream parts which includes beagleboard. Over time I'm hoping
>>> to see these pieces converge, then we when get the tooling right it will
>>> become automated.
>>> """
>>> 
>>> which I'd hardly call denial. There is a plan indicated above which we
>>> agreed to and we intend to follow unless there is a problem?
>> 
>> This 
>> 
>>>>> I should 
>>>>> have pushed this particular patch to meta-yocto 
>> 
>> bit from Pauls email indicates a problem. Since that is not pushing to
>> upstream first (implied by the use of 'copy'), but keeping fixes only
>> in the yocto layer.
> 
> One step at a time. Getting pieces in roughly the right places is a good
> start, then we can look at syncing up any differences.
> 
> I can start jumping up and down every time someone duplicates something
> in meta-oe to be synced "later" if it would help? ;-)

That would actually be very helpfull, there's too much crud in there that needs a cleanup. Which is slowly improving, though :)

regards,

Koen
Darren Hart - April 18, 2011, 4:07 p.m.
On 04/18/2011 02:12 AM, Paul Eggleton wrote:
> On Saturday 16 April 2011 00:01:30 Darren Hart wrote:
>> On 04/15/2011 03:43 PM, Gary Thomas wrote:
>>> eth1 yes, but doesn't the BeagleBoard xM have eth0?
>>
>> No. The onboard device is usb0.
> 
> Looks like we're not the only ones confused by this:
> 
> https://bugs.launchpad.net/linux-linaro/+bug/622429
> 

Perhaps I am missing some context, but I don't see any problem with
having the name usb0. In fact, I find it informative, and helps to
explain why things like tftp don't work from u-boot, etc.

While the community remains divided, I plan to stay in the usb0 camp.

Patch

diff --git a/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces b/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
new file mode 100644
index 0000000..b6935c1
--- /dev/null
+++ b/meta/recipes-core/netbase/netbase-4.45/beagleboard/interfaces
@@ -0,0 +1,27 @@ 
+# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
+ 
+# The loopback interface
+auto lo
+iface lo inet loopback
+
+# Wireless interfaces
+iface wlan0 inet dhcp
+	wireless_mode managed
+	wireless_essid any
+	wpa-driver wext
+	wpa-conf /etc/wpa_supplicant.conf
+
+iface atml0 inet dhcp
+
+# Wired or wireless interfaces
+auto eth0
+iface eth0 inet dhcp
+iface eth1 inet dhcp
+
+# Ethernet/RNDIS gadget (g_ether) or LAN9514 on BeagleBoard xM
+auto usb0
+iface usb0 inet dhcp
+
+# Bluetooth networking
+iface bnep0 inet dhcp
+