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
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
