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
--
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
