[U-Boot-Users] I2C address above 0x7f

[U-Boot-Users] I2C address above 0x7f

[Stephan Linz]

Hi all,

currently I play with the I2C facility of PPCBoot 2.0.0 (I know, it's 
deprecated). At my TQ850L I'm using the I2C hardware machine 
(CONFIG_HARD_I2C) with needed configuration:

   * CFG_I2C_SPEED=400000
   * CFG_I2C_SLAVE=0x7f

Hm, what's the meaning of CFG_I2C_SLAVE ? I've expected it's the highes valid 
slave address, isn't it ?


Best regards,
Stephan Linz
-- 

======================================================================
Stephan Linz
Software Engineer

MAZeT GmbH                   Email:   mailto:linz at mazet.de
Branche office Jena          Phone:   +49-3641-2809-55
G?schwitzer Stra?e 32        Fax  :   +49-3641-2809-12
D-07745 JENA
Germany

Visit our web-pages: http://www.MAZeT.de
======================================================================

[U-Boot-Users] I2C address above 0x7f

[Wolfgang Denk]

In message <0212041158460F.06014@pcj86.jena.mazet.de> you wrote:
> 
> currently I play with the I2C facility of PPCBoot 2.0.0 (I know, it's 
> deprecated). At my TQ850L I'm using the I2C hardware machine 
> (CONFIG_HARD_I2C) with needed configuration:
> 
>    * CFG_I2C_SPEED=400000
>    * CFG_I2C_SLAVE=0x7f

Why don't you use the default of 0xFE?

> Hm, what's the meaning of CFG_I2C_SLAVE ? I've expected it's the highes valid 
> slave address, isn't it ?

No, what makes you think so? It's the value that gets programmed into
the MPC8xx I2C controller's I2ADD register. See the Users Manual  for
details.


The subject suggests you ntended to ask something different?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
You don't have to worry about me. I might have been born yesterday...
but I stayed up all night.

[U-Boot-Users] I2C address above 0x7f

[Stephan Linz]

Am Mittwoch,  4. Dezember 2002 12:43 schrieb Wolfgang Denk:
> In message <0212041158460F.06014@pcj86.jena.mazet.de> you wrote:
> > currently I play with the I2C facility of PPCBoot 2.0.0 (I know, it's
> > deprecated). At my TQ850L I'm using the I2C hardware machine
> > (CONFIG_HARD_I2C) with needed configuration:
> >
> >    * CFG_I2C_SPEED=400000
> >    * CFG_I2C_SLAVE=0x7f
>
> Why don't you use the default of 0xFE?

Oh yes, the value above was coming from TQM8260.h. I've changed.

>
> > Hm, what's the meaning of CFG_I2C_SLAVE ? I've expected it's the highes
> > valid slave address, isn't it ?
>
> No, what makes you think so? It's the value that gets programmed into
> the MPC8xx I2C controller's I2ADD register. See the Users Manual  for
> details.
>
>
> The subject suggests you ntended to ask something different?

Oops, I've forgot to ask. Now, at my TQ there is a so named FRAM I2C brick 
connected to I2CSDA (PB27) and I2CSCL (PB26). The FRAM has two different 
addresses both above 0x7F, 0xAE for write access and 0xAF for read access. 
The FRAM is similar to E2PROM bricks like AT24C64.

My question: Is there an read/write abstraction layer inside of the I2C stuff 
of PPCBoot ? I don't know if I should use the bit shifted address 0x57 
instead of 0xAE for calling imd -- I think 0x57. However, upt to now I've 
tried both addresses without success.

Ah, just now I see there is a nice tool to scan I2C devices (iprobe). Can 
anybody give me an generic command line dump with iprobe in action? I've ran 
iprobe but without any success. The only thing I see is:

=> iprobe
Valid chip addresses:
=> _

I think iprobe has not found any valid chip. Is it so ?

>
> Best regards,
>
> Wolfgang Denk

-- 

======================================================================
Stephan Linz
Software Engineer

MAZeT GmbH                   Email:   mailto:linz at mazet.de
Branche office Jena          Phone:   +49-3641-2809-55
G?schwitzer Stra?e 32        Fax  :   +49-3641-2809-12
D-07745 JENA
Germany

