Strategy for permament extended/EUI64 address writing and updating in atusb

Strategy for permament extended/EUI64 address writing and updating in atusb

[Stefan Schmidt]

Hello.

Background:
With the atusb device we have the possibility to store some data in 
EEPROM as non-volatile memory. Qi hardware as the company behind this 
devices also has an IEEE OUI assigned which we can use for a range of 
valiud and unique EUI64 addresses we can use as permanent extended 
addresses in IEEE 802.15.4

http://en.qi-hardware.com/wiki/IEEE_OUI_assignments

Status:
o I enhanced the firmware to access the EEPROM to allow write and 
update/read operations
o A new command allows the reading of the whole EUI64 over usb (ATUSB_EUI64)
o The ATUSB_EUI64 command is used in the atusb driver to read the 
address during probe and set it correctly for the default wpan0 
interface. This basically replaces the
ieee802154_random_extended_addr() call.
o The above is tested and works fine with a device being unplugged and 
re-plugged and still showing the permanent address read from EEPROM.

Update/Write Strategy:
Right now i changed the firmware to intercept write to the IEEE_ADDR 
register which gets updated whenever the hardware address filter 
callback fires. (adding a new interface with extended address and 
bringing it up is such a case). This is hacky and comes with some side 
effects like your "permanent" address gets overridden by bringing up an 
interface :)

I also thought about exposing a sysfs entry to write the new address. 
This would allow an easy way to change it right through the kernel 
driver. Easy to use but also kind of violates the idea of having a 
"permanent" address which is not touched by the driver at all. I chatted 
a bit with Phobe on IRC about it and really the solution that seems to 
make most sense is to have a small host utility that uses libusb to read 
and write the EUI64 to the device. It would be combined with a simple 
list of known serial numbers and their mapped allocated address.

For this I will remove the intercepting part of the firmware and expose 
the writes through another ATUSB command over USB.

Let me know if you think this goes into the wrong direction. I will be 
working on this over the next days.

regards
Stefan Schmidt

Re: Strategy for permament extended/EUI64 address writing and updating in atusb

[Marcel Holtmann]

Hi Stefan,

> Background:
> With the atusb device we have the possibility to store some data in EEPROM as non-volatile memory. Qi hardware as the company behind this devices also has an IEEE OUI assigned which we can use for a range of valiud and unique EUI64 addresses we can use as permanent extended addresses in IEEE 802.15.4
> 
> http://en.qi-hardware.com/wiki/IEEE_OUI_assignments
> 
> Status:
> o I enhanced the firmware to access the EEPROM to allow write and update/read operations
> o A new command allows the reading of the whole EUI64 over usb (ATUSB_EUI64)
> o The ATUSB_EUI64 command is used in the atusb driver to read the address during probe and set it correctly for the default wpan0 interface. This basically replaces the
> ieee802154_random_extended_addr() call.
> o The above is tested and works fine with a device being unplugged and re-plugged and still showing the permanent address read from EEPROM.
> 
> Update/Write Strategy:
> Right now i changed the firmware to intercept write to the IEEE_ADDR register which gets updated whenever the hardware address filter callback fires. (adding a new interface with extended address and bringing it up is such a case). This is hacky and comes with some side effects like your "permanent" address gets overridden by bringing up an interface :)
> 
> I also thought about exposing a sysfs entry to write the new address. This would allow an easy way to change it right through the kernel driver. Easy to use but also kind of violates the idea of having a "permanent" address which is not touched by the driver at all. I chatted a bit with Phobe on IRC about it and really the solution that seems to make most sense is to have a small host utility that uses libusb to read and write the EUI64 to the device. It would be combined with a simple list of known serial numbers and their mapped allocated address.

I am against sysfs entries for drivers to do some setting of their addresses. Especially if these are permanent and change the EEPROM data.

> For this I will remove the intercepting part of the firmware and expose the writes through another ATUSB command over USB.
> 
> Let me know if you think this goes into the wrong direction. I will be working on this over the next days.

I have the feeling that you might want to push that device into a special mode to allow programming of these settings and not allow this at runtime. Same as we do not allow DFU based firmware upgrade at runtime. So maybe you want it to go into DFU upgrade mode and have extra support for certain control messages to allow configuration.

