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

[Stefan Schmidt <stefan@osg.samsung.com>]

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