[U-Boot] [PATCH 29/32] nitrogen6x: config: configure usb_ether

[Eric Nelson]

Thanks Stefano,

On 10/07/2014 07:36 AM, Stefano Babic wrote:
> Hi Eric,
> 
> On 06/10/2014 18:41, Eric Nelson wrote:
> 
>>> I understand the use case, but it does not always work (I mean, in all
>>> network configurations) and we regret generally having IP addresses hard
>>> coded in the default configuration.
>>>
>>
>> Can you clarify which parts (mac/IP address/both) are a problem?
>>
>> The 'usb_ether' is kind of an odd beast, in that it's a link-local
>> protocol, which is why the the IP addresses aren't read from or written
>> to a persistent environment.
> 
> This is not completely true. I mean, I understand that you want to have
> such as situation, with addresses valid only in the link host / target.
> 
> However, if a customer / user has a PC belonging to the  10.0.0.0/24
> network, there is a conflict. And this is not a rare case, because as I
> have seen in companies 10.0.0.0/8 are used more often as 192.168.0.0/16.
> 
> You can have two interface (ethernet and USB) acting on the same address
> range and packets originally sent to network are readdressed to the
> target, letting the customer without network.
> 
> I understand that you want to provide is a special case - but as you can
> see, you cannot cover all cases by setting a hard coded address.
> 

Right. I've also seen that.

It seems that 169.254.x.x is more appropriate.
	http://tools.ietf.org/html/rfc3927

>>
>> Our goal was to only require configuration of one side of the link
>> (the USB Host). It seems that without implementing a DHCP **server**,
>> this is the most convenient.
> 
> If you really want, why don't you use a script as a 6x_ ? usbrecover can
> load initially a script setting the network addresses, without
> hardcoding to the u-boot image.
> 

Chicken and egg.... The goal for usbrecover was/is to allow access to
on-board storage (SATA on Nitrogen6x, eMMC on Nitrogen6_Max)

Thankfully, the "ums" utility now functions nicely for that purpose
without using IP.

A kernel gadget still performs much better though (~2x), since you can
interleave writes to storage with USB I/O.

>>
>> The mac addresses above are ours, and we can confirm that they are
>> not in use on any other hardware,
> 
> I know that and it is exactly the same we had in the past with other
> boards. Customers can buy more as one instance of the boards, having
> then multiple boards with the same MAC address - and very bad case.
> 
>> so they're guaranteed to be unique
>> unless you happen to hook up multiple of our boards to a Host at the
>> same time.
> 
> Yes, exactly. Why do you want to restrict your sales chances ? :-D
> 

This (and all of our patches) is an attempt to increase sales by
making life easier on users.

> Seriously, hard coding mac and network addresses was strictly rejected -
> even if after your patch I have found a couple of boards doing that
> (maybe it was not seen during review, see for example  v38b.h).
> 

Understood.

>>
>> Since the configuration of network adapters on most hosts is based
>> on mac addresses, hard-coding these prevents the need to re-configure
>> each time a new board is connected to a host.
> 
> I understand that hard coding makes life easier, but I am not convinced
> it is the correct way to do, specially with IP addresses.
> 

Right.

Perhaps when we have some spare time we could write a DHCP
server component to get closer to auto-configuration, although it's not
clear how that would interact with other commands.

I appreciate your time in review and commenting.

Regards,


Eric