For runtime based device address configuration (in case a device does not have one at all), I prefer looking at doc/mgmt-api.txt in BlueZ and our unconfigured state and Set Public Address commands. We solved this problem nicely in case the host OS has access to some sort of one-time non-volatile memory area.

Regards

Marcel

Re: Strategy for permament extended/EUI64 address writing and updating in atusb

[Alexander Aring]

On Wed, Jun 10, 2015 at 04:49:17PM +0200, Marcel Holtmann wrote:
> Hi Stefan,
> 
> > Background:
> > With the atusb device we have the possibility to store some data in EEPROM as non-volatile memory. Qi hardware as the company behind this devices also has an IEEE OUI assigned which we can use for a range of valiud and unique EUI64 addresses we can use as permanent extended addresses in IEEE 802.15.4
> > 
> > http://en.qi-hardware.com/wiki/IEEE_OUI_assignments
> > 
> > Status:
> > o I enhanced the firmware to access the EEPROM to allow write and update/read operations
> > o A new command allows the reading of the whole EUI64 over usb (ATUSB_EUI64)
> > o The ATUSB_EUI64 command is used in the atusb driver to read the address during probe and set it correctly for the default wpan0 interface. This basically replaces the
> > ieee802154_random_extended_addr() call.
> > o The above is tested and works fine with a device being unplugged and re-plugged and still showing the permanent address read from EEPROM.
> > 
> > Update/Write Strategy:
> > Right now i changed the firmware to intercept write to the IEEE_ADDR register which gets updated whenever the hardware address filter callback fires. (adding a new interface with extended address and bringing it up is such a case). This is hacky and comes with some side effects like your "permanent" address gets overridden by bringing up an interface :)
> > 
> > I also thought about exposing a sysfs entry to write the new address. This would allow an easy way to change it right through the kernel driver. Easy to use but also kind of violates the idea of having a "permanent" address which is not touched by the driver at all. I chatted a bit with Phobe on IRC about it and really the solution that seems to make most sense is to have a small host utility that uses libusb to read and write the EUI64 to the device. It would be combined with a simple list of known serial numbers and their mapped allocated address.
> 
> I am against sysfs entries for drivers to do some setting of their addresses. Especially if these are permanent and change the EEPROM data.
> 
> > For this I will remove the intercepting part of the firmware and expose the writes through another ATUSB command over USB.
> > 
> > Let me know if you think this goes into the wrong direction. I will be working on this over the next days.
> 
> I have the feeling that you might want to push that device into a special mode to allow programming of these settings and not allow this at runtime. Same as we do not allow DFU based firmware upgrade at runtime. So maybe you want it to go into DFU upgrade mode and have extra support for certain control messages to allow configuration.
> 

I think the endpoint 0 is different between bootloader (dfu) and the
application (atusb). Maybe then add this functionality for the
bootloader only.

Then it should fine when the userspace tool sends a reset and then
having some timeslot (before atusb starts)  to send the permanent address
settings over the usb bus.

Not sure if this is true and that's how dfu works.

> For runtime based device address configuration (in case a device does not have one at all), I prefer looking at doc/mgmt-api.txt in BlueZ and our unconfigured state and Set Public Address commands. We solved this problem nicely in case the host OS has access to some sort of one-time non-volatile memory area.
> 

I look right now into [0]. What do you mean with 'host OS has access to
some sort of one-time non-volatile memory area.', is this really the
host OS. Means I can connect a eeprom at my i2c bus and store some
public address which is read out by some userspace tool and sets the address
to the specific "controller"?

I was think about to implement such thing like ethernet it does. The
bootloader set's some parameter/device tree argument and then the driver
"could" parse it, if the driver cares about that. See [1], which adds
the device-tree binding. This can be overwritten by the bootloader and
the bootloader, which probably has an enviornment can set this addrss
then. Maybe this behaviour is some outdated and there exists some better
solution. Anyway this is also right now for non plug&play transceivers
like the SPI ones. For USB, the transceiver should store the permanent
address.

- Alex

[0] http://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/mgmt-api.txt#n2180
[1] http://www.spinics.net/lists/linux-wpan/msg01504.html

Re: Strategy for permament extended/EUI64 address writing and updating in atusb

[Marcel Holtmann]

Hi Alex,

