Re: [coreboot] Run PCI rom before PCI bus scan??

[Corey Osgood]

Another missed cc.

On Feb 7, 2008 5:46 PM, Corey Osgood  wrote:
> On Feb 7, 2008 5:02 PM,  wrote:
> > Quoting Marc Karasek :
> > > Let me add me two cents..
> > >
> > > I have dealt with the Intel MACs in the past so let me dreg up some
> > > memorries...
> > >
> > > From what I recall,  you had a serial eeprom on the board that
> > > contained the init for the chip.  This was the 82545GM.
> > >
> > > The eeprom image was protected by a CRC and if the CRC failed it would
> > > not load the image.
> >
> > By CRC do you mean checksum? There is a checksum in the eeprom.
> > > The device would also not be visible on the PCI
> > > Bus unless the eeprom was loaded.  I have attached the 82545 eeprom
> > > spec sheet (freely avail from Intel) maybe this will give you some
> > > insight.
> > >
> > > Intel has a program to read/update the paramters.  I never used it,
> > > mainly because I was on an embedded system running MIPS-Linux and they
> > > would only provide a x86 binary, no src code.   It took me a couple of
> > > iterations to get the eeprom right.  Maybe you can get the utility
> >
> > from
> > > Intel and dump the eeprom. What I do not understand is why you would
> >
> > be
> > > having problems with coreboot.  the only thing I can guess is the
> > > default eeprom is putting the MAC into a state that the BIOS must take
> > > it out of (maybe WoL).  Did you say you have the spec sheet for the
> > > part and it talks about the eeprom?
> >
> > Marc I am able to read the eeprom in Linux with ethtool. Wol is
> > enabled. This is a 82562ET chipset (same family). Corey, I am pretty
> > sure that atmel chip is the eeprom. Again, here is what I think needs
> > to be done:
> >
> > OK, here is what I have picked up reading, reading, and more reading:
> > When the system is powered on "At this point, the LAN
> >
> > controller is in the D0u state"
> > The "Platform LAN Connect component" is actually a command script
> >
> > (probibly a rom written in assembly) runs and sets up the CSR register
> > (I could setup a script in the mainboard directory and run from auto.c).
> >
> > At this point it goes into a DOa state.
> >
> > The "Platform LAN Connect component" hands it over to the bios
> >
> > (coreboot) to setup "Memory, or I/O Base Registers in the PCI
> > Configuration space"
> > nic is setup and ready to go!
> >
> > What do you think?
> >
> > The only thing I am not sure of is how to read/write to the CSR
> > register???
> >
> > Thanks - Joe
>
> I apologize if this seems disorganized, I'm trying to work it out:
>
> 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.
>
> 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.
>
> 3: reset the lan controller? write 1 to bit 3 of 0x1c. Wait 1ms
> afterwards.
>
> Good luck, hope this helps
> -Corey

Run PCI rom before PCI bus scan??

Quoting Corey Osgood :
> > I apologize if this seems disorganized, I'm trying to work it out:
> >
> > 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.
> >
> > 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.
> >
> > 3: reset the lan controller? write 1 to bit 3 of 0x1c. Wait 1ms
> > afterwards.
> >
> > Good luck, hope this helps

I think your right Corey, we need to setup space for for the CSR  
register first:

Control/Status Register (CSR) Accesses
The integrated LAN controller supports zero wait-state single cycle  
memory or I/O mapped accesses to its CSR space. Separate BARs request  
4 KB of memory space and 64 bytes of I/O space to accomplish this.  
Based on its needs, the software driver will use either memory or I/O  
mapping to access these registers. The LAN controller provides four  
valid Kbytes of CSR space, which include the following elements:
? System Control Block (SCB) registers ***(I know for a fact this is  
part of the pci rom)***
? PORT register
? EEPROM control register
? MDI control register
? Flow control registers
In the case of accessing the Control/Status Registers, the processor  
is the initiator and the LAN controller is the target.
Read Accesses: The processor, as the initiator, drives address lines  
AD[31:0], the command and byte enable lines C/BE[3:0]# and the control  
lines IRDY# and FRAME#. As a slave, the LAN controller controls the  
TRDY# signal and provides valid data on each data access. The LAN  
controller allows the processor to issue only one read cycle when it  
accesses the Control/Status Registers, generating a disconnect by  
asserting the STOP# signal. The processor can insert waitstates by  
deasserting IRDY# when it is not ready.
Write Accesses: The processor, as the initiator, drives the address  
lines AD[31:0], the command and byte enable lines C/BE[3:0]# and the  
control lines IRDY# and FRAME#. It also provides the LAN controller  
with valid data on each data access immediately after asserting IRDY#.  
The LAN controller controls the TRDY# signal and asserts it from the  
data access. The LAN controller allows the processor to issue only one  
I/O write cycle to the Control/Status Registers, generating a  
disconnect by asserting the STOP# signal. This is true for both memory  
mapped and I/O mapped accesses.

How to do this???

Thanks - Joe

Run PCI rom before PCI bus scan??

[Peter Stuge]

On Fri, Feb 08, 2008 at 08:55:50AM -0500, [e-mail] wrote:
> > > 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.
>
> I think your right Corey, we need to setup space for for the CSR
> register first:
>
> Control/Status Register (CSR) Accesses
> The integrated LAN controller supports zero wait-state single cycle
> memory or I/O mapped accesses to its CSR space. Separate BARs
> request 4 KB of memory space and 64 bytes of I/O space to
> accomplish this.

This is unfortunately at a later point in time. Anything to do with
CSR needs PCI config registers to be working properly. One hint is
"BARs" - Base Address Registers, which are stored in PCI config
registers.

Sorry I keep shooting down ideas. :\

//Peter

Run PCI rom before PCI bus scan??

Quoting Peter Stuge :
> This is unfortunately at a later point in time. Anything to do with
> CSR needs PCI config registers to be working properly. One hint is
> "BARs" - Base Address Registers, which are stored in PCI config
> registers.
>
> Sorry I keep shooting down ideas. :\
>
> //Peter

That's ok Peter. I'm starting to wonder if the nic problem is getting  
to complicated. As an alternative I'm thinking about just writing a  
script that would disable the Wol in the eeprom before the RM4100 user  
flashes their device with coreboot. This way the nic would power on  
like a normal pci device?

I am having problems writing to the eeprom with ethtool.

ethtool -E ethX [magic N] [offset N] [value N]

-E     Changes EEPROM byte for the specified ethernet  device.   offset
               and value specify which byte and it?s new value.  Because of the
               persistent nature of writing to the  EEPROM,  a  device-specific
               magic key must be specified to prevent the accidental writing to
               the EEPROM.

No matter what I try for the magic key I keep getting:

[root@localhost ~]# /usr/sbin/ethtool -E eth0 magic 0xXXXX offset 0x15  
value 0x82
Cannot set EEPROM data: Invalid argument

What is the magic key supposed to be?

Thanks - Joe

Run PCI rom before PCI bus scan??

I think I figured out what is going on here. According to this doc:

http://www.intel.com/design/network/applnots/ap417.pdf

ICHx Integrated LAN Controller Function Disable and Power Control for  
Fast Ethernet

I think what this is saying is the Lan Enable is controlled by a  
signal from either a Super I/O GPIO, ICHx Resume-well GPIO, or  
micro-controller output. The signal is sent to the LAN_RST# pin on the  
ICH4.

To test this theory, I disabled the Lan in the original bios and  
rebooted. It does the exact same thing that coreboot is currently  
doing???

So I guess now I need to figure out where the signal is coming from??  
Can anyone shed some light on this?

Thanks - Joe