Re: [U-Boot-Users] EEPROM content and multiple NIC
--- 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@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@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
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,
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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..
participants (3)
-
Daniel Ann -
Frank -
Kylo Ginsberg