Visit our web-pages: http://www.MAZeT.de
======================================================================

[U-Boot-Users] I2C address above 0x7f

[Wolfgang Denk]

In message <0212041401260G.06014@pcj86.jena.mazet.de> you wrote:
>
> > > Hm, what's the meaning of CFG_I2C_SLAVE ? I've expected it's the highes
> > > valid slave address, isn't it ?
> >
> > No, what makes you think so? It's the value that gets programmed into
> > the MPC8xx I2C controller's I2ADD register. See the Users Manual  for
> > details.
> >
> > The subject suggests you ntended to ask something different?
> 
> Oops, I've forgot to ask. Now, at my TQ there is a so named FRAM I2C brick 
> connected to I2CSDA (PB27) and I2CSCL (PB26). The FRAM has two different 
> addresses both above 0x7F, 0xAE for write access and 0xAF for read access. 

No. The FRAM has just one address: 0x57. The first octet sent on  the
I2C  bus  contains  the 7 address bits plus a read/write bit. The I2C
interface as used in U-Boot does NOT consider the  read/write  bit  a
part of the address - we use the plain 7 bit device address.

> The FRAM is similar to E2PROM bricks like AT24C64.

Yes, I know. You can find a configuration featuring a  FM24CL64  FRAM
in the LWMON config file ("include/configs/lwmon.h").

> My question: Is there an read/write abstraction layer inside of the I2C stuff 
> of PPCBoot ? I don't know if I should use the bit shifted address 0x57 

You mean something like i2c_read() and i2c_write()? Of  course  there
is.  And  there  is  also extensive command line support for I2C. Use
"help".

> instead of 0xAE for calling imd -- I think 0x57. However, upt to now I've 
> tried both addresses without success.

You probably got the address length wrong. See the LWMON board for  a
working example.

> Ah, just now I see there is a nice tool to scan I2C devices (iprobe). Can 
> anybody give me an generic command line dump with iprobe in action? I've ran 
> iprobe but without any success. The only thing I see is:
> 
> => iprobe
> Valid chip addresses:

Be careful. "iprobe" with the HW I2C code may  take  _very_  long  to
complete.  If  you  don't need very fast bulk data transfers (100 kHz
clock or more) you will find it  probably  much  simpler  to  use  SW
(bitbanging) I2C instead.

Here is what I get on a LWMON board:

	U-Boot 0.1.1 (Dec  4 2002 - 14:19:27)

	CPU:   PPC823EZTnnB2 at 66 MHz: 16 kB I-Cache 8 kB D-Cache
	Board: Litronic Monitor IV
	       Watchdog enabled
	I2C:   ready
	DRAM:  64 MB
	POST spr PASSED
	FLASH: 16 MB
	KEYBD: Version 1.2
	Net:   SCC ETHERNET
	POST cache PASSED
	POST i2c PASSED
	POST cpu PASSED
	POST ethernet PASSED
	POST spi PASSED
	POST usb PASSED
	PCMCIA:   No Card found
	Hit any key to stop autoboot:  0 
	=> iprobe
	Valid chip addresses: 2E 51 52 53 55 56
	=>

> I think iprobe has not found any valid chip. Is it so ?

Seems so.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Many Myths are based on truth
	-- Spock, "The Way to Eden",  stardate 5832.3

[U-Boot-Users] I2C address above 0x7f

[Jerry Van Baren]

I believe the CFG_I2C_SLAVE value is put in a register because the register 
must have something in it, but it is only used if the 8xx/82xx processor is 
used as a I2C slave.  Leave it at 0xFE.  This would be the shifted value, 
so it actually sets what I would consider the I2C to be 0x7F.

I2C addresses are the top 7 bits of a byte with the LSBit the R/W 
flag.  Some people treat the whole byte as the address.  I (and 
approximately half the world, including u-boot) find that non-intuitive and 
thus treat I2C addresses as the 7 bits right-shifted one bit.  Thus when 
you write that your FRAM is at address 0xAE/0xAF, that is the full byte 
address and includes the R/W flag.  As you deduced, the address you should 
use with u-boot is 0x57.