>>> Background:
>>> With the atusb device we have the possibility to store some data in EEPROM as non-volatile memory. Qi hardware as the company behind this devices also has an IEEE OUI assigned which we can use for a range of valiud and unique EUI64 addresses we can use as permanent extended addresses in IEEE 802.15.4
>>> 
>>> http://en.qi-hardware.com/wiki/IEEE_OUI_assignments
>>> 
>>> Status:
>>> o I enhanced the firmware to access the EEPROM to allow write and update/read operations
>>> o A new command allows the reading of the whole EUI64 over usb (ATUSB_EUI64)
>>> o The ATUSB_EUI64 command is used in the atusb driver to read the address during probe and set it correctly for the default wpan0 interface. This basically replaces the
>>> ieee802154_random_extended_addr() call.
>>> o The above is tested and works fine with a device being unplugged and re-plugged and still showing the permanent address read from EEPROM.
>>> 
>>> Update/Write Strategy:
>>> Right now i changed the firmware to intercept write to the IEEE_ADDR register which gets updated whenever the hardware address filter callback fires. (adding a new interface with extended address and bringing it up is such a case). This is hacky and comes with some side effects like your "permanent" address gets overridden by bringing up an interface :)
>>> 
>>> I also thought about exposing a sysfs entry to write the new address. This would allow an easy way to change it right through the kernel driver. Easy to use but also kind of violates the idea of having a "permanent" address which is not touched by the driver at all. I chatted a bit with Phobe on IRC about it and really the solution that seems to make most sense is to have a small host utility that uses libusb to read and write the EUI64 to the device. It would be combined with a simple list of known serial numbers and their mapped allocated address.
>> 
>> I am against sysfs entries for drivers to do some setting of their addresses. Especially if these are permanent and change the EEPROM data.
>> 
>>> For this I will remove the intercepting part of the firmware and expose the writes through another ATUSB command over USB.
>>> 
>>> Let me know if you think this goes into the wrong direction. I will be working on this over the next days.
>> 
>> I have the feeling that you might want to push that device into a special mode to allow programming of these settings and not allow this at runtime. Same as we do not allow DFU based firmware upgrade at runtime. So maybe you want it to go into DFU upgrade mode and have extra support for certain control messages to allow configuration.
>> 
> 
> I think the endpoint 0 is different between bootloader (dfu) and the
> application (atusb). Maybe then add this functionality for the
> bootloader only.

the device resets and re-enumerates. So yes, the control endpoint will be different in DFU mode than in normal operation mode. So yes, this might be better some vendor control commands.

> Then it should fine when the userspace tool sends a reset and then
> having some timeslot (before atusb starts)  to send the permanent address
> settings over the usb bus.
> 
> Not sure if this is true and that's how dfu works.

Correct me if I am wrong, but loading the firmware is a one time thing. It is persistent. So in case of power loss (aka unplug), next time around you do not have to load firmware again.

>> For runtime based device address configuration (in case a device does not have one at all), I prefer looking at doc/mgmt-api.txt in BlueZ and our unconfigured state and Set Public Address commands. We solved this problem nicely in case the host OS has access to some sort of one-time non-volatile memory area.
>> 
> 
> I look right now into [0]. What do you mean with 'host OS has access to
> some sort of one-time non-volatile memory area.', is this really the
> host OS. Means I can connect a eeprom at my i2c bus and store some
> public address which is read out by some userspace tool and sets the address
> to the specific "controller"?

If the driver can load the persistent and permanent address from somewhere, then it should do that. I am talking in the cases where it does not. And in Bluetooth a lot of manufactures just have the BD_ADDR stored in their own one-time memory or even the host filesystem.

It is too keep the chips cheap since you buy them without IEEE assigned address.

> I was think about to implement such thing like ethernet it does. The
> bootloader set's some parameter/device tree argument and then the driver
> "could" parse it, if the driver cares about that. See [1], which adds
> the device-tree binding. This can be overwritten by the bootloader and
> the bootloader, which probably has an enviornment can set this addrss
> then. Maybe this behaviour is some outdated and there exists some better
> solution. Anyway this is also right now for non plug&play transceivers
> like the SPI ones. For USB, the transceiver should store the permanent
> address.

Having to update DT to change an address is stupid. It might be fine with a minimal overlay DT for just the address, but otherwise it is still stupid.

If you need to operate a valid address, then it is either present when the device gets powered on or it is not. In case it is not, then let userspace program it.

