Another missed cc.<br><br><div class="gmail_quote">On Feb 7, 2008 5:46 PM, Corey Osgood <<a href="mailto:corey.osgood@gmail.com">corey.osgood@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On Feb 7, 2008 5:02 PM,  <<a href="mailto:joe@smittys.pointclark.net" target="_blank">joe@smittys.pointclark.net</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div>Quoting Marc Karasek <<a href="mailto:Marc.Karasek@Sun.COM" target="_blank">Marc.Karasek@Sun.COM</a>>:<br><br>> Let me add me two cents..<br>><br>> I have dealt with the Intel MACs in the past so let me dreg up some<br>

> memorries...<br>><br>> From what I recall,  you had a serial eeprom on the board that<br>> contained the init for the chip.  This was the 82545GM.<br>><br>> The eeprom image was protected by a CRC and if the CRC failed it would<br>

> not load the image.<br><br></div>By CRC do you mean checksum? There is a checksum in the eeprom.<br><div><br>> The device would also not be visible on the PCI<br>> Bus unless the eeprom was loaded.  I have attached the 82545 eeprom<br>

> spec sheet (freely avail from Intel) maybe this will give you some<br>> insight.<br>><br>> Intel has a program to read/update the paramters.  I never used it,<br>> mainly because I was on an embedded system running MIPS-Linux and they<br>

> would only provide a x86 binary, no src code.   It took me a couple of<br>> iterations to get the eeprom right.  Maybe you can get the utility from<br>> Intel and dump the eeprom. What I do not understand is why you would be<br>

> having problems with coreboot.  the only thing I can guess is the<br>> default eeprom is putting the MAC into a state that the BIOS must take<br>> it out of (maybe WoL).  Did you say you have the spec sheet for the<br>

> part and it talks about the eeprom?<br>><br></div>Marc I am able to read the eeprom in Linux with ethtool. Wol is<br>enabled. This is a 82562ET chipset (same family). Corey, I am pretty<br>sure that atmel chip is the eeprom. Again, here is what I think needs<br>

to be done:<br><div><br>OK, here is what I have picked up reading, reading, and more reading:<br></div><div>1. When the system is powered on "At this point, the LAN<br>controller is in the D0u state"<br>
<br></div><div>2. The "Platform LAN Connect component" is actually a command script<br>(probibly a rom written in assembly) runs and sets up the CSR register<br></div><div>(I could setup a script in the mainboard directory and run from auto.c).<br>

<br></div><div>3. At this point it goes into a DOa state.<br><br></div><div>3. The "Platform LAN Connect component" hands it over to the bios<br></div>(coreboot) to setup "Memory, or I/O Base Registers in the PCI<br>

Configuration space"<br><div><br>4. nic is setup and ready to go!<br><br>What do you think?<br><br></div>The only thing I am not sure of is how to read/write to the CSR register???<br><br><br>Thanks - Joe<br>
</blockquote></div><br><br><br></div></div>I apologize if this seems disorganized, I'm trying to work it out:<br><br>1: set up csr memory/io base in the nic. ami bios uses 0xff7ff000 for mem base, and 0xdc01 as io base, these values should work to test with. Datasheet contradicts itself, says bits 3:0 of the mem base registers are all hardwired to 0, then gives a default value of 0x8.<br>

<br>2: write 0x3 to register 0xe (in IO space?) to enable the rom and clock. if this is io space, the write is just outb(val, (NIC_IO_BASE + reg)). There are reserved registers, so be sure to do a read-modify-write.<br><br>

3: reset the lan controller? write 1 to bit 3 of 0x1c. Wait 1ms afterwards.<br><br>Good luck, hope this helps<br><font color="#888888">-Corey<br>
</font></blockquote></div><br>