The iprobe command should just work.  What you show is nobody responding 
(which is one result of "works", you just need to figure out why nobody is 
responding :-/)  Unfortunately, iprobe can be quirky, especially when using 
hardware accelerated I2C as opposed to the bit-bang (software driver) 
I2C.  I don't have any 8xx experience, but my experience is that it is much 
easier to get the 8260 to work using the bit-banging driver.  I have had 
limited exposure to the 8240 (which only supports the hardware driver) but 
my experience is that iprobe is very quirky on it.

Things to check with an oscilloscope:
1) Speed: if you clock too fast, the slaves won't respond.
2) Activity: if the clock and data lines don't wiggle, the slaves won't 
respond.
3) Edges occur per the I2C specification (should be diagrammed in your FRAM 
manual)

Use an oscilloscope to look at the waveforms.  Usually it is pretty obvious 
once you look at it what is wrong.

gvb


At 02:03 PM 12/4/2002 +0100, Stephan Linz wrote:
>Am Mittwoch,  4. Dezember 2002 12:43 schrieb Wolfgang Denk:
> > In message <0212041158460F.06014@pcj86.jena.mazet.de> you wrote:
> > > currently I play with the I2C facility of PPCBoot 2.0.0 (I know, it's
> > > deprecated). At my TQ850L I'm using the I2C hardware machine
> > > (CONFIG_HARD_I2C) with needed configuration:
> > >
> > >    * CFG_I2C_SPEED=400000
> > >    * CFG_I2C_SLAVE=0x7f
> >
> > Why don't you use the default of 0xFE?
>
>Oh yes, the value above was coming from TQM8260.h. I've changed.
>
> >
> > > Hm, what's the meaning of CFG_I2C_SLAVE ? I've expected it's the highes
> > > valid slave address, isn't it ?
> >
> > No, what makes you think so? It's the value that gets programmed into
> > the MPC8xx I2C controller's I2ADD register. See the Users Manual  for
> > details.
> >
> >
> > The subject suggests you ntended to ask something different?
>
>Oops, I've forgot to ask. Now, at my TQ there is a so named FRAM I2C brick
>connected to I2CSDA (PB27) and I2CSCL (PB26). The FRAM has two different
>addresses both above 0x7F, 0xAE for write access and 0xAF for read access.
>The FRAM is similar to E2PROM bricks like AT24C64.
>
>My question: Is there an read/write abstraction layer inside of the I2C stuff
>of PPCBoot ? I don't know if I should use the bit shifted address 0x57
>instead of 0xAE for calling imd -- I think 0x57. However, upt to now I've
>tried both addresses without success.
>
>Ah, just now I see there is a nice tool to scan I2C devices (iprobe). Can
>anybody give me an generic command line dump with iprobe in action? I've ran
>iprobe but without any success. The only thing I see is:
>
>=> iprobe
>Valid chip addresses:
>=> _
>
>I think iprobe has not found any valid chip. Is it so ?
>
> >
> > Best regards,
> >
> > Wolfgang Denk
>
>--
>
>======================================================================
>Stephan Linz
>Software Engineer
>
>MAZeT GmbH                   Email:   mailto:linz at mazet.de
>Branche office Jena          Phone:   +49-3641-2809-55
>G?schwitzer Stra?e 32        Fax  :   +49-3641-2809-12
>D-07745 JENA
>Germany
>
>Visit our web-pages: http://www.MAZeT.de
>======================================================================
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Microsoft Visual Studio.NET
>comprehensive development tool, built to increase your
>productivity. Try a free online hosted session at:
>http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
>_______________________________________________
>U-Boot-Users mailing list
>U-Boot-Users at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/u-boot-users



**********************************************************************
This e-mail and any files transmitted with it are confidential and may
be legally privileged or otherwise exempt from disclosure under
applicable law. This e-mail and its files are intended solely for
the individual or entity to whom they are addressed and their content
is the property of Smiths Aerospace.  If you are not the intended
recipient, please do not read, copy, use or disclose this communication.
If you have received this e-mail in error please notify the e-mail 
administrator at postmaster at si.com and then delete this e-mail, its
files and any copies.

This footnote also confirms that this e-mail message has been scanned
for the presence of known computer viruses.
***********************************************************************

[U-Boot-Users] I2C address above 0x7f

[Stephan Linz]

Hurray, it seems to work. Thank you for all the support. I've borrowed the 
LWMON configuration, thank you Wolfgang.

But now I've another problem (sorry :-). Is there a more extensive syntax 
description of all the I2C commands than the quick help messages. I don't 
understand the meanings of "dotted address numbers" [.0, .1, .2] and "numbers 
of objects" [# of objects]. What is happen if I leave out this fields or in 
which case I have to use it ?

A quick guidance how to write to the lowest and the highest address of my 
FRAM would be really great.


Thanks for all,
Stephan Linz

Am Mittwoch,  4. Dezember 2002 14:22 schrieb Wolfgang Denk:
> In message <0212041401260G.06014@pcj86.jena.mazet.de> you wrote:
> > > > Hm, what's the meaning of CFG_I2C_SLAVE ? I've expected it's the
> > > > highes valid slave address, isn't it ?
> > >
> > > No, what makes you think so? It's the value that gets programmed into
> > > the MPC8xx I2C controller's I2ADD register. See the Users Manual  for
> > > details.
> > >
> > > The subject suggests you ntended to ask something different?
> >
> > Oops, I've forgot to ask. Now, at my TQ there is a so named FRAM I2C
> > brick connected to I2CSDA (PB27) and I2CSCL (PB26). The FRAM has two
> > different addresses both above 0x7F, 0xAE for write access and 0xAF for
> > read access.
>
> No. The FRAM has just one address: 0x57. The first octet sent on  the
> I2C  bus  contains  the 7 address bits plus a read/write bit. The I2C
> interface as used in U-Boot does NOT consider the  read/write  bit  a
> part of the address - we use the plain 7 bit device address.
>
> > The FRAM is similar to E2PROM bricks like AT24C64.
>
> Yes, I know. You can find a configuration featuring a  FM24CL64  FRAM
> in the LWMON config file ("include/configs/lwmon.h").
>
> > My question: Is there an read/write abstraction layer inside of the I2C
> > stuff of PPCBoot ? I don't know if I should use the bit shifted address
> > 0x57
>
> You mean something like i2c_read() and i2c_write()? Of  course  there
> is.  And  there  is  also extensive command line support for I2C. Use
> "help".
>
> > instead of 0xAE for calling imd -- I think 0x57. However, upt to now I've
> > tried both addresses without success.
>
> You probably got the address length wrong. See the LWMON board for  a
> working example.
>
> > Ah, just now I see there is a nice tool to scan I2C devices (iprobe). Can
> > anybody give me an generic command line dump with iprobe in action? I've
> > ran iprobe but without any success. The only thing I see is:
> >
> > => iprobe
> > Valid chip addresses:
>
> Be careful. "iprobe" with the HW I2C code may  take  _very_  long  to
> complete.  If  you  don't need very fast bulk data transfers (100 kHz
> clock or more) you will find it  probably  much  simpler  to  use  SW
> (bitbanging) I2C instead.
>
> Here is what I get on a LWMON board:
>
> 	U-Boot 0.1.1 (Dec  4 2002 - 14:19:27)
>
> 	CPU:   PPC823EZTnnB2 at 66 MHz: 16 kB I-Cache 8 kB D-Cache
> 	Board: Litronic Monitor IV
> 	       Watchdog enabled
> 	I2C:   ready
> 	DRAM:  64 MB
> 	POST spr PASSED
> 	FLASH: 16 MB
> 	KEYBD: Version 1.2
> 	Net:   SCC ETHERNET
> 	POST cache PASSED
> 	POST i2c PASSED
> 	POST cpu PASSED
> 	POST ethernet PASSED
> 	POST spi PASSED
> 	POST usb PASSED
> 	PCMCIA:   No Card found
> 	Hit any key to stop autoboot:  0
> 	=> iprobe
> 	Valid chip addresses: 2E 51 52 53 55 56
> 	=>
>
> > I think iprobe has not found any valid chip. Is it so ?
>
> Seems so.
>
> Best regards,
>
> Wolfgang Denk

-- 

======================================================================
Stephan Linz
Software Engineer

MAZeT GmbH                   Email:   mailto:linz at mazet.de
Branche office Jena          Phone:   +49-3641-2809-55
G?schwitzer Stra?e 32        Fax  :   +49-3641-2809-12
D-07745 JENA
Germany

Visit our web-pages: http://www.MAZeT.de
======================================================================

[U-Boot-Users] I2C address above 0x7f

[Wolfgang Denk]

In message <0212041616150I.06014@pcj86.jena.mazet.de> you wrote:
> 
> Hurray, it seems to work. Thank you for all the support. I've borrowed the 
> LWMON configuration, thank you Wolfgang.

:-) You're welcome.

> A quick guidance how to write to the lowest and the highest address of my 
> FRAM would be really great.

Read:	=> eeprom read 100000 0 <size_of_fram_in_bytex_in_hex>
	=> md 100000

Write:	=> eeprom write 100000 0 <size_of_fram_in_bytex_in_hex>

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
egrep patterns are full regular expressions; it uses a fast  determi-
nistic algorithm that sometimes needs exponential space.
- unix manuals

[U-Boot-Users] I2C address above 0x7f

[diekema_jon]

> But now I've another problem (sorry :-). Is there a more extensive syntax 
> description of all the I2C commands than the quick help messages. I don't 
> understand the meanings of "dotted address numbers" [.0, .1, .2] and "numbers 
> of objects" [# of objects]. What is happen if I leave out this fields or in 
> which case I have to use it ?

[U-Boot-Users] I2C address above 0x7f

[Jerry Van Baren]

In The Beginning, there were only single byte I2C addresses.  Then people 
started making chips with more than 256 data locations and two hack 
solutions came up.  The first hack solution was to spill the data address 
into the chip address.  The second hack address was to add another byte to 
the internal address field, allowing 64K bytes.  In addition, some people 
made I2C devices with only one register and decided that saving a byte in 
the transfer operation was more important than staying compatible with 
Historical Devices.

The .0, .1, .2 address modifiers deal with the internal address length 
(i.e. the offset inside the chip).  Some I2C devices have only one register 
and thus have no internal address -- use 0.0 for the address field for 
these chips.  The "in the beginning" chips have one byte internal address 
-- this is the default or you can make it obvious by using 12.1 for offset 
12.  Some chips have one byte internal address but have some address bits 
spill over into the chip address, making it (to my logical mind) "look 
like" multiple 256byte chips -- this is just a variant of the x.1 
address.  Other chips have two byte internal addresses -- use 12.2 for 
offset 0012.

x.0
<chip-addr><data>

x.1
<chip-addr><x><data>

x.2
<chip-addr><x-high><x-low><data>  (I think "x" is big endian)

You MUST know what device you are talking to because there is no way of 
knowing the address length a priori.  Using the wrong form is really bad 
because you won't be addressing what you think you are addressing.

gvb


At 04:16 PM 12/4/2002 +0100, Stephan Linz wrote:

