[U-Boot-Users] EEPROM content and multiple NIC

[U-Boot-Users] EEPROM content and multiple NIC

[Daniel Ann]

I'm very curious about this output I'm getting,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
        00  14  100b  0020  0200  ff
In:    serial
Out:   serial
Err:   serial
Net:   natsemi: EEPROM contents:
 d008 0001 0001 0001 0001 0001 0001 0001 0001 0001 1841 0001
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

As far as I know, NS83815 manual claims that d008 is a default value
for vendor ID. but pci_ids thinks 100b is National semiconductor's
vendor ID. Does anyone know why the difference ?

Also, board Im using has EEPROM to configure the NIC during reset. And
it contains 100b (shown on first line of output), however, print out
of EEPROM from natsemi.c shows d008 as written in the NS83815 manual.

I'm reading the natsemi.c but I just cant see why it would read some
other value. This is a cut out of the source from natsemi.c

-------------cut--------------
        printf("natsemi: EEPROM contents:\n");
        for (i = 0; i <= EEPROM_SIZE; i++) {
            short eedata = read_eeprom(dev, EECtrl, i);
            printf(" %04hx", eedata);
        }
----------end cut-----------

EEPROM_SIZE = 12 <- correct
EECtrl = 0x08 <- correct too

Another question is, I have several NIC. When I do tftpboot from first
card, works. It prints out,
Using dp83815#0 device

Next, when I remove the cable from first card, insert it to second
card, run the same command, it works, and prints out,
Using dp83815#0 device

I'm pretty sure it should print out "Using dp83815#1 device". Possibly
failed attempt from using dp83815#0 device. What do you all think?

I havent looked@it deeper enuf, but if I can get some shared
thoughts it would help me out great deal.


-- 
Daniel

[U-Boot-Users] EEPROM content and multiple NIC

[Mark Rakes]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Apr 19, 2005, at 10:24 PM, Daniel Ann wrote:
> I'm very curious about this output I'm getting,
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>         00  14  100b  0020  0200  ff
...
> Net:   natsemi: EEPROM contents:
>  d008 0001 0001 0001 0001 0001 0001 0001 0001 0001 1841 0001
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> As far as I know, NS83815 manual claims that d008 is a default value
> for vendor ID. but pci_ids thinks 100b is National semiconductor's
> vendor ID. Does anyone know why the difference ?
d008 == 1101000000001000
100b == 0001000000001011

It's been a long, long time since I touched/looked at this code (or the
docs!), so don't ask me why this is like it is, but, there you have 
it...

I do remember that getting MAC addresses into the EEPROM wasn't much
fun because of the shifting required to get the bits into the right
places.

hope this helps,
- -mark rakes


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.0 (Build 1917)
Comment: secure:

iQA/AwUBQmXxor7wvj+mn5e0EQJZQwCgxlk6DqwQjjZRQENWEHFKPONxe2EAoN7D
Kw8DfjjKiOeVhNbiyvYs3tb9
=QHgw
-----END PGP SIGNATURE-----

[U-Boot-Users] EEPROM content and multiple NIC

[Daniel Ann]

On 4/20/05, Mark Rakes <mrakes@mac.com> wrote:
> d008 == 1101000000001000
> 100b == 0001000000001011
> 
> It's been a long, long time since I touched/looked at this code (or the
> docs!), so don't ask me why this is like it is, but, there you have
> it...

Hahahaha... This is so funny. Its amazing how simple one can get if
you just know why.

Thanks mark.

-- 
Daniel

[U-Boot-Users] EEPROM content and multiple NIC

[Frank]

--- Daniel Ann <ktdann@gmail.com> wrote:
> On 4/20/05, Mark Rakes <mrakes@mac.com> wrote:
> > d008 == 1101000000001000
> > 100b == 0001000000001011
> > 
> > It's been a long, long time since I touched/looked at this
> code (or the
> > docs!), so don't ask me why this is like it is, but, there
> you have
> > it...
> 
> Hahahaha... This is so funny. Its amazing how simple one can
> get if
> you just know why.
> 
Looks like an endian issue to me. Just do a byte swap...
> Thanks mark.
> 
> -- 
> Daniel
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time
> involved in
> creating, integrating, and deploying reporting solutions. Free
> runtime info,
> new features, or free trial, at:
> http://www.businessobjects.com/devxi/728
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[U-Boot-Users] EEPROM content and multiple NIC

[Wolfgang Denk]

In message <20050420144405.70123.qmail@web32203.mail.mud.yahoo.com> you wrote:
> 
> > > d008 == 1101000000001000
> > > 100b == 0001000000001011
...
> Looks like an endian issue to me. Just do a byte swap...

No, not at all. Endianess affects the BYTE order, i. e. the  sequence
of bytes, but not the positions of the bits in a byte.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What the gods would destroy they first submit to  an  IEEE  standards
committee.

[U-Boot-Users] EEPROM content and multiple NIC

[Frank]

--- Wolfgang Denk <wd@denx.de> wrote:
> In message
> <20050420144405.70123.qmail@web32203.mail.mud.yahoo.com> you
> wrote:
> > 
> > > > d008 == 1101000000001000
> > > > 100b == 0001000000001011
> ...
> > Looks like an endian issue to me. Just do a byte swap...
> 
> No, not at all. Endianess affects the BYTE order, i. e. the 
> sequence
> of bytes, but not the positions of the bits in a byte.
> 
> Best regards,
Oops, you're right, I meant the bits appear to be reversed. Like
they were shifted in bit 0 first and the other bit 31 first...
> 
> Wolfgang Denk
> 
> -- 
> Software Engineering:  Embedded and Realtime Systems, 
> Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> wd at denx.de
> What the gods would destroy they first submit to  an  IEEE 
> standards
> committee.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time
> involved in
> creating, integrating, and deploying reporting solutions. Free
> runtime info,
> new features, or free trial, at:
> http://www.businessobjects.com/devxi/728
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[U-Boot-Users] EEPROM content and multiple NIC

[Daniel Ann]

On 4/21/05, Frank <frannk_m1@yahoo.com> wrote:
> > > > > d008 == 1101000000001000
> > > > > 100b == 0001000000001011

> Oops, you're right, I meant the bits appear to be reversed. Like
> they were shifted in bit 0 first and the other bit 31 first...

yeah.. you guys are right. It aint endian issue. Funny thing is,
NS83815 manual thinks d008, while pci_ids file thinks 100b.

I still have no idea how one could actually read it this way. I dont
think any right mind will delibrately read it this way.
I guess a dive into the code will help but.. gonna leave it for later :P

Anyway, got my EEPROM content right this time. And all is working
smoothly. As u-boot boots its displaying the content of EEPROM in
exactly the fashion shown above.


-- 
Daniel

[U-Boot-Users] EEPROM content and multiple NIC

[Kylo Ginsberg]

Daniel,

I haven't used this part but took a look at the manual.  Please note
that PCI configuration registers include Vendor ID (at offset 0x00)
and Subsystem Vendor ID (at offset 0x2c).  Look in linux/pci.h.  On
this part, the former is read-only always 0x100b, the latter can be
read from EEPROM.

Compounding the confusion is the god-awful bit-swapping method of
access to the EEPROM.  And then someone at National who was either
confused or had a sick sense of humor apparently provided EEPROM
defaults for the Subsystem Vendor Id (0x2c) and Subsystem Device Ids
(0x2e) that are bitswapped versions of the main Vendor Id (0x00) and
Device Id (0x02).  Ugh.

Kylo

On 4/21/05, Daniel Ann <ktdann@gmail.com> wrote:
> On 4/21/05, Frank <frannk_m1@yahoo.com> wrote:
> > > > > > d008 == 1101000000001000
> > > > > > 100b == 0001000000001011
> 
> > Oops, you're right, I meant the bits appear to be reversed. Like
> > they were shifted in bit 0 first and the other bit 31 first...
> 
> yeah.. you guys are right. It aint endian issue. Funny thing is,
> NS83815 manual thinks d008, while pci_ids file thinks 100b.
> 
> I still have no idea how one could actually read it this way. I dont
> think any right mind will delibrately read it this way.
> I guess a dive into the code will help but.. gonna leave it for later :P
> 
> Anyway, got my EEPROM content right this time. And all is working
> smoothly. As u-boot boots its displaying the content of EEPROM in
> exactly the fashion shown above.
> 
> --
> Daniel
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime info,
> new features, or free trial, at: http://www.businessobjects.com/devxi/728
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 
>

[U-Boot-Users] EEPROM content and multiple NIC

[Daniel Ann]

On 4/22/05, Kylo Ginsberg <kylo.ginsberg@gmail.com> wrote:
> Compounding the confusion is the god-awful bit-swapping method of
> access to the EEPROM.  And then someone at National who was either
> confused or had a sick sense of humor apparently provided EEPROM
> defaults for the Subsystem Vendor Id (0x2c) and Subsystem Device Ids
> (0x2e) that are bitswapped versions of the main Vendor Id (0x00) and
> Device Id (0x02).  Ugh.

I take it its an explanation right ? :)
Yeah.. Ugh indeed. I guess its that somebody who obviously had one
drink too many would know why then.

Interesting.. 


-- 
Daniel