Run PCI rom before PCI bus scan??

Hello,
Is there a way to run a PCI rom before the PCI bus scan runs???

Thanks - Joe

[Corey Osgood]

Yep. Take a look in pci_rom.c, there's a function that runs the rom (I think
it's just rom_run but it might be pci_rom_run). It can't go into auto.c,
since it's only in post-ram linuxbios, but there should be somewhere you can
put it (maybe i82801xx.c's i82801xx_init is early enough, or else the pci
domain setup). I can't guarantee that it'll actually work or help, though.
If it does work, do register dumps both before and after the rom runs, and
see what it does, we can probably do the same thing without the rom.

-Corey

On Feb 2, 2008 8:34 PM,  wrote:
> Hello,
> Is there a way to run a PCI rom before the PCI bus scan runs???
>
> Thanks - Joe

[ron minnich]

On Feb 2, 2008 5:34 PM,   wrote:
> Hello,
> Is there a way to run a PCI rom before the PCI bus scan runs???

Yes, we have to do this on any later geode. The LX port should give
you a hint on how it's done.

Thanks

ron

[Carl-Daniel Hailfinger]

On 03.02.2008 03:34, ron minnich wrote:
> On Feb 2, 2008 5:34 PM,   wrote:
> > Hello,
> > Is there a way to run a PCI rom before the PCI bus scan runs???
>
> Yes, we have to do this on any later geode. The LX port should give
> you a hint on how it's done.

Sorry, but how are you going to run a ROM before you know where it is
located? I can see a way to run an image of a PCI ROM before PCI bus
scan if the image resides in main system flash, but otherwise...

Regards,
Carl-Daniel

Quoting Carl-Daniel Hailfinger :
> On 03.02.2008 03:34, ron minnich wrote:
> > On Feb 2, 2008 5:34 PM,   wrote:
> > > Hello,
> > > Is there a way to run a PCI rom before the PCI bus scan runs???
> >
> > Yes, we have to do this on any later geode. The LX port should give
> > you a hint on how it's done.
>
> Sorry, but how are you going to run a ROM before you know where it is
> located? I can see a way to run an image of a PCI ROM before PCI bus
> scan if the image resides in main system flash, but otherwise...
>
> Regards,
> Carl-Daniel

Ok, let me be more specific. I am pretty sure the pci rom for the  
82562ET nic runs and powers on the onboard ethernet device. The nic  
does not have an eeprom. All the device settings are kept in the pci  
rom on the bios. After the rom runs it enables it, sets up PHY  
registers, sets up it PCI config registers, and requests use of the  
PCI bridge. That is why I need it to run before the PCI bus scan.

Make sense?

Thanks - Joe

[ron minnich]

Joe, I think Carl-Daniel is asking: where is the image for the PCI ROM
located? In BIOS flash, as it is on some systems? or on some PCI card?
If on a PCI card, that makes running it before PCI is configured more
"interesting". Not impossible, just harder.

ron

[Carl-Daniel Hailfinger]

On 03.02.2008 17:59, [e-mail] wrote:
> Quoting Carl-Daniel Hailfinger :
> > On 03.02.2008 03:34, ron minnich wrote:
> > > On Feb 2, 2008 5:34 PM,   wrote:
> > > > Hello,
> > > > Is there a way to run a PCI rom before the PCI bus scan runs???
> > >
> > > Yes, we have to do this on any later geode. The LX port should give
> > > you a hint on how it's done.
> >
> > Sorry, but how are you going to run a ROM before you know where it is
> > located? I can see a way to run an image of a PCI ROM before PCI bus
> > scan if the image resides in main system flash, but otherwise...
> >
> > Regards,
> > Carl-Daniel
>
> Ok, let me be more specific. I am pretty sure the pci rom for the  
> 82562ET nic runs and powers on the onboard ethernet device. The nic  
> does not have an eeprom. All the device settings are kept in the pci  
> rom on the bios.

OK, so the PCI ROM is located inside the main system flash. IMO we
should invent a name for such constellations. Off-card ROM?
> After the rom runs it enables it, sets up PHY  
> registers, sets up it PCI config registers, and requests use of the  
> PCI bridge. That is why I need it to run before the PCI bus scan.
>
> Make sense?

Indeed, it does.

Regards,
Carl-Daniel

[ron minnich]

On Feb 3, 2008 12:52 PM, Carl-Daniel Hailfinger <
[e-mail]> wrote:
> OK, so the PCI ROM is located inside the main system flash. IMO we
> should invent a name for such constellations. Off-card ROM?