>Hurray, it seems to work. Thank you for all the support. I've borrowed the
>LWMON configuration, thank you Wolfgang.
>
>But now I've another problem (sorry :-). Is there a more extensive syntax
>description of all the I2C commands than the quick help messages. I don't
>understand the meanings of "dotted address numbers" [.0, .1, .2] and "numbers
>of objects" [# of objects]. What is happen if I leave out this fields or in
>which case I have to use it ?
>
>A quick guidance how to write to the lowest and the highest address of my
>FRAM would be really great.
>
>
>Thanks for all,
>Stephan Linz
>
>Am Mittwoch,  4. Dezember 2002 14:22 schrieb Wolfgang Denk:
> > In message <0212041401260G.06014@pcj86.jena.mazet.de> you wrote:
> > > > > Hm, what's the meaning of CFG_I2C_SLAVE ? I've expected it's the
> > > > > highes valid slave address, isn't it ?
> > > >
> > > > No, what makes you think so? It's the value that gets programmed into
> > > > the MPC8xx I2C controller's I2ADD register. See the Users Manual  for
> > > > details.
> > > >
> > > > The subject suggests you ntended to ask something different?
> > >
> > > Oops, I've forgot to ask. Now, at my TQ there is a so named FRAM I2C
> > > brick connected to I2CSDA (PB27) and I2CSCL (PB26). The FRAM has two
> > > different addresses both above 0x7F, 0xAE for write access and 0xAF for
> > > read access.
> >
> > No. The FRAM has just one address: 0x57. The first octet sent on  the
> > I2C  bus  contains  the 7 address bits plus a read/write bit. The I2C
> > interface as used in U-Boot does NOT consider the  read/write  bit  a
> > part of the address - we use the plain 7 bit device address.
> >
> > > The FRAM is similar to E2PROM bricks like AT24C64.
> >
> > Yes, I know. You can find a configuration featuring a  FM24CL64  FRAM
> > in the LWMON config file ("include/configs/lwmon.h").
> >
> > > My question: Is there an read/write abstraction layer inside of the I2C
> > > stuff of PPCBoot ? I don't know if I should use the bit shifted address
> > > 0x57
> >
> > You mean something like i2c_read() and i2c_write()? Of  course  there
> > is.  And  there  is  also extensive command line support for I2C. Use
> > "help".
> >
> > > instead of 0xAE for calling imd -- I think 0x57. However, upt to now I've
> > > tried both addresses without success.
> >
> > You probably got the address length wrong. See the LWMON board for  a
> > working example.
> >
> > > Ah, just now I see there is a nice tool to scan I2C devices (iprobe). Can
> > > anybody give me an generic command line dump with iprobe in action? I've
> > > ran iprobe but without any success. The only thing I see is:
> > >
> > > => iprobe
> > > Valid chip addresses:
> >
> > Be careful. "iprobe" with the HW I2C code may  take  _very_  long  to
> > complete.  If  you  don't need very fast bulk data transfers (100 kHz
> > clock or more) you will find it  probably  much  simpler  to  use  SW
> > (bitbanging) I2C instead.
> >
> > Here is what I get on a LWMON board:
> >
> >       U-Boot 0.1.1 (Dec  4 2002 - 14:19:27)
> >
> >       CPU:   PPC823EZTnnB2 at 66 MHz: 16 kB I-Cache 8 kB D-Cache
> >       Board: Litronic Monitor IV
> >              Watchdog enabled
> >       I2C:   ready
> >       DRAM:  64 MB
> >       POST spr PASSED
> >       FLASH: 16 MB
> >       KEYBD: Version 1.2
> >       Net:   SCC ETHERNET
> >       POST cache PASSED
> >       POST i2c PASSED
> >       POST cpu PASSED
> >       POST ethernet PASSED
> >       POST spi PASSED
> >       POST usb PASSED
> >       PCMCIA:   No Card found
> >       Hit any key to stop autoboot:  0
> >       => iprobe
> >       Valid chip addresses: 2E 51 52 53 55 56
> >       =>
> >
> > > I think iprobe has not found any valid chip. Is it so ?
> >
> > Seems so.
> >
> > Best regards,
> >
> > Wolfgang Denk
>
>--
>
>======================================================================
>Stephan Linz
>Software Engineer
>
>MAZeT GmbH                   Email:   mailto:linz at mazet.de
>Branche office Jena          Phone:   +49-3641-2809-55
>G?schwitzer Stra?e 32        Fax  :   +49-3641-2809-12
>D-07745 JENA
>Germany
>
>Visit our web-pages: http://www.MAZeT.de
>======================================================================
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Microsoft Visual Studio.NET
>comprehensive development tool, built to increase your
>productivity. Try a free online hosted session at:
>http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
>_______________________________________________
>U-Boot-Users mailing list
>U-Boot-Users at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/u-boot-users



**********************************************************************
This e-mail and any files transmitted with it are confidential and may
be legally privileged or otherwise exempt from disclosure under
applicable law. This e-mail and its files are intended solely for
the individual or entity to whom they are addressed and their content
is the property of Smiths Aerospace.  If you are not the intended
recipient, please do not read, copy, use or disclose this communication.
If you have received this e-mail in error please notify the e-mail 
administrator at postmaster at si.com and then delete this e-mail, its
files and any copies.

This footnote also confirms that this e-mail message has been scanned
for the presence of known computer viruses.
***********************************************************************