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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to