There is overlapping between prefmem and mem.
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] io <node 0 link 0> PCI: 00:18.0 1b8 <- [0x0000000000 - 0x000fffffff] prefmem <node 0 link 0> PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fe1fffff] mem <node 0 link 0> PCI: 00:18.0 1da <- [0x0000004000 - 0x0000004fff] io <node 0 link 2> PCI: 00:18.0 1aa <- [0x0100800000 - 0x01007fffff] prefmem <node 0 link 2> PCI: 00:18.0 1a2 <- [0x00fe200000 - 0x00fe4fffff] mem <node 0 link 2>
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart> PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart> PCI: 00:19.0 1c8 <- [0x0000005000 - 0x0000005fff] io <node 1 link 0> PCI: 00:19.0 198 <- [0x00f8000000 - 0x01007fffff] prefmem <node 1 link 0> PCI: 00:19.0 190 <- [0x00fe500000 - 0x00fe6fffff] mem <node 1 link 0>
-----Original Message----- From: YhLu Sent: Monday, October 18, 2004 2:29 PM To: 'ebiederman@lnxi.com' Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS' Subject: RE: FYI: Merge in progress...
self.firstparentdevicelink()
How about IORESOURCE_FIXED ?
static void pnp_set_resource(device_t dev, struct resource *resource) { if (!(resource->flags & IORESOURCE_ASSIGNED)) { printk_err("ERROR: %s %02x not allocated\n", dev_path(dev), resource->index); return; }
-----Original Message----- From: ebiederman@lnxi.com [mailto:ebiederman@lnxi.com] Sent: Monday, October 18, 2004 2:22 PM To: YhLu Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS' Subject: Re: FYI: Merge in progress...
YhLu YhLu@tyan.com writes:
It should config.g bug, there is some un consistent.
It could be. I should have fixed this Saturday, but...
Looking Hmm...
For dev33 and it sibling should be .bus = &_dev4.link[2], instead of .bus = &_dev4.link[0],
Good catch. We do not yet have the link of the parent device set properly in the .bus field. It is always hard coded to 0 :(
Ok the fix looks easy, committed.
Hopefully I have not missed any other cases...
Eric
On Mon, 18 Oct 2004, YhLu wrote:
There is overlapping between prefmem and mem.
Dr. Lu, we could not ask for a better tester than you!
Thanks for your patience ... I realize we did break things a bit last week!
Thanks
ron
I've been reading this new v2 stuff with some interest. I may be able to finde time to move the 440bx stuff over into v2. We've hired a big gun PCI guru to help find our problems that have been keeping me from getting video to work.
While he's working on that and I'm playing gopher boy, I may be able to scratch in some v2 conversion work. What v2 boards have a working SPD implementation?
Whats all this new stuff mean for those of us without these fancy new wizbang chipsets and only 1 pci bus?
Richard Smith rsmith@bitworks.com writes:
I've been reading this new v2 stuff with some interest. I may be able to finde
time to move the 440bx stuff over into v2. We've hired a big gun PCI guru to help find our problems that have been keeping me from getting video to work.
While he's working on that and I'm playing gopher boy, I may be able to scratch in some v2 conversion work. What v2 boards have a working SPD implementation?
I think everything except the epia. I wish I could point you at a simple port.
Whats all this new stuff mean for those of us without these fancy new wizbang chipsets and only 1 pci bus?
Possibly an extra nesting level in Config.lb. If you have a PCI slot you can still have multiple busses.
Hmm. I suspect your configuration would look something like:
Except that some of the unused parts don't compile out it really should be fairly simple.
chip northbridge/intel/440bx device pci_domain 0 on device pci 0.0 on end # memory controller device pci 0.1 on end # PCI-PCI bridge? chip southbridge/intel/piix4e device pci 12.0 on end # ISA bridge device pci 12.1 on end # IDE controller device pci 12.2 on end # USB host controller device pci 12.3 on end # Power management registers end end device apic_cluster 0 on chip cpu/intel/slot_2 device apic 0 on end end end end
Eric
Eric W. Biederman wrote:
Hmm. I suspect your configuration would look something like:
chip northbridge/intel/440bx device pci_domain 0 on
Ok so I guess I'll start asking questions. "pci_domain" this is the top level I guess? Where are all the different device types listed at?
The use of "on" this is on as in on/off and not "this item is on this item"
Is the order of the config file related to the order of the init sequence the code generates?
device apic_cluster 0 on chip cpu/intel/slot_2 device apic 0 on end end endend
So after I fix up this example to match our board where would my board specific code go? Is there still a mainboard.c? I've got things that disable the secondary IDE controller and a few other specials.
Richard Smith rsmith@bitworks.com writes:
Eric W. Biederman wrote:
Hmm. I suspect your configuration would look something like:
chip northbridge/intel/440bx device pci_domain 0 on
Ok so I guess I'll start asking questions. "pci_domain" this is the top level I guess? Where are all the different device types listed at?
src/include/device/path.h
The use of "on" this is on as in on/off and not "this item is on this item"
Correct. It is there so we do things like disable unused integrated hardware.
Is the order of the config file related to the order of the init sequence the code generates?
Roughly. Yes.
The compile time information is merged with what can be found dynamically. The resources are allocated (much like v1 pci devices) but the methods can be overridden.
Then the init methods of all of the devices are called.
device apic_cluster 0 on chip cpu/intel/slot_2 device apic 0 on end end endend
So after I fix up this example to match our board where would my board specific code go? Is there still a mainboard.c? I've got things that disable the secondary IDE controller and a few other specials.
Yes, but we try to avoid
Basically the code is inside out from the v1 tree. That makes the code a little harder to follow but a lot easier to reuse.
I am stunned that the ide interface enable/disable thing has not come up, before. That looks something we have just glossed over. To many other glitches I guess.
I am trying to think of a clean way to handle it so the ide enable/disable can be set in the configuration file.
I can see two possible ways and I will list an example of both: Either we add and ide_socket path and only enable IDE controllers who have an attached socket, or we add a chip specific configuration option.
chip southbridge/intel/piix4e device pci 12.0 on end # ISA bridge device pci 12.1 on device ide_socket on end end # IDE controller device pci 12.1 on end # IDE controller device pci 12.2 on end # USB host controller device pci 12.3 on end # Power management registers
register enable_ide_0 = "1" register enable_ide_1 = "0" end
We can still run mainboard specific code in the appropriate init method. Note however that will be the first init method run. In general it is assumed that the order of init methods does not matter, so the just get run in the order the devices were discovered.
Eric
On Mon, 18 Oct 2004, Richard Smith wrote:
I've been reading this new v2 stuff with some interest. I may be able to finde time to move the 440bx stuff over into v2. We've hired a big gun PCI guru to help find our problems that have been keeping me from getting video to work.
excellent!
While he's working on that and I'm playing gopher boy, I may be able to scratch in some v2 conversion work. What v2 boards have a working SPD implementation?
Try the port for the digitallogic adl855pc or whatever it is. modulo Intel's unwillingness to tell us how the chips actually work I think the structure is close to right.
The Arima HDAMA is still the gold standard, but it is really way more complex than a simple 440bx system. That's why I like the digitallogic port better as an example.
ron
Ronald G. Minnich wrote:
Try the port for the digitallogic adl855pc or whatever it is. modulo Intel's unwillingness to tell us how the chips actually work I think the structure is close to right.
The Arima HDAMA is still the gold standard, but it is really way more complex than a simple 440bx system. That's why I like the digitallogic port better as an example.
I've been going over the various ports trying to get a feel for whats needed. What I think I may do is take a stab at creating a generic port. Some fictious motherboard that has the minimum structure necessary as a search and replace starting point. Does that sound useful? If so what should I name it?
On Tue, 19 Oct 2004, Richard Smith wrote:
I've been going over the various ports trying to get a feel for whats needed. What I think I may do is take a stab at creating a generic port. Some fictious motherboard that has the minimum structure necessary as a search and replace starting point. Does that sound useful? If so what should I name it?
I'm not sure it's less work than a full one, although you could set up 'user mode linuxbios' for educational purposes.
ron
Ronald G. Minnich wrote:
replace starting point. Does that sound useful? If so what should I name it?
I'm not sure it's less work than a full one, although you could set up 'user mode linuxbios' for educational purposes.
I'm not doing it because its less work. *grin*
I'm thinking about those who come after me. With the purpose of creating a well documented starting structure at the same time teaching me how v2 goes together.
Then next guy then has a clean starting point and dosen't have to wade through the same stuff.
* Richard Smith rsmith@bitworks.com [041019 18:30]:
I'm not doing it because its less work. *grin*
I'm thinking about those who come after me. With the purpose of creating a well documented starting structure at the same time teaching me how v2 goes together.
Then next guy then has a clean starting point and dosen't have to wade through the same stuff.
Maybe some good documentation about what needs to be done in which order helps better in this case? I started describing the AMD64 work in freebios2/documentation/LinuxBIOS-AMD64.tex, but this is obsolete with the latest config file changes and it could need a lot more contributions, ie generalizing the AMD64isms.
Stefan
* Ronald G. Minnich rminnich@lanl.gov [041019 17:55]:
I've been going over the various ports trying to get a feel for whats needed. What I think I may do is take a stab at creating a generic port. Some fictious motherboard that has the minimum structure necessary as a search and replace starting point. Does that sound useful? If so what should I name it?
I'm not sure it's less work than a full one, although you could set up 'user mode linuxbios' for educational purposes.
Wait!! That is already there... Have a look at the emulation/qemu-i386 motherboard before you start anything new! I did that a while ago, but it could use some work (the PCI resource allocation vanished when I dropped around the time I dropped the normal image to get more space for my payload)
Stefan
On Tue, 19 Oct 2004, Richard Smith wrote:
I've been going over the various ports trying to get a feel for whats needed. What I think I may do is take a stab at creating a generic port. Some fictious motherboard that has the minimum structure necessary as a search and replace starting point. Does that sound useful? If so what should I name it?
it has a name. the name is bochs.
more seriously if we could do it one way and move bochs bios to real hardware, we could go other way and move LB to bochs hardware (which is something like intel 440BX IIRC).
* Adam Sulmicki adam@cfar.umd.edu [041019 19:28]:
it has a name. the name is bochs.
more seriously if we could do it one way and move bochs bios to real hardware, we could go other way and move LB to bochs hardware (which is something like intel 440BX IIRC).
The emulation/qemu-i386 target should work with bochs, if it supports rom images with more than 64k. The reason I called it qemu-i386 is because qemu is a lot faster than bochs, and it supports many CPU architectures, instead of just x86 while emulating a fixed set of PCI hardware. Thus, creating a qemu-ppc or qemu-sparc target for LinuxBIOS would probably not be too much work.
Stefan
YhLu YhLu@tyan.com writes:
There is overlapping between prefmem and mem.
Ok that is really weird.
Do you have a prefmem resource whose limit is below 4G?
A few small glitches don't surprise me as the 64bit support in the resources is new, and I am still refining it. And it should be suboptimal for multiple HT chains. (Because I am artificially limiting them in the PCI_DOMAIN).
However. I don't know of a case that would assign prefmem and mem the same base address.
In src/northbridge/amd/amdk8/northbridge.c:pci_domain_read_resources
You might try setting the limit to 4G - 1 == 0xffffffff
An lspci -vvv of the failing system would be interesting if you have BIOS under which it boots.
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] io <node 0 link 0> PCI: 00:18.0 1b8 <- [0x0000000000 - 0x000fffffff] prefmem <node 0 link 0> PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fe1fffff] mem <node 0 link 0> PCI: 00:18.0 1da <- [0x0000004000 - 0x0000004fff] io <node 0 link 2> PCI: 00:18.0 1aa <- [0x0100800000 - 0x01007fffff] prefmem <node 0 link 2> PCI: 00:18.0 1a2 <- [0x00fe200000 - 0x00fe4fffff] mem <node 0 link 2>
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart> PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart> PCI: 00:19.0 1c8 <- [0x0000005000 - 0x0000005fff] io <node 1 link 0> PCI: 00:19.0 198 <- [0x00f8000000 - 0x01007fffff] prefmem <node 1 link 0> PCI: 00:19.0 190 <- [0x00fe500000 - 0x00fe6fffff] mem <node 1 link 0>
For reference on my HDAMA with a mellanox HCA plugged in I am getting:
PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000002fff] io PCI_DOMAIN: 0000 01 <- [0xfcf0000000 - 0xfcf87fffff] prefmem PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fd3fffff] mem PCI: 00:18.0 1b8 <- [0xfcf0000000 - 0xfcf87fffff] prefmem <node 0 link 0> PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000002fff] io <node 0 link 0> PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fd3fffff] mem <node 0 link 0>
Eric
-
Adam Sulmicki -
ebiederman＠lnxi.com -
Richard Smith -
Ronald G. Minnich -
Stefan Reinauer -
YhLu