EEPROM read/write user space program

EEPROM read/write user space program

[Jean Delvare]

Hi Stefano,

Please contact the mailing-list for general discussion, instead of me
directly

> I'm writing you because I wrote a Linux program to read and write
> 24Cxx EEPROMs through the SMBus interface and want to share it with
> the community (it's free of course).
> 
> I wrote it because the 'eeprom' and 'eepromer' programs require a I2C
> capable chipset (or, at least, this is what I think is the problem :)
> and mine does not seem capable of I2C_RW (I'm using the viapro
> driver).

I don't get it. We have prog/eepromer/eepromer.c that is supposed to to
the very same. In which way is your program different?

I don't know what you mean with "I2C_RW", but all the bus drivers we
have support sending data to the chips.

> I think (and hope:) that eeprog (oh, it's called eeprog) url could be
> included into a README in the eeprom dir or somewhere in lm-sensors
> package so the next more-lucky-then-me can find it if needed.
> 
> info link:
> 	http://codesink.org/eeprog.html
> 
> download:
> 	http://codesink.org/download/eeprog-0.7.3.tar.gz

If your program brings something really new, we will, but for now it
seems to be just a duplicate of eepromer. It would be preferable to
merge our efforts, isn't it? Please explain why eepromer did not work
for you, and/or what eeprog does better.

Mark D. Studebaker and some other persons on the list are much more
knowledged about writing to eeproms than I am, and might be able to
discuss it with you.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

EEPROM read/write user space program

[Stefano Barbato]

Thanks Jean and hi to the mailing list.
I wrote to Jean because I wrote a program to read/write to EEPROMs using the 
SMBus and I would like to share it.

I found problems with 'eepromer' because it requires (based on my 
understanding of the problem, mailing list comments will be very 
appreciated:) a plain I2C capable bus. 

My chipset (viapro) is not able to send/recv plain I2C commands (master_xfer 
is set to NULL into my adapter i2c_algorithm structure) but it's able to use 
SMBus transfers and 'eeprog', the program I wrote, just use SMBus commands.

The result is that running 'eeprog' I can read/write to 24Cxx EEPROMs with any 
SMBus bus adapter without requiring a plain I2C-capable chipset while 
'eepromer' or 'eeprom' on such systems will not work.

I'm not an expert on the i2c topic so I'm not sure that my understanding of 
the topic is, well, correct so if somebody here can confirm that 'eepromer' 
has those limits and that 'eeprog' could be useful then I'll be happy to know 
that I've not lost hours of my time for nothing :)

thanks.

stefano

p.s. program URLs are quoted below.
----------------------------------------
stefano barbato - stefano || codesink.org



On Saturday 22 November 2003 08:40, Jean Delvare wrote:
> Hi Stefano,
>
> Please contact the mailing-list for general discussion, instead of me
> directly
>
> > I'm writing you because I wrote a Linux program to read and write
> > 24Cxx EEPROMs through the SMBus interface and want to share it with
> > the community (it's free of course).
> >
> > I wrote it because the 'eeprom' and 'eepromer' programs require a I2C
> > capable chipset (or, at least, this is what I think is the problem :)
> > and mine does not seem capable of I2C_RW (I'm using the viapro
> > driver).
>
> I don't get it. We have prog/eepromer/eepromer.c that is supposed to to
> the very same. In which way is your program different?
>
> I don't know what you mean with "I2C_RW", but all the bus drivers we
> have support sending data to the chips.
>
> > I think (and hope:) that eeprog (oh, it's called eeprog) url could be
> > included into a README in the eeprom dir or somewhere in lm-sensors
> > package so the next more-lucky-then-me can find it if needed.
> >
> > info link:
> > 	http://codesink.org/eeprog.html
> >
> > download:
> > 	http://codesink.org/download/eeprog-0.7.3.tar.gz
>
> If your program brings something really new, we will, but for now it
> seems to be just a duplicate of eepromer. It would be preferable to
> merge our efforts, isn't it? Please explain why eepromer did not work
> for you, and/or what eeprog does better.
>
> Mark D. Studebaker and some other persons on the list are much more
> knowledged about writing to eeproms than I am, and might be able to
> discuss it with you.

EEPROM read/write user space program

[Mark Studebaker]

we have two programs, eeprom for small chips and eepromer for larger
ones.
They both suffer from the limitation you describe.
As your program appears to overcome this limitation, and handle both
small and large chips, I'd say it is worth including in our package.

One thing we would require is that the program contains a big fat
warning,
and a force flag, before writing. See eeprom.c for an example.

One suggestion you may want to think about is using i2c block reads and
writes
if the bus driver supports them. You can see the kernel/chips/eeprom.c
driver
for an example of this code.

mds


Stefano Barbato wrote:
> 
> Thanks Jean and hi to the mailing list.
> I wrote to Jean because I wrote a program to read/write to EEPROMs using the
> SMBus and I would like to share it.
> 
> I found problems with 'eepromer' because it requires (based on my
> understanding of the problem, mailing list comments will be very
> appreciated:) a plain I2C capable bus.
> 
> My chipset (viapro) is not able to send/recv plain I2C commands (master_xfer
> is set to NULL into my adapter i2c_algorithm structure) but it's able to use
> SMBus transfers and 'eeprog', the program I wrote, just use SMBus commands.
> 
> The result is that running 'eeprog' I can read/write to 24Cxx EEPROMs with any
> SMBus bus adapter without requiring a plain I2C-capable chipset while
> 'eepromer' or 'eeprom' on such systems will not work.
> 
> I'm not an expert on the i2c topic so I'm not sure that my understanding of
> the topic is, well, correct so if somebody here can confirm that 'eepromer'
> has those limits and that 'eeprog' could be useful then I'll be happy to know
> that I've not lost hours of my time for nothing :)
> 
> thanks.
> 
> stefano
> 
> p.s. program URLs are quoted below.
> ----------------------------------------
> stefano barbato - stefano || codesink.org
> 
> On Saturday 22 November 2003 08:40, Jean Delvare wrote:
> > Hi Stefano,
> >
> > Please contact the mailing-list for general discussion, instead of me
> > directly
> >
> > > I'm writing you because I wrote a Linux program to read and write
> > > 24Cxx EEPROMs through the SMBus interface and want to share it with
> > > the community (it's free of course).
> > >
> > > I wrote it because the 'eeprom' and 'eepromer' programs require a I2C
> > > capable chipset (or, at least, this is what I think is the problem :)
> > > and mine does not seem capable of I2C_RW (I'm using the viapro
> > > driver).
> >
> > I don't get it. We have prog/eepromer/eepromer.c that is supposed to to
> > the very same. In which way is your program different?
> >
> > I don't know what you mean with "I2C_RW", but all the bus drivers we
> > have support sending data to the chips.
> >
> > > I think (and hope:) that eeprog (oh, it's called eeprog) url could be
> > > included into a README in the eeprom dir or somewhere in lm-sensors
> > > package so the next more-lucky-then-me can find it if needed.
> > >
> > > info link:
> > >     http://codesink.org/eeprog.html
> > >
> > > download:
> > >     http://codesink.org/download/eeprog-0.7.3.tar.gz
> >
> > If your program brings something really new, we will, but for now it
> > seems to be just a duplicate of eepromer. It would be preferable to
> > merge our efforts, isn't it? Please explain why eepromer did not work
> > for you, and/or what eeprog does better.
> >
> > Mark D. Studebaker and some other persons on the list are much more
> > knowledged about writing to eeproms than I am, and might be able to
> > discuss it with you.

EEPROM read/write user space program

[Stefano Barbato]

I'll add a warning and a force flag in the next few days and if I'll have a 
look on block transfers.  Now I'm ill and not lucid enough to work on it :)

I'll let you know.

stefano

On Sunday 23 November 2003 01:28, you wrote:
> we have two programs, eeprom for small chips and eepromer for larger
> ones.
> They both suffer from the limitation you describe.
> As your program appears to overcome this limitation, and handle both
> small and large chips, I'd say it is worth including in our package.
>
> One thing we would require is that the program contains a big fat
> warning,
> and a force flag, before writing. See eeprom.c for an example.
>
> One suggestion you may want to think about is using i2c block reads and
> writes
> if the bus driver supports them. You can see the kernel/chips/eeprom.c
> driver
> for an example of this code.
>
> mds
>
> Stefano Barbato wrote:
> > Thanks Jean and hi to the mailing list.
> > I wrote to Jean because I wrote a program to read/write to EEPROMs using
> > the SMBus and I would like to share it.
> >
> > I found problems with 'eepromer' because it requires (based on my
> > understanding of the problem, mailing list comments will be very
> > appreciated:) a plain I2C capable bus.
> >
> > My chipset (viapro) is not able to send/recv plain I2C commands
> > (master_xfer is set to NULL into my adapter i2c_algorithm structure) but
> > it's able to use SMBus transfers and 'eeprog', the program I wrote, just
> > use SMBus commands.
> >
> > The result is that running 'eeprog' I can read/write to 24Cxx EEPROMs
> > with any SMBus bus adapter without requiring a plain I2C-capable chipset
> > while 'eepromer' or 'eeprom' on such systems will not work.
> >
> > I'm not an expert on the i2c topic so I'm not sure that my understanding
> > of the topic is, well, correct so if somebody here can confirm that
> > 'eepromer' has those limits and that 'eeprog' could be useful then I'll
> > be happy to know that I've not lost hours of my time for nothing :)
> >
> > thanks.
> >
> > stefano
> >
> > p.s. program URLs are quoted below.
> > ----------------------------------------
> > stefano barbato - stefano || codesink.org
> >
> > On Saturday 22 November 2003 08:40, Jean Delvare wrote:
> > > Hi Stefano,
> > >
> > > Please contact the mailing-list for general discussion, instead of me
> > > directly
> > >
> > > > I'm writing you because I wrote a Linux program to read and write
> > > > 24Cxx EEPROMs through the SMBus interface and want to share it with
> > > > the community (it's free of course).
> > > >
> > > > I wrote it because the 'eeprom' and 'eepromer' programs require a I2C
> > > > capable chipset (or, at least, this is what I think is the problem :)
> > > > and mine does not seem capable of I2C_RW (I'm using the viapro
> > > > driver).
> > >
> > > I don't get it. We have prog/eepromer/eepromer.c that is supposed to to
> > > the very same. In which way is your program different?
> > >
> > > I don't know what you mean with "I2C_RW", but all the bus drivers we
> > > have support sending data to the chips.
> > >
> > > > I think (and hope:) that eeprog (oh, it's called eeprog) url could be
> > > > included into a README in the eeprom dir or somewhere in lm-sensors
> > > > package so the next more-lucky-then-me can find it if needed.
> > > >
> > > > info link:
> > > >     http://codesink.org/eeprog.html
> > > >
> > > > download:
> > > >     http://codesink.org/download/eeprog-0.7.3.tar.gz
> > >
> > > If your program brings something really new, we will, but for now it
> > > seems to be just a duplicate of eepromer. It would be preferable to
> > > merge our efforts, isn't it? Please explain why eepromer did not work
> > > for you, and/or what eeprog does better.
> > >
> > > Mark D. Studebaker and some other persons on the list are much more
> > > knowledged about writing to eeproms than I am, and might be able to
> > > discuss it with you.

EEPROM read/write user space program

[Stefano Barbato]

I've updated eeprog to display a big warning and a confirmation to continue. 
It's displayed for write AND for read operations because reading from an 8bit 
eeprom using 16bit addressing can actually *write* to the eeprom. 

I'll see block transfers whenever possible. I'll let you know for updates.

here is the download link:
   http://codesink.org/download/eeprog-0.7.4.tar.gz

stefano

p.s. if anybody is really willing to proofread this is the warning message :-)
=================================
__________________________________WARNING_______________________________
Erroneously writing to a system EEPROM (like DIMM SPD modules) can brake your
system.  It will NOT boot any more so you'll not be able to fix it.

Reading from 8bit EEPROMs (like that in your DIMM) without using the -8 switch
can also UNEXPECTEDLY write to them, so be sure to use the -8 command param 
when required.

Use -f to disable this warning message

Press ENTER to continue or hit CTRL-C to exit
=================================


On Sunday 23 November 2003 01:28, Mark Studebaker wrote:
> we have two programs, eeprom for small chips and eepromer for larger
> ones.
> They both suffer from the limitation you describe.
> As your program appears to overcome this limitation, and handle both
> small and large chips, I'd say it is worth including in our package.
>
> One thing we would require is that the program contains a big fat
> warning,
> and a force flag, before writing. See eeprom.c for an example.
>
> One suggestion you may want to think about is using i2c block reads and
> writes
> if the bus driver supports them. You can see the kernel/chips/eeprom.c
> driver
> for an example of this code.
>
> mds
>
> Stefano Barbato wrote:
> > Thanks Jean and hi to the mailing list.
> > I wrote to Jean because I wrote a program to read/write to EEPROMs using
> > the SMBus and I would like to share it.
> >
> > I found problems with 'eepromer' because it requires (based on my
> > understanding of the problem, mailing list comments will be very
> > appreciated:) a plain I2C capable bus.
> >
> > My chipset (viapro) is not able to send/recv plain I2C commands
> > (master_xfer is set to NULL into my adapter i2c_algorithm structure) but
> > it's able to use SMBus transfers and 'eeprog', the program I wrote, just
> > use SMBus commands.
> >
> > The result is that running 'eeprog' I can read/write to 24Cxx EEPROMs
> > with any SMBus bus adapter without requiring a plain I2C-capable chipset
> > while 'eepromer' or 'eeprom' on such systems will not work.
> >
> > I'm not an expert on the i2c topic so I'm not sure that my understanding
> > of the topic is, well, correct so if somebody here can confirm that
> > 'eepromer' has those limits and that 'eeprog' could be useful then I'll
> > be happy to know that I've not lost hours of my time for nothing :)
> >
> > thanks.
> >
> > stefano
> >
> > p.s. program URLs are quoted below.
> > ----------------------------------------
> > stefano barbato - stefano || codesink.org
> >
> > On Saturday 22 November 2003 08:40, Jean Delvare wrote:
> > > Hi Stefano,
> > >
> > > Please contact the mailing-list for general discussion, instead of me
> > > directly
> > >
> > > > I'm writing you because I wrote a Linux program to read and write
> > > > 24Cxx EEPROMs through the SMBus interface and want to share it with
> > > > the community (it's free of course).
> > > >
> > > > I wrote it because the 'eeprom' and 'eepromer' programs require a I2C
> > > > capable chipset (or, at least, this is what I think is the problem :)
> > > > and mine does not seem capable of I2C_RW (I'm using the viapro
> > > > driver).
> > >
> > > I don't get it. We have prog/eepromer/eepromer.c that is supposed to to
> > > the very same. In which way is your program different?
> > >
> > > I don't know what you mean with "I2C_RW", but all the bus drivers we
> > > have support sending data to the chips.
> > >
> > > > I think (and hope:) that eeprog (oh, it's called eeprog) url could be
> > > > included into a README in the eeprom dir or somewhere in lm-sensors
> > > > package so the next more-lucky-then-me can find it if needed.
> > > >
> > > > info link:
> > > >     http://codesink.org/eeprog.html
> > > >
> > > > download:
> > > >     http://codesink.org/download/eeprog-0.7.3.tar.gz
> > >
> > > If your program brings something really new, we will, but for now it
> > > seems to be just a duplicate of eepromer. It would be preferable to
> > > merge our efforts, isn't it? Please explain why eepromer did not work
> > > for you, and/or what eeprog does better.
> > >
> > > Mark D. Studebaker and some other persons on the list are much more
> > > knowledged about writing to eeproms than I am, and might be able to
> > > discuss it with you.

EEPROM read/write user space program

[Jean Delvare]

> __________________________________WARNING____________________________
> ___ Erroneously writing to a system EEPROM (like DIMM SPD modules) can
> brake your system.  It will NOT boot any more so you'll not be able to
> fix it.

It's "break", not "brake" (also in some way I agree it does too ;)).
And "any more" is "anymore".

> Reading from 8bit EEPROMs (like that in your DIMM) without using the
> -8 switch can also UNEXPECTEDLY write to them, so be sure to use the
> -8 command param when required.

Wouldn't it be safer to default to 8-bit and have a switch to use
16-bit addressing? From what you said, "reading from an 8bit eeprom
using 16bit addressing can actually *write* to the eeprom", but what
would reading a 16-bit eeprom using 8-bit addressing do? If it isn't
dangerous, I believe you should default to 8-bit addressing.

BTW, isn't it possible to detect the addressing mode?

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

EEPROM read/write user space program

[Stefano Barbato]

I could also change in "your system will brake, very very VERY much" :)

I think that defaulting to 8bit makes sense, I agree with you. It will be more 
safer or, better, less devastating. Reading from a 16bit using 8bit will just 
confuse the eeprom that can return wrong values (usually 0xff). Writing just 
don't work or at least not on eeproms I used for testing.

So I'll change to 16bit default as soon as possible (and I'll add a -16 
switch).

I was trying to figure out if there's a non-euristic mode to detect the eeprom 
type without writing to it but, before trying, I want to buy a new 8bit 
eeprom because I don't want to play with my dimm spd (that btw is not write 
protected)!

I'll let you know.

Thanks for the proofreading work :)

stefano


On Friday 28 November 2003 19:23, you wrote:
> > __________________________________WARNING____________________________
> > ___ Erroneously writing to a system EEPROM (like DIMM SPD modules) can
> > brake your system.  It will NOT boot any more so you'll not be able to
> > fix it.
>
> It's "break", not "brake" (also in some way I agree it does too ;)).
> And "any more" is "anymore".
>
> > Reading from 8bit EEPROMs (like that in your DIMM) without using the
> > -8 switch can also UNEXPECTEDLY write to them, so be sure to use the
> > -8 command param when required.
>
> Wouldn't it be safer to default to 8-bit and have a switch to use
> 16-bit addressing? From what you said, "reading from an 8bit eeprom
> using 16bit addressing can actually *write* to the eeprom", but what
> would reading a 16-bit eeprom using 8-bit addressing do? If it isn't
> dangerous, I believe you should default to 8-bit addressing.
>
> BTW, isn't it possible to detect the addressing mode?

EEPROM read/write user space program

[Stefano Barbato]

I've modified eeprog so that -8 and -16 can be selected. 8bit mode is now the 
default (thanks to Jean for the suggestion). It's definitely safer.

download link:
	http://codesink.org/download/eeprog-0.7.5.tar.gz

please update, thanks.

stefano



On Friday 28 November 2003 19:23, Jean Delvare wrote:
> > __________________________________WARNING____________________________
> > ___ Erroneously writing to a system EEPROM (like DIMM SPD modules) can
> > brake your system.  It will NOT boot any more so you'll not be able to
> > fix it.
>
> It's "break", not "brake" (also in some way I agree it does too ;)).
> And "any more" is "anymore".
>
> > Reading from 8bit EEPROMs (like that in your DIMM) without using the
> > -8 switch can also UNEXPECTEDLY write to them, so be sure to use the
> > -8 command param when required.
>
> Wouldn't it be safer to default to 8-bit and have a switch to use
> 16-bit addressing? From what you said, "reading from an 8bit eeprom
> using 16bit addressing can actually *write* to the eeprom", but what
> would reading a 16-bit eeprom using 8-bit addressing do? If it isn't
> dangerous, I believe you should default to 8-bit addressing.
>
> BTW, isn't it possible to detect the addressing mode?