• Home
  • Help
  • Search
  • Login
  • Register
Pages: [1]
Author Topic: 2.5V Connector J2 Caution!  (Read 3672 times)
superpat
Full Member
***

Karma: 15
Posts: 141


View Profile
« on: September 25, 2009, 12:43:55 PM »

Hi,

I have seen several posts pondering the purpose of the two pin connector marked J2 2.5V

I believe this is ONLY for a manufacturing process, enabling the writing of the write once only EFuse in the Sheeva cpu with the individual  MAC address.

There are 44 bytes of write once Efuse memory in the Sheeva for this purpose.  The read voltage is 1.5V and the write voltage is 2.5V

I would steer well clear of applying any external voltage to J2 in case you do something untoward to the EFuse memory.  It may be OK but  better safe than no mac address

YMMV

cheers

Patrick

Logged

birdman
Sr. Member
****

Karma: 4
Posts: 443


View Profile WWW
« Reply #1 on: September 25, 2009, 04:02:40 PM »

enabling the writing of the write once only EFuse in the Sheeva cpu with the individual  MAC address.
The (default) MAC address can be set by the Sheevaplug installer, and it can be configured at runtime to anything you want.
So where does this setting come in the chain?
(Just curious).
Logged

superpat
Full Member
***

Karma: 15
Posts: 141


View Profile
« Reply #2 on: September 26, 2009, 01:40:11 AM »

Hi Birdman

I am very surprised by your statement that the MAC address can be overwritten at will!

The IEEE802 MAC spec defines that the 48bit Mac address should be PERMANENTLY written into any ethernet device,  (otherwise chaos would ensue on a network!)

I know when I worked at DEC, we used to get a big block of MAC addresses from IEE802, or their agents to use to burn in our NIC Roms individually.

I have not yet found any Marvell documentation that reveals the addressing methods of the Efuse, the data sheet only states on the features page:-

• 128-bit eFuse (one-time programmable memory)

Have you any documentation that describes the use of the Efuse ROM?

regards

Patrick


Logged

fragfutter
Sr. Member
****

Karma: 12
Posts: 280


View Profile
« Reply #3 on: September 27, 2009, 07:13:36 AM »

nearly any modern ethernet hardware can modify mac addresses "at will". Some permanent, most on runtime.

For the sheevaplug mac addresses are stored in an environment variable of the uboot. I'm not sure if it can be reset from the uboot prompt (you can at least write it once), but the moment i overwrite the memory block i can.
Logged

birdman
Sr. Member
****

Karma: 4
Posts: 443


View Profile WWW
« Reply #4 on: September 27, 2009, 08:37:56 AM »

The IEEE802 MAC spec defines that the 48bit Mac address should be PERMANENTLY written into any ethernet device,  (otherwise chaos would ensue on a network!)

I know when I worked at DEC, we used to get a big block of MAC addresses from IEE802, or their agents to use to burn in our NIC Roms individually.
That would be the same DEC that always overwrote the MAC address for DECNet?  So that overwritten value was used for Ethernet too?
OK - it was overwritten with a "private" MAC address (top bit(s?) set), but it was always overwritten.
Logged

superpat
Full Member
***

Karma: 15
Posts: 141


View Profile
« Reply #5 on: September 27, 2009, 12:02:36 PM »

Hi Birdman,

Pardon?

DECNET never used the physical MAC address so you are incorrect in your statement. Please read the following quote:-

DECnet hosts do not use manufacturer-assigned Media Access Control (MAC)-layer addresses. Instead, network level addresses are embedded in the MAC-layer address according to an algorithm that multiplies the area number by 1024 and adds the node number to the product. The resulting 16-bit decimal address is converted to a hexadecimal number and is appended to the address AA00.0400 in byte-swapped order, with the least-significant byte first. For example, DECnet address 12.75 becomes 12363 (base 10), which equals 304B (base 16). After this byte-swapped address is appended to the standard DECnet MAC address prefix, the address is AA00.0400.4B30.

(From Internetworking Technology by Cisco Technologies, I could not find my old DEC Networks book!)

You nearly remembered correctly! but  I am writing about the manufacture assigned MAC addresses!

Please believe me when I tell you that all Ethernet devices normally have a non alterable manufacturer assigned MAC address burnt in. as  I believe so does the Sheevaplug, and since the only "ROM" available is the Efuse, it is probable that it is stored there. There are a 144 bytes so even after loading the MAC there is still space available. 

In most of the other ARM controllers I have worked on, the Efuse or similar circuits are also used to protect the firmware, for commercial reasons.

Cheers

Patrick

Logged

birdman
Sr. Member
****

Karma: 4
Posts: 443


View Profile WWW
« Reply #6 on: September 27, 2009, 01:32:15 PM »