we pretty much named this  already for VGA.  It is supported in various
mainboards, via Config.lb, so we could do something along those lines. I
can't find a mainboard example right now. Gee, we have a lot of mainboards
now :-)

ron

[Stefan Reinauer]

* [e-mail]  [080203 02:34]:
> Hello,
> Is there a way to run a PCI rom before the PCI bus scan runs???

Running a _PCI_ ROM without knowing where the PCI device lives (ie.
before the _scan_) sounds impossible to me. There might be something
wrong with the approach. Why do you want/need to do this?

We do execute 16bit bios binary chunks in vm86 mode before the pci scan
on geode. But those are not option roms but VSA that are required to
make some virtual devices appear at all.

Stefan

Quoting Stefan Reinauer :
> [e-mail]  [080203 02:34]:
> > Hello,
> > Is there a way to run a PCI rom before the PCI bus scan runs???
>
> Running a _PCI_ ROM without knowing where the PCI device lives (ie.
> before the _scan_) sounds impossible to me.

Shouldn't be impossible if you manually told coreboot where the PCI  
device lives.
> There might be something
> wrong with the approach. Why do you want/need to do this?

Again. coreboot is not able to find the 82562ET onboard nic. The  
lights on the nic are not coming on. And there is no eeprom,  
everything comes from the pci rom in the bios.

Here is what I think the PCI rom does with the original bios:

1. powers on and enables device
2. sets up PHY registers
3. sets up it PCI config registers
4. and requests use of the PCI bridge

If I could figure out how to do #1 the rest would be fairly simple to  
setup,although I am not exactly sure about PHY registers. Then I  
wouldn't need the pci rom at all.
> Joe, I think Carl-Daniel is asking: where is the image for the PCI ROM
> located? In BIOS flash, as it is on some systems? or on some PCI card?
> If on a PCI card, that makes running it before PCI is configured more
> "interesting". Not impossible, just harder.

Yes, the pci rom currently lives in the bios. It is a three part rom,  
Intel boot agent, Intel PXE, and the base code (I think the base code  
is the only real part I need??).

Thanks - Joe

[Peter Stuge]

On Sun, Feb 03, 2008 at 02:44:43PM -0500, [e-mail] wrote:
> Yes, the pci rom currently lives in the bios. It is a three part
> rom, Intel boot agent, Intel PXE, and the base code (I think the
> base code is the only real part I need??).

Intel southbridges support "flash sharing" so that both the system
CPU and the NIC can use one and the same flash chip.

If there is indeed a blob in the factory BIOS that is required for
your NIC to operate, then you'll have to teach coreboot about this
flash sharing scheme. At the very least it will require putting the
NIC blob at a predefined location in flash, but I doubt it stops
there.

Since your NIC is onboard and does not work I suppose this is what
you're up against.

//Peter

[Tom Sylla]

[e-mail] wrote:
> Here is what I think the PCI rom does with the original bios:
> powers on and enables device
> sets up PHY registers
> sets up it PCI config registers
> and requests use of the PCI bridge
>
> If I could figure out how to do #1 the rest would be fairly simple to  
> setup,although I am not exactly sure about PHY registers. Then I  
> wouldn't need the pci rom at all.

I'm not sure it really works this way. A normal platform has some 
mechanism to set the default values for the LAN config registers. It can 
be a dedicated SPI ROM, or a dedicated chunk of your boot ROM, or you 
could program them in your BIOS. I would guess that a PCI ROM is 
expecting all of those registers to have been programmed already. 
Furthermore, many of those settings are *platform specific*, so they 
would not be in any sort of generic PCI ROM that you would get from 
Intel, or generate using their tools.

I recently designed a platform with an 82571 Intel LOM, and I programmed 
proper values in the SPI, and don't load any PCI ROM at all. It works 
fine in all OSes. The PCI ROM usually just provides things like PXE or 
manageability stuff.

You need to figure out how your platform is handling this. I think it is 
unlikely that the PCI expansion ROM is doing what you think it is.

Quoting Tom Sylla :
> [e-mail] wrote:
> > Here is what I think the PCI rom does with the original bios:
> > powers on and enables device
> > sets up PHY registers
> > sets up it PCI config registers
> > and requests use of the PCI bridge
> >
> > If I could figure out how to do #1 the rest would be fairly simple   
> > to  setup,although I am not exactly sure about PHY registers. Then   
> > I  wouldn't need the pci rom at all.
>
> I'm not sure it really works this way. A normal platform has some
> mechanism to set the default values for the LAN config registers. It
> can be a dedicated SPI ROM, or a dedicated chunk of your boot ROM, or
> you could program them in your BIOS. I would guess that a PCI ROM is
> expecting all of those registers to have been programmed already.
> Furthermore, many of those settings are *platform specific*, so they
> would not be in any sort of generic PCI ROM that you would get from
> Intel, or generate using their tools.
>
> I recently designed a platform with an 82571 Intel LOM, and I
> programmed proper values in the SPI, and don't load any PCI ROM at all.
> It works fine in all OSes. The PCI ROM usually just provides things
> like PXE or manageability stuff.
>
> You need to figure out how your platform is handling this. I think it
> is unlikely that the PCI expansion ROM is doing what you think it is.

Thanks Tom, This makes alot of sense. All the million pages of  
documentation I have read, and read they talk about an eeprom (which  
is the SPI???) and an PCI rom. I guess I am getting the two confused.  
This board has an Intel 82562ET LOM.
How do I access the SPI rom in linux (read/dump/write)? I found this  
program called eepro100-diag and/or ethtool that is supposed to be  
able to this but have not tried them yet. Also Intel speaks of an PHY  
register is that the register that is in the SPI. Thanks for your  
help. I hope you won't mind helping me on this, seeing you have  
already done it before?

Thanks - Joe

Hello,
I would like to report that with ethtool under the original bios I am  
able to dump the 82562ET eeprom registers:

0010 957a d175 1a03 0000 0201 4701 0000
0000 0000 49b2 0000 8086 007f 0000 0000
8080 8080 7a7a 7a7a bd90 60b3 0000 7454
8bab 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 1039 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0128 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 4030 0000 0000 0000 c731

According to the datasheet:

http://download.intel.com/design/network/applnots/ap409.pdf

There are a few registers out of the norm. I am going to re-program  
them back to their defaults and try coreboot again?? One major  
difference I noticed is Linux is detecting the device id of 103Ah and  
the eeprom has a device id of 1039h (this value should be correct).  
Could the incorrect device id cause the PCI bridge scan not to detect  
the device?

Thanks - Joe

[ron minnich]

On Feb 4, 2008 4:49 AM,   wrote:
> Could the incorrect device id cause the PCI bridge scan not to detect
> the device?

That's very unlikely.

ron

[Rudolf Marek]

> difference I noticed is Linux is detecting the device id of 103Ah and  
> the eeprom has a device id of 1039h (this value should be correct).

This is written in some datasheet (IMHO ICH4) It means that the ROM values were 
not used. I tried to help you so I read some datahsets but without any luck to 
ROMchip. Maybe you can try to scan original bios for same values as there are in 
the EEPROM. Maybe there is somewhere a pointer to them.

Rudolf

So I found this in the ICH4 datasheet:

The LAN controller enters Wake on LAN mode after reset if the Wake on  
LAN bit in the EEPROM is set *(which it is)*. At this point, the LAN  
controller is in the D0u state. When the LAN controller is in Wake on  
LAN mode:
? The LAN controller scans incoming packets for a Magic Packet and  
asserts the PME# signal for 52 ms when a one is detected in Wake on  
LAN mode.
? The Activity LED changes its functionality to indicates that the  
received frame passed Individual Address (IA) filtering or broadcast  
filtering.
? The PCI Configuration registers are accessible to the host *(this is  
what I'm looking for!!)*.
The LAN controller switches from Wake on LAN mode to the D0a power  
state following

So, if this is correct I think I was right in saying the nic seemed  
like it was powered off?? At this point I need to figure out how to  
assert a PME# signal to wake up the nic. Maybe from the Power  
Managment Control register??

Thanks - Joe

[Peter Stuge]

On Tue, Feb 05, 2008 at 10:51:39AM -0500, [e-mail] wrote:
> So I found this in the ICH4 datasheet:
>
> The LAN controller enters Wake on LAN mode after reset if the Wake
> on LAN bit in the EEPROM is set *(which it is)*.

You could try changing this bit in the EEPROM before running
coreboot and see if you get different results from the PCI scan.
> When the LAN controller is in Wake on LAN mode:
> ? The LAN controller scans incoming packets for a Magic Packet and  
> asserts the PME# signal for 52 ms when a one is detected in Wake on  
> LAN mode.

..
> ? The PCI Configuration registers are accessible to the host *(this
> is what I'm looking for!!)*.

Right, and this says that they are accessible even when the NIC is in
WoL mode.
> So, if this is correct I think I was right in saying the nic seemed
> like it was powered off?? At this point I need to figure out how to
> assert a PME# signal to wake up the nic. Maybe from the Power
> Managment Control register??

Note that PME# is asserted by the NIC. Ie. PME# is considered an
output from the NIC. Remember that Wake on LAN means that the NIC
wakes up the computer if a special packet is received.

I'm afraid I don't think this is causing the problem you're seeing.
:\

//Peter

[Corey Osgood]

> From the datasheet:

"In the LAN controller the D0 state is partitioned into two substates, D0
Uninitialized (D0u) and D0 Active (D0a). [...] Initialization of the CSR,
Memory, or I/O Base Registers in the PCI Configuration space switches the
LAN controller D0u state to the D0a state."

and

"The integrated LAN controller will be disabled if no Platform LAN Connect
component is detected (See Section 5.2.1.3)."

Any help?

-Corey

On Feb 5, 2008 11:44 AM, Peter Stuge  wrote:
> On Tue, Feb 05, 2008 at 10:51:39AM -0500, [e-mail]:
> > So I found this in the ICH4 datasheet:
> >
> > The LAN controller enters Wake on LAN mode after reset if the Wake
> > on LAN bit in the EEPROM is set *(which it is)*.
>
> You could try changing this bit in the EEPROM before running
> coreboot and see if you get different results from the PCI scan.
> > When the LAN controller is in Wake on LAN mode:
> > ? The LAN controller scans incoming packets for a Magic Packet and
> > asserts the PME# signal for 52 ms when a one is detected in Wake on
> > LAN mode.
>
> ..
> > ? The PCI Configuration registers are accessible to the host *(this
> > is what I'm looking for!!)*.
>
> Right, and this says that they are accessible even when the NIC is in
> WoL mode.
> > So, if this is correct I think I was right in saying the nic seemed
> > like it was powered off?? At this point I need to figure out how to
> > assert a PME# signal to wake up the nic. Maybe from the Power
> > Managment Control register??
>
> Note that PME# is asserted by the NIC. Ie. PME# is considered an
> output from the NIC. Remember that Wake on LAN means that the NIC
> wakes up the computer if a special packet is received.
>
> I'm afraid I don't think this is causing the problem you're seeing.
> :\
>
> //Peter

[Peter Stuge]

On Tue, Feb 05, 2008 at 02:49:52PM -0500, Corey Osgood wrote:
> "In the LAN controller the D0 state is partitioned into two substates
>
> and
>
> "The integrated LAN controller will be disabled if no Platform LAN
> Connect component is detected (See Section 5.2.1.3)."
>
> Any help?

The first one isn't that interesting since it also implies that PCI
config regs are actually available.

The second one, or rather section 5.2.1.3, could be interesting if
"Platform LAN Connect component" is usually found in the BIOS.

//Peter

[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.  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 Karasek
MTS
Sun Microsystems
mailto:[e-mail]
ph:770.360.6415
*********************/

Peter Stuge wrote:
> On Tue, Feb 05, 2008 at 02:49:52PM -0500, Corey Osgood wrote:
> > "In the LAN controller the D0 state is partitioned into two substates
> >
> > and
> >
> > "The integrated LAN controller will be disabled if no Platform LAN
> > Connect component is detected (See Section 5.2.1.3)."
> >
> > Any help?
>
> The first one isn't that interesting since it also implies that PCI
> config regs are actually available.
>
> The second one, or rather section 5.2.1.3, could be interesting if
> "Platform LAN Connect component" is usually found in the BIOS.
>
> //Peter

[Corey Osgood]

On Feb 7, 2008 12:45 PM, Marc Karasek  wrote:
> 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.

Hmm, no intel eeprom, but I do see a chip marked "atmel532", which google
says is a serial eeprom, less than half an inch from the southbridge.
Possible winner?

-Corey
> The eeprom image was protected by a CRC and if the CRC failed it would
> not load the image.  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 Karasek
> MTS
> Sun Microsystems
> mailto:[e-mail]
> ph:770.360.6415
> *********************/
>
> Peter Stuge wrote:
> > On Tue, Feb 05, 2008 at 02:49:52PM -0500, Corey Osgood wrote:
> > > "In the LAN controller the D0 state is partitioned into two substates
> > >
> > > and
> > >
> > > "The integrated LAN controller will be disabled if no Platform LAN
> > > Connect component is detected (See Section 5.2.1.3)."
> > >
> > > Any help?
> >
> > The first one isn't that interesting since it also implies that PCI
> > config regs are actually available.
> >
> > The second one, or rather section 5.2.1.3, could be interesting if
> > "Platform LAN Connect component" is usually found in the BIOS.
> >
> > //Peter

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:
1. When the system is powered on "At this point, the LAN
controller is in the D0u state"

2. 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).

3. At this point it goes into a DOa state.

3. 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"

4. 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