This clearly is for the case where an unplug/replug would loose the address. If you write it once and it is persistent, then that is different. That is outside the scope of nl802154 an hardware specific.

Regards

Marcel

Re: Strategy for permament extended/EUI64 address writing and updating in atusb

[Alexander Aring]

On Wed, Jun 10, 2015 at 05:38:59PM +0200, Marcel Holtmann wrote:
> Hi Alex,
> 
> >>> Background:
> >>> With the atusb device we have the possibility to store some data in EEPROM as non-volatile memory. Qi hardware as the company behind this devices also has an IEEE OUI assigned which we can use for a range of valiud and unique EUI64 addresses we can use as permanent extended addresses in IEEE 802.15.4
> >>> 
> >>> http://en.qi-hardware.com/wiki/IEEE_OUI_assignments
> >>> 
> >>> Status:
> >>> o I enhanced the firmware to access the EEPROM to allow write and update/read operations
> >>> o A new command allows the reading of the whole EUI64 over usb (ATUSB_EUI64)
> >>> o The ATUSB_EUI64 command is used in the atusb driver to read the address during probe and set it correctly for the default wpan0 interface. This basically replaces the
> >>> ieee802154_random_extended_addr() call.
> >>> o The above is tested and works fine with a device being unplugged and re-plugged and still showing the permanent address read from EEPROM.
> >>> 
> >>> Update/Write Strategy:
> >>> Right now i changed the firmware to intercept write to the IEEE_ADDR register which gets updated whenever the hardware address filter callback fires. (adding a new interface with extended address and bringing it up is such a case). This is hacky and comes with some side effects like your "permanent" address gets overridden by bringing up an interface :)
> >>> 
> >>> I also thought about exposing a sysfs entry to write the new address. This would allow an easy way to change it right through the kernel driver. Easy to use but also kind of violates the idea of having a "permanent" address which is not touched by the driver at all. I chatted a bit with Phobe on IRC about it and really the solution that seems to make most sense is to have a small host utility that uses libusb to read and write the EUI64 to the device. It would be combined with a simple list of known serial numbers and their mapped allocated address.
> >> 
> >> I am against sysfs entries for drivers to do some setting of their addresses. Especially if these are permanent and change the EEPROM data.
> >> 
> >>> For this I will remove the intercepting part of the firmware and expose the writes through another ATUSB command over USB.
> >>> 
> >>> Let me know if you think this goes into the wrong direction. I will be working on this over the next days.
> >> 
> >> I have the feeling that you might want to push that device into a special mode to allow programming of these settings and not allow this at runtime. Same as we do not allow DFU based firmware upgrade at runtime. So maybe you want it to go into DFU upgrade mode and have extra support for certain control messages to allow configuration.
> >> 
> > 
> > I think the endpoint 0 is different between bootloader (dfu) and the
> > application (atusb). Maybe then add this functionality for the
> > bootloader only.
> 
> the device resets and re-enumerates. So yes, the control endpoint will be different in DFU mode than in normal operation mode. So yes, this might be better some vendor control commands.
> 
> > Then it should fine when the userspace tool sends a reset and then
> > having some timeslot (before atusb starts)  to send the permanent address
> > settings over the usb bus.
> > 
> > Not sure if this is true and that's how dfu works.
> 
> Correct me if I am wrong, but loading the firmware is a one time thing. It is persistent. So in case of power loss (aka unplug), next time around you do not have to load firmware again.
> 

What I meant here was the "general updating procedure for the address".

1. Device resets -> going into bootloader
2. You have some timeslot that you need to tell the transceiver "I want
   to programm the address" - in this time the bootloader runs. 

This is solved by of course some libusb utility program which can do the
complete stuff for you. I just meant in the timeslot of 2 the "special"
endpoint is available to do programming stuff.

> >> For runtime based device address configuration (in case a device does not have one at all), I prefer looking at doc/mgmt-api.txt in BlueZ and our unconfigured state and Set Public Address commands. We solved this problem nicely in case the host OS has access to some sort of one-time non-volatile memory area.
> >> 
> > 
> > I look right now into [0]. What do you mean with 'host OS has access to
> > some sort of one-time non-volatile memory area.', is this really the
> > host OS. Means I can connect a eeprom at my i2c bus and store some
> > public address which is read out by some userspace tool and sets the address
> > to the specific "controller"?
> 
> If the driver can load the persistent and permanent address from somewhere, then it should do that. I am talking in the cases where it does not. And in Bluetooth a lot of manufactures just have the BD_ADDR stored in their own one-time memory or even the host filesystem.
> 

