Hi Benoît,

On 11/27/2012 11:27 AM, Benoît Thébaudeau wrote:
Hi Eric, Dirk,

On Tuesday, November 27, 2012 5:58:19 PM, Eric Nelson wrote:
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.

OK. The more code is in common, the easier it is to maintain.

Either way, this needs a general 'readme' for the fuse command
conventions

Sure. I'll add a doc/README.fuse to v3.

and some per-arch documentation about how to translate
between the reference manual and the command.

Yes. Should this documentation be located in the README.fuse, or in separate
README files, or in the drivers themselves, e.g. fsl_iim.c?


I think doc/readme.imx* is the right place.

Oops. It looks like we need one of these for i.MX6.

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.

Yes. Currently, it can be found in the various imx-regs.h, in the
fuse_bankx_regs structures. This information could be added to README.imx*.

There is also an imx_get_mac_from_fuse() function implemented for each i.MX SoC
to load the MAC address from the fuses for the FEC. Perhaps a similar function
with a default implementation could be created by each applicable SoC and used
by a new command in cmd_fuse.c to handle MAC addresses read/write operations.
But this would perhaps be too specific for cmd_fuse.c. It might be better to
either have only the README.imx* documentation, or to have SoC-specific commands
for the MAC addresses, like for the clock commands. What do you think?


Since this really only hits us board vendors, and is mostly used
in the production process, it's probably overkill to implement a command
to make it easier.

Best regards,
Benoît


Regards,


Eric
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to