All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 1/1] imx: Get fec mac address from fuse
Date: Tue, 16 Nov 2010 10:34:44 +0100	[thread overview]
Message-ID: <4CE25034.4090403@denx.de> (raw)
In-Reply-To: <AANLkTi=NZurD4NkjCC6+v0A5rKmXoG6tpFZQqhkyFmFH@mail.gmail.com>

On 11/16/2010 08:16 AM, Jason Liu wrote:
>>> struct iim_regs {
>>>         u32 stat;
>>>         u32 statm;
>>>         u32 err;
>>>         u32 emask;
>>>         u32 fctl;
>>>         u32 ua;
>>>         u32 la;
>>>         u32 sdat;
>>>         u32 prev;
>>>         u32 srev;
>>>         u32 preg_p;
>>>         u32 scs0;
>>>         u32 scs1;
>>>         u32 scs2;
>>>         u32 scs3;
>>>         u32 res0[0x1f1];
>>>         u32 iim_bank_area0_1[9];
>>>         u32 mac_addr[6];
>>>         u32 iim_bank_area0_2[0x11];
>>>         u32 res1[0xe0];
>>>         u32 iim_bank_area1[0x20];
>>>         u32 res2[0xe0];
>>>         u32 iim_bank_area2[0x20];
>>>         u32 res3[0xe0];
>>>         u32 iim_bank_area3[0x20];
>>>         u32 res4[0xe0];
>>> };
>>
>> This struct is supposed to describe some register layout defined by
>> the hardware - but does the hardware know anything about teh special
>> meaning "MAC address" of this specific field, or is this an
>> interpretation that we just define as we like?

The MAC address is stored at a specific address, that is different in
each i.MX implementation. There are a lot of fields the hardware is
aware of.

> 
> This is defined according to the IC spec and it should be hw layout.
> We can read such kind of fuse just like read register.  But currently, uboot
> require that all the register array should be included into one
> structure and not
> use the *(offset + base_addr) method, this is also stefano suggestion. But for
> fuse support, there are many fuses but we only use FEC_MAC fuse
> currently, this is why
> I ask how to handle it better in uboot.
> 
> Stefano, what's your comments?

I would like to propose a structure to better clarify the internal
layout. Let me explain and check if this can be suitable for you. We
could use a union to define the different layouts for the fuse banks,
such as (the example is for the i.MX51):

typedef union fuse_bank {
	struct {
		u32 fuse_lock;
		u32 osc_jtag;
		u32 reserved0;
		u32 bt
		.....
		u32 mac_addr[6];
		....
		u32 reserved_filled[..]; /* to fill the 0x80-0xFF*/
	};
	/* Now the layout for the other fuse banks */
	struct {
		....
	};
	/*
	 * If we do not want to set now the layout, we can distinguish
	 * only between real register and reserved addresses
	 * as you already did
	 */
	 struct {
		u32 fuse_regs[0x20];
		u32 reserved[0xe0];
	}
}

And in your structure you can have something like this:

        ....
        u32 scs3;
        u32 res0[0x1f1];
	fuse_bank fuses[4];
}

You do not need to set the layout for the fuse banks 1-3, if you do not
want, but the structure is prepared if someone else will add functions
to manage the fuses.

What do you think about it ?

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

  reply	other threads:[~2010-11-16  9:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-14  3:26 [U-Boot] [PATCH v2 1/1] imx: Get fec mac address from fuse Jason Liu
2010-11-14 10:04 ` Wolfgang Denk
2010-11-14 16:59 ` Stefano Babic
2010-11-15  4:11   ` Jason Liu
2010-11-16  6:41   ` Jason Liu
2010-11-16  6:53     ` Wolfgang Denk
2010-11-16  7:16       ` Jason Liu
2010-11-16  9:34         ` Stefano Babic [this message]
2010-11-17  2:22           ` Jason Liu
2010-11-17  8:13             ` Stefano Babic
2010-11-17  8:44               ` Jason Liu
2010-11-16  9:47         ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CE25034.4090403@denx.de \
    --to=sbabic@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.