Okay, but then you could also use any network manager to do this stuff
on boot time via generic interface, which "ip" utility also use.

btw. for SPI transceivers I also don't saw any persistent storage. Also
no serial id or something else which could be used to generate an
extended address from.

> It is too keep the chips cheap since you buy them without IEEE assigned address.
> 
> > I was think about to implement such thing like ethernet it does. The
> > bootloader set's some parameter/device tree argument and then the driver
> > "could" parse it, if the driver cares about that. See [1], which adds
> > the device-tree binding. This can be overwritten by the bootloader and
> > the bootloader, which probably has an enviornment can set this addrss
> > then. Maybe this behaviour is some outdated and there exists some better
> > solution. Anyway this is also right now for non plug&play transceivers
> > like the SPI ones. For USB, the transceiver should store the permanent
> > address.
> 
> Having to update DT to change an address is stupid. It might be fine with a minimal overlay DT for just the address, but otherwise it is still stupid.
> 

Should I assume this opinion now as review comment for the device tree
patch? Or it's only the mechanism that the bootloader should overwrite
it. This works somehow "persistent" for static systems.

This mechanism also not means that the bootloader doesn't update the
device tree. It's just that the user has some possibility to add a
extended-address for this static connected SPI device, which the user
can configure over the dt.

I only know that some bootloader enviornments mechanism do the updating
on the fly before starting the kernel. Then it's just stupid that the
bootloader does that.

> If you need to operate a valid address, then it is either present when the device gets powered on or it is not. In case it is not, then let userspace program it.
> 

The current solution is more:

All driver _should_ have some permanent extended address source. Doesn't
matter where it comes frome, at last a driver can always call that a
random one can be generated. If a driver doesn't set a permanent
extended address, then I declare it as a bug inside the driver.

So we are sure that the driver always sets some valid address. After
booting then a network manager can set this address. Then the extended
address is stored on the host filesystem.

In general there should be some priority of getting the extended address
like:

1. get it from some r/w persistent storage
2. (if 1. fails). get it from some read only persistent storage
3. (if 2. fails). try to get from device tree (in case of SPI transceivers, for now)
4. (if 3. fails). generate a random one

Nevertheless the last option should be always that the driver generates
a random one.

> This clearly is for the case where an unplug/replug would loose the address. If you write it once and it is persistent, then that is different. That is outside the scope of nl802154 an hardware specific.

Yes, persistent is just when I plugged in into PC A then it's also the
same when I plug my transceiver into PC B. For SPI transceivers, you
cannot simple unplug and replug the transceiver at runtime, that's why
the above solution for device tree setting should _maybe_ come in for
SPI transceivers. The driver can deal where the persistent address
source comes from.

- Alex

Re: Strategy for permament extended/EUI64 address writing and updating in atusb

[Werner Almesberger]

Alexander Aring wrote:
> I think the endpoint 0 is different between bootloader (dfu) and the
> application (atusb). Maybe then add this functionality for the
> bootloader only.

If you add it to the boot loader, then you need to flash your
enhanced boot loader via in-circuit programming (or find a way
to bypass the write protection. NB: no such way should exist.)
Not everyone may find that convenient ;)

I'd leave the boot loader as it is and just add a new operation
to the application part of the firmware.

- Werner

Re: Strategy for permament extended/EUI64 address writing and updating in atusb

[Alexander Aring]

On Wed, Jun 10, 2015 at 06:23:51PM -0300, Werner Almesberger wrote:
> Alexander Aring wrote:
> > I think the endpoint 0 is different between bootloader (dfu) and the
> > application (atusb). Maybe then add this functionality for the
> > bootloader only.
> 
> If you add it to the boot loader, then you need to flash your
> enhanced boot loader via in-circuit programming (or find a way
> to bypass the write protection. NB: no such way should exist.)
> Not everyone may find that convenient ;)
> 
> I'd leave the boot loader as it is and just add a new operation
> to the application part of the firmware.
> 

yea, this was just an idea because Marcel said:

"... you might want to push that device into a special mode to allow
programming of these settings"

and that's for me the dfu mode. My idea was just make the "new
operation" accessable in dfu endpoint only.

Nevertheless I am also fine with normal application operation, or making
some special bus access cycles to get into "privileged mode" or
something else, everything is possible.

- Alex

Re: Strategy for permament extended/EUI64 address writing and updating in atusb

[Marcel Holtmann]

Hi Alex,

>>> I think the endpoint 0 is different between bootloader (dfu) and the
>>> application (atusb). Maybe then add this functionality for the
>>> bootloader only.
>> 
>> If you add it to the boot loader, then you need to flash your
>> enhanced boot loader via in-circuit programming (or find a way
>> to bypass the write protection. NB: no such way should exist.)
>> Not everyone may find that convenient ;)
>> 
>> I'd leave the boot loader as it is and just add a new operation
>> to the application part of the firmware.
>> 
> 
> yea, this was just an idea because Marcel said:
> 
> "... you might want to push that device into a special mode to allow
> programming of these settings"
> 
> and that's for me the dfu mode. My idea was just make the "new
> operation" accessable in dfu endpoint only.
> 
> Nevertheless I am also fine with normal application operation, or making
> some special bus access cycles to get into "privileged mode" or
> something else, everything is possible.

I would not do that at runtime mode unless you have an easy way to re-enmuerate that device. Reason is that changing settings like the address should be only be done when the device is in a special mode.

So at minimum that needs to be when the device is powered off or something. And if you change the address it re-enumerates again so that userspace can know that the address has changed.

For a permanent address, that is normally done in a special mode when you provision it. Be that DFU mode or some other mode you push the device into.

Regards

Marcel

Re: Strategy for permament extended/EUI64 address writing and updating in atusb

[Stefan Schmidt]

Hello.

I'm surprised how much interest this sparked. :)

Let's try to sum things up here from my view. See below.

On 11/06/15 10:23, Marcel Holtmann wrote:
> Hi Alex,
>
>>>> I think the endpoint 0 is different between bootloader (dfu) and the
>>>> application (atusb). Maybe then add this functionality for the
>>>> bootloader only.
>>> If you add it to the boot loader, then you need to flash your
>>> enhanced boot loader via in-circuit programming (or find a way
>>> to bypass the write protection. NB: no such way should exist.)
>>> Not everyone may find that convenient ;)
>>>
>>> I'd leave the boot loader as it is and just add a new operation
>>> to the application part of the firmware.
>>>
>> yea, this was just an idea because Marcel said:
>>
>> "... you might want to push that device into a special mode to allow
>> programming of these settings"
>>
>> and that's for me the dfu mode. My idea was just make the "new
>> operation" accessable in dfu endpoint only.
>>
>> Nevertheless I am also fine with normal application operation, or making
>> some special bus access cycles to get into "privileged mode" or
>> something else, everything is possible.
> I would not do that at runtime mode unless you have an easy way to re-enmuerate that device. Reason is that changing settings like the address should be only be done when the device is in a special mode.
>
> So at minimum that needs to be when the device is powered off or something. And if you change the address it re-enumerates again so that userspace can know that the address has changed.
>
> For a permanent address, that is normally done in a special mode when you provision it. Be that DFU mode or some other mode you push the device into.
>

Lets quickly handle the kernel driver side as this is easier and people 
should be able to agree on.

As a summary for the kernel driver side this is what I want it to be:
o During probe we check if the firmware version is 0.3 (not released but 
should contain this feature)
o If fw is to old we use a random address
o If the fw is new enough we read the address from EEPROM
o If the address is != 00:00:00:00:00:00:00:00 and a valid EUI64 we use 
that one, if not fall back to random
o No write access what so ever is going through the driver (no sysfs, etc)


Coming back to the fw side now. I agree that the best point in time for 
writing this information is when you provision it. In the case of ATUSB 
this happened when the bootloader got flashed. This happens with a avr 
programmer I don't have (like almost all users of the current ATUSB 
devices). The bootloader is not much more besides a steppi9ng stone to 
offer DFU functionality and executing an application which in our case 
is the real firmware for ATUSB. While I can change bootloader as well as 
application code I can only flash the later one.

Which means I need to implement the EUI64 writing to EEPROM solution 
over an interface that is available when the application runs, normal 
runtime. I see two things I can offer to make you a bit more comfortable 
with this.
1) The host utility which changes the address can try to detach the 
kernel driver over libusb
2) The firmware can issue a MCU reset after the address was written 
which would force a USB reset and re-enumerate.

How does that sound to you?

The perfect solution would be to have this done during 
production/provisioning or at least as part of the bootloader. I don't 
think this is feasible for the current ATUSB devices out there but if 
there will ever be another production run of them we should try to 
handle it that way.

regards
Stefan Schmidt

Re: Strategy for permament extended/EUI64 address writing and updating in atusb

[Werner Almesberger]

Stefan Schmidt wrote:
> 2) The firmware can issue a MCU reset after the address was written
> which would force a USB reset and re-enumerate.

Or just copy EEPROM content to RAM on application start ("reset")
and on USB bus reset, and make the application that writes the
EEPROM do a USB bus reset.

That way, the address won't change while the device is in active
use, no matter how often you write to the EEPROM. And a USB bus
reset is supposed to reset the whole dependency chain anyway, so
that should be a safe moment for propagating the address change.

Oh, and for completeness, a plan B could be to attach the address
to the application binary (so you read it from Flash, not EEPROM).
Then you could use DFU. But you'd be trading one can of worms for
another one.

> The perfect solution would be to have this done [...]

Yup, once time travel finally becomes mainstream, engineers will
laugh about our clumsy work-arounds ;-)

- Werner

Re: Strategy for permament extended/EUI64 address writing and updating in atusb

[Stefan Schmidt]

Hello.

On 11/06/15 14:48, Werner Almesberger wrote:
> Stefan Schmidt wrote:
>> 2) The firmware can issue a MCU reset after the address was written
>> which would force a USB reset and re-enumerate.
> Or just copy EEPROM content to RAM on application start ("reset")
> and on USB bus reset, and make the application that writes the
> EEPROM do a USB bus reset.
Which means we would not write the content from RAM to EEPROM if we pull 
the device out of the pc without doing a usb reset before? How would 
that be more safe compared to what I proposed above?

> That way, the address won't change while the device is in active
> use, no matter how often you write to the EEPROM. And a USB bus
> reset is supposed to reset the whole dependency chain anyway, so
> that should be a safe moment for propagating the address change.

Hmm, I really have a hard time to the the benefit here. Maybe I miss 
some use cases you folks see and I don't.
I see the following:
o Device is connected and the atusb driver is loaded and driving the device.
    o It read the EUI64 from EEPROM during probe and is no further 
touching it at all
    o We write a new EUI64 with a host utility behind the back of the atusb.
    o Its not mapped or anything so the driver will keep working fine 
with the EUI64 it got during probe.
    o Furthermore, after the EEPROM write a mcu_reset() done to 
re-enumerate on the USB bus
    o The atusb driver sees the device going away and tears itself down
    o The device appears again on the bus, atusb gets called and probes 
the device to find the newly written address.
    o Done
o The device is connected but no atusb driver is loaded or accessing the 
device
    o The problem does not exist at all and one can update the EUI64 
without problems.

What do I miss that makes this more problematic?

I have to say that this simple task which I started for my pure 
convenience (and the maybe handful of atusb users) turns out to get 
something way bigger.

> Oh, and for completeness, a plan B could be to attach the address
> to the application binary (so you read it from Flash, not EEPROM).
> Then you could use DFU. But you'd be trading one can of worms for
> another one.
Which would mean each user would have to make sure the firmware gets 
modified before flashing and flashed to the right device for _every_ fw 
update. Not compelling at all if you ask me. We have an EEPROM available 
to store such device properties so we better use it.

regards
Stefan Schmidt

Re: Strategy for permament extended/EUI64 address writing and updating in atusb

[Werner Almesberger]

Stefan Schmidt wrote:
>    o It read the EUI64 from EEPROM during probe and is no further
> touching it at all

That's then functionally equivalent to the "copying to RAM"
I proposed.

>    o Furthermore, after the EEPROM write a mcu_reset() done to
> re-enumerate on the USB bus

I'm just saying that we already have a generic mechanism for
getting the device to re-enumerate.

> Not compelling at all if you ask me. We have an EEPROM
> available to store such device properties so we better use it.

While I disagree with any reasoning that one should use the
EEPROM because it's there, I also think that attaching the
address to the firmware binary would add too many operational
complications.

- Werner