DECNET never used the physical MAC address so you are incorrect in your statement.
That's what I said·  DECNet used software-assigned MAC addresses....
Quote from: and also
You nearly remembered correctly! but  I am writing about the manufacture assigned MAC addresses!
...and you agree with me.
The Ethernet address on the Sheeva plug is certainly modifiable, as the Sheeva installer will set it to a "standard" value if you forget to edit the config file to set it to the one written on the plug itself.  I managed to acheive this, so just set the MAC address to the "correct" value at runtime (but since I'm using Wifi anyway it's not too important here anyway).
Quote
Please believe me when I tell you that all Ethernet devices normally have a non alterable manufacturer assigned MAC address burnt in. as  I believe so does the Sheevaplug, and since the only "ROM" available is the Efuse, it is probable that it is stored there.
I'm quite prepared to believe that, but given that this can be overridden quite easily then it would seem to be fairly irrelevant in real terms.
Logged

superpat
Full Member
***

Karma: 15
Posts: 141


View Profile
« Reply #7 on: October 28, 2009, 03:10:32 AM »

Hi

I was looking through the Marvell Functional spec for info on the sata registers and came across this regarding the Efuse:-

Quote
88F6180/88F619x/88F6281

Functional Specifications

Doc. No. MV-S104860-U0 Rev. C Copyright © 2008 Marvell

23 eFuse

The device integrates two eFuse blocks: eFuse0 and eFuse1. Each eFuse block has 64
programmable data bits that provide a total of 128 bits (2 * 64). The eFuse is a one-time electrical
programmable element, where the data bit values can be programmed.
The device supports:
eFuse programming—updating the data bits in the eFuse
eFuse locking—disabling the programming operation
eFuse reading—reading the data bits and the lock bit.
The default value of the of the eFuse data bits and the lock bit is 0x0.

23.1 Typical eFuse Applications

Specific private/public key for security and prevention of hacking.
Operations information, such as system serial number/production number.
Time of the initial operation of system by the end user. (For example, software may burn
date/time after the initial power up.)
Software upgrade limiter. (For example, only three upgrades are allowed by the system vendor,
where each upgrade burns specific eFuse bits).

Device unique name/ID (for example, MAC address).

23.2 eFuse Power Supply

When programming the eFuse, a 2.5V power supply is required for the VHV power pin.
When reading from the eFuse, a 1.0V power supply is required for the VHV power pin.
For more details, see the Electrical Specifications section in the Hardware Specifications.

23.3 eFuse Program and Lock

eFuse0 and eFuse1 can be programmed and /or locked by the CPU. Each data bit can be set to 1,
one time only. After programming a bit in the eFuse to 1, it can no longer be changed to 0. When a
data bit has a value of 0, and it is programmed to 0, it is as if it has not been programmed, since it
remains unchanged. In such a situation, the bit can still be programmed to the value 1.
Each of the eFuse0 and eFuse1 blocks can be locked independently. When a eFuse block is locked,
the eFuse programming operation is disabled.
The eFuse lock operation can be performed one time only. After locking the eFuse, it cannot be
unlocked.

Note
Programming and/or locking the eFuse without using the required power supply results
in unpredictable data in the eFuse.

Cut (there is a second page and pages with the register defs)


Note the typical Efuse applications!

Looking at the register set there does not seem to be a great deal of risk of bricking the plug by erroneously setting the Efuse data bits. They do NOT appear to do anything directly to the hardware. The O/S has to be instructed to read the Efuse bits and take action depending on what bits are set.  Hopefully Marvell have not patched the kernel to look at the efuse registers! <g>

A liitle bit OT (for Birdman). 

Setting your own MAC address is OK when you have one or two devices, but how do you manage 5000 NIC's in a big office intranet?  It is far better to leave the MAC to the pre-allocated manufacture supplied address and then you get no ARP problems, or whatever is the current translation protocol these days.

cheers

P
Logged

birdman
Sr. Member
****

Karma: 4
Posts: 443


View Profile WWW
« Reply #8 on: October 29, 2009, 04:06:59 PM »

A liitle bit OT (for Birdman). 

Setting your own MAC address is OK when you have one or two devices, but how do you manage 5000 NIC's in a big office intranet?  It is far better to leave the MAC to the pre-allocated manufacture supplied address and then you get no ARP problems, or whatever is the current translation protocol these days.
I wasn't advocating anarchy - juts pointing out that you can set the MAC address from software at run time as:
  • a) I did after I forgot to edit the config file when running the alpha-6 installer
  • b) DEC did in VMS with every Ethernet interface (based on the DECnet name&|address for uniqueness)
  • c) "High Availability" systems do so that one system can pick up the interface of another when it goes down.
Logged

Pages: [1]
Print
Jump to: