[U-Boot] [PATCH 3/5] Add fuse API and commands

[Eric Nelson]

On 11/27/2012 12:19 AM, Dirk Behme wrote:
> On 26.11.2012 17:03, Benoît Thébaudeau wrote:
>> Hi Eric, all,
>>
>> On Thursday, August 23, 2012 3:23:20 PM, Eric Nelson wrote:
>>> On 08/23/2012 03:31 AM, Stefano Babic wrote:
>>>> On 22/08/2012 12:43, Dirk Behme wrote:
>>>>> On 14.08.2012 14:52, Benoît Thébaudeau wrote:
>>>>>> This can be useful for fuse-like hardware, OTP SoC options, etc.
>>>>> For i.MX6, I have a port of the OTP support from Freescale's
>>>>> U-Boot to
>>>>> our mainline U-Boot in the queue [1].
>>>>>
>>>>> As I don't have the overview over the various i.MXxx SoCs and
>>>>> don't
>>>>> understand much of this patch below: Should this implement the
>>>>> same
>>>>> functionality like my patch [1] for i.MX6?
>>>> I have not checked the details. but seeing the code it looks that
>>>> the
>>>> procedure to read / write are different. In this case, a further
>>>> driver
>>>> is ok.
>>>>
>>>> Anyway, you should take a look if your patches can be used on a mxs
>>>> (MX28) device, because they should be closer. And then I will not
>>>> like
>>>> to have a driver for each SOC.
>>>>
>>>> Generally, I think we should use the approach of the common command
>>>> and
>>>> a specific fuse implementation. Then this API should be used by
>>>> your
>>>> patches as well.
>>>>
>>> I agree.
>>>
>>> The use of the fuse API will likely result in more code than the
>>> imxotp implementation, and more importantly, it will make the usage
>>> more confusing by introducing terms bank and row.
>>>
>>> Reading and writing fuses is probably not an area that we want
>>> confusion.
>>
>> I am looking again into this question now that I have the i.MX6 reference
>> manual.
>>
>> I don't see any difference between IIM and OCOTP features:
>>  - There are still banks: They exist as seen from the controller, even
>> if they
>>    don't exist physically in the efusebox. See 46.2.1 and OCOTP memory
>> map
>>    ("Value of OTP Bankx Wordy" shadow registers).
>>  - Rows are named words.
>>  - The read operations are read accesses to the shadow registers.
>>  - The sense operations are direct fuse reads (shadow reload + read), as
>>    explained by the steps in 46.2.1.2.
>>  - The prog operations are the programming of the fuses, as explained
>> by the
>>    steps in 46.2.1.3.
>>  - The override operations are simple write accesses to the shadow
>> registers, as
>>    explained in 46.2.1.3.
>>
>> As to the vocabulary used, the differences are:
>>  - "row" -> "word".
>>  - "sense" -> "direct read".
>>
>> Hence, the fuse API applies very well in this case too.
>
> Do you like to update/rebase your patches to the latest U-Boot and
> re-send? Maybe it makes sense to discuss your patches again, then?
>
> Eric: What do you think?
>

Hi Benoit and Dirk,

I don't have strong feelings one way or the other. If left to
me, I'd probably stick with the imxotp command, but Benoît has
clearly walked through the details and we're not talking about
a lot of code either way.

Either way, this needs a general 'readme' for the fuse command
conventions and some per-arch documentation about how to translate
between the reference manual and the command.

It also seems appropriate to have documentation somewhere about
the conventions used for things like mac address storage. AFAIK,
the only place to find the mapping of OTP locations used for this
is in the various bits of code that implement it.

Regards,


Eric