OK, that post finally got through.

Please look at the attached sloginfo dump.  I highlighted where things are "interesting".  Set your Word or Wordpad to 
landscape and A3 paper so you can see the long lines.  Also turn on display of line numbers.

PCI finds Bus0 and reserves 0x80000000 to 0xffe00000 at line 5.

Pci goes out and finds the 82547 on Bus0/Bus1 and discovers it needs 0x24000 bytes.  Then it finds the 4 units of the 
82580 on Bus0/Bus2.  It adds up all the needed memory and discovers it needs 5 MB of total memory for ethernet 
controllers.  it reserves the memory from 0xff900000 to 0xffe00000 at line 268 for Bus0/Bus1 and Bus0/Bus2.

At line 316 devb-mmcsd starts.  libcam.so gets its 0x100 bytes from the ethernet section starting at 0xffdfff00 rather 
than somewhere that is correct.  Then cam-disk.so gets its 0x400 bytes starting at 0xffdff800 rahter than where it 
should.

So why does the memory manager grab memory from the ethernet area when it is specifically reserved for Bus0/Bus1 and 
Bus0/Bus2?

I¹ll take a look at this as soon as I get a chance.

Hugh.



On 2014/4/23, 4:26 PM, "Ray Mack" <community-noreply@qnx.com> wrote:

>OK, that post finally got through.
>
>Please look at the attached sloginfo dump.  I highlighted where things
>are "interesting".  Set your Word or Wordpad to landscape and A3 paper so
>you can see the long lines.  Also turn on display of line numbers.
>
>PCI finds Bus0 and reserves 0x80000000 to 0xffe00000 at line 5.
>
>Pci goes out and finds the 82547 on Bus0/Bus1 and discovers it needs
>0x24000 bytes.  Then it finds the 4 units of the 82580 on Bus0/Bus2.  It
>adds up all the needed memory and discovers it needs 5 MB of total memory
>for ethernet controllers.  it reserves the memory from 0xff900000 to
>0xffe00000 at line 268 for Bus0/Bus1 and Bus0/Bus2.
>
>At line 316 devb-mmcsd starts.  libcam.so gets its 0x100 bytes from the
>ethernet section starting at 0xffdfff00 rather than somewhere that is
>correct.  Then cam-disk.so gets its 0x400 bytes starting at 0xffdff800
>rahter than where it should.
>
>So why does the memory manager grab memory from the ethernet area when it
>is specifically reserved for Bus0/Bus1 and Bus0/Bus2?
>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post110010
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com

Please try the attached pci-bios-v2 and let me know if it solves your
problem.

Thanks, Hugh.



On 2014/4/23, 4:26 PM, "Ray Mack" <community-noreply@qnx.com> wrote:

>OK, that post finally got through.
>
>Please look at the attached sloginfo dump.  I highlighted where things
>are "interesting".  Set your Word or Wordpad to landscape and A3 paper so
>you can see the long lines.  Also turn on display of line numbers.
>
>PCI finds Bus0 and reserves 0x80000000 to 0xffe00000 at line 5.
>
>Pci goes out and finds the 82547 on Bus0/Bus1 and discovers it needs
>0x24000 bytes.  Then it finds the 4 units of the 82580 on Bus0/Bus2.  It
>adds up all the needed memory and discovers it needs 5 MB of total memory
>for ethernet controllers.  it reserves the memory from 0xff900000 to
>0xffe00000 at line 268 for Bus0/Bus1 and Bus0/Bus2.
>
>At line 316 devb-mmcsd starts.  libcam.so gets its 0x100 bytes from the
>ethernet section starting at 0xffdfff00 rather than somewhere that is
>correct.  Then cam-disk.so gets its 0x400 bytes starting at 0xffdff800
>rahter than where it should.
>
>So why does the memory manager grab memory from the ethernet area when it
>is specifically reserved for Bus0/Bus1 and Bus0/Bus2?
>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post110010
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com

Hugh:

I suspect I will not be successful with this file.  You may recall that we are using the fastboot method, so we do not 
have an actual BIOS installed.

I will try it and get a response back.

Ray

I get the same "No BIOS present ...." error that I got before.

What was changed in this file? Are there changes I can make to server.c in the pci-adi directorythat should resolve the 
issue?

In the pci_alloc_resource function in the server.c code, there is a line
commented out (rreq.flags |= RSRCDBMGR_FLAG_RANGE). Un-comment this line
and comment out the previous line.



On 2014/4/28, 6:18 PM, "Ray Mack" <community-noreply@qnx.com> wrote:

>I get the same "No BIOS present ...." error that I got before.
>
>What was changed in this file? Are there changes I can make to server.c
>in the pci-adi directorythat should resolve the issue?
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post110075
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com

Hugh:

That was the magic to solve that issue.  Many thanks!!!!!!!

It is now doing the memory allocation on other strange boundaries and still failing on the last ethernet port.  It has 
something to do with the rreq structure that gets filled in.  The first port get 0xff900000 0xff923ffff. the next 3 get 
memory from 0xffa00000 up to 0xffcfffff.  Somehow the top of the memory pool gets changed from 0xffdfffff to 0xffcfffff.
  I'll do some more troubleshooting.  I hope I can figure it out on my own.

Ray

I think we are really really close on nailing this issue.  I have been reverse engineering as much of the PCI server as 
I can. 

The problem appears to be in the PCI DLL at this point and appears to be an issue with PCI devices that have multiple 
units.  

The problem has its source at these lines in pci_alloc_resource:
				if (BaseReg->Flags & PCI_MEM_PREFETCH) {
					(*pci_drivers->entry->map_addr) (ll_handle, busmap->prefetch_mem_start, &rreq.start, PCI_MEM_SPACE | 
PCI_MAP_ADDR_CPU);
					(*pci_drivers->entry->map_addr) (ll_handle, busmap->prefetch_mem_end, &rreq.end, PCI_MEM_SPACE | PCI_MAP_ADDR_CPU);

					}
				else {
					(*pci_drivers->entry->map_addr) (ll_handle, busmap->mem_start, &rreq.start, PCI_MEM_SPACE | PCI_MAP_ADDR_CPU);
					(*pci_drivers->entry->map_addr) (ll_handle, busmap->mem_end, &rreq.end, PCI_MEM_SPACE | PCI_MAP_ADDR_CPU);
               printf("pci_alloc_resource: PCI memory driver start: %llx  end: %llx\n", rreq.start, rreq.end);
					}
The rreq.end value is off by 1 MB.  Here is the console output from my printf:
PCI_attach_device vendor 0x8086 - device 0x150e


PCI_attach_device device Bus mem start 0 device Bus mem end 0

pci_alloc_resource Base register: 8047a20 alignment: 80000 bus: 2
Base Reg length: 84000  flags: 0
pci_alloc_resource: PCI memory driver start: ff200000  end: ff4fffff
pci_alloc_resource: PCI memory driver start: ff200000  end: ff4fffff
Memory Request Start 0xff200000 - End 0xff4fffff - Size = 0x84000 - Name pcimemory/Bus0/Bus2
rsrcdbmgr_attach result: 0  EOK: 0
pci_alloc_resource Address = 0xff200000 - End 0xff283fff
pci_alloc_resource New BaseReg Address ff200000


PCI_attach_device complete

You can see that the DLL has given me only 3 MB rather than the full 4 MB required.

I am not sure how to proceed because I do not have code for the PCI DLL or the DLL map_addr() function.
______________________________________________

Also, I think there might be an issue with the line where the BaseReg -> Address is updated at the end of 
pci_alloc_resource:

	if (verbose > 2)
		pci_slogf (_SLOGC_PCI, _SLOG_INFO, "Address = 0x%llx - End 0x%llx", rreq.start, rreq.end);
   printf("pci_alloc_resource Address = 0x%llx - End 0x%llx\n", rreq.start, rreq.end);
	BaseReg->Address |= rreq.start;		//Or address with flags
   printf("pci_alloc_resource New BaseReg Address %x\n\n", BaseReg->Address);
	return (PCI_SUCCESS);

As you can see, the comment does not match up with what is actually happening.  It appears that this needs to act 
differently if we are allocating bottom up vs. top down.  My guess is that this value is supposed to be at the end of 
what we are allocating.  The line is correct as-is for top down because the lowest address is at the edge of the pool.  
For bottom up it appears the line should say BaseReg->Address |= (rreq.end + 1); but I could be wrong on what is 
intended.

The DLL code is in bios-v2.c and is statically linked with server.c. At
the top of the file you will see a list of entry points.




On 2014/4/30, 5:40 PM, "Ray Mack" <community-noreply@qnx.com> wrote:

>I think we are really really close on nailing this issue.  I have been
>reverse engineering as much of the PCI server as I can.
>
>The problem appears to be in the PCI DLL at this point and appears to be
>an issue with PCI devices that have multiple units.
>
>The problem has its source at these lines in pci_alloc_resource:
>				if (BaseReg->Flags & PCI_MEM_PREFETCH) {
>					(*pci_drivers->entry->map_addr) (ll_handle,
>busmap->prefetch_mem_start, &rreq.start, PCI_MEM_SPACE |
>PCI_MAP_ADDR_CPU);
>					(*pci_drivers->entry->map_addr) (ll_handle,
>busmap->prefetch_mem_end, &rreq.end, PCI_MEM_SPACE | PCI_MAP_ADDR_CPU);
>					}
>				else {
>					(*pci_drivers->entry->map_addr) (ll_handle, busmap->mem_start,
>&rreq.start, PCI_MEM_SPACE | PCI_MAP_ADDR_CPU);
>					(*pci_drivers->entry->map_addr) (ll_handle, busmap->mem_end,
>&rreq.end, PCI_MEM_SPACE | PCI_MAP_ADDR_CPU);
>               printf("pci_alloc_resource: PCI memory driver start: %llx
>end: %llx\n", rreq.start, rreq.end);
>					}
>The rreq.end value is off by 1 MB.  Here is the console output from my
>printf:
>PCI_attach_device vendor 0x8086 - device 0x150e
>
>
>PCI_attach_device device Bus mem start 0 device Bus mem end 0
>
>pci_alloc_resource Base register: 8047a20 alignment: 80000 bus: 2
>Base Reg length: 84000  flags: 0
>pci_alloc_resource: PCI memory driver start: ff200000  end: ff4fffff
>pci_alloc_resource: PCI memory driver start: ff200000  end: ff4fffff
>Memory Request Start 0xff200000 - End 0xff4fffff - Size = 0x84000 - Name
>pcimemory/Bus0/Bus2
>rsrcdbmgr_attach result: 0  EOK: 0
>pci_alloc_resource Address = 0xff200000 - End 0xff283fff
>pci_alloc_resource New BaseReg Address ff200000
>
>
>PCI_attach_device complete
>
>You can see that the DLL has given me only 3 MB rather than the full 4 MB
>required.
>
>I am not sure how to proceed because I do not have code for the PCI DLL
>or the DLL map_addr() function.
>______________________________________________
>
>Also, I think there might be an issue with the line where the BaseReg ->
>Address is updated at the end of pci_alloc_resource:
>
>	if (verbose > 2)
>		pci_slogf (_SLOGC_PCI, _SLOG_INFO, "Address = 0x%llx - End 0x%llx",
>rreq.start, rreq.end);
>   printf("pci_alloc_resource Address = 0x%llx - End 0x%llx\n",
>rreq.start, rreq.end);
>	BaseReg->Address |= rreq.start;		//Or address with flags
>   printf("pci_alloc_resource New BaseReg Address %x\n\n",
>BaseReg->Address);
>	return (PCI_SUCCESS);
>
>As you can see, the comment does not match up with what is actually
>happening.  It appears that this needs to act differently if we are
>allocating bottom up vs. top down.  My guess is that this value is
>supposed to be at the end of what we are allocating.  The line is correct
>as-is for top down because the lowest address is at the edge of the pool.
> For bottom up it appears the line should say BaseReg->Address |=
>(rreq.end + 1); but I could be wrong on what is intended.
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post110104
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com

Awesome!!!! Just knowing where to look is 90% of the task.

Thank you so much.

I have finally gotten the PCI/E1000 combination to work.  The problem is that the scan_windows() function fills in the 
bus map database with just the amount of memory needed to handle an ethernet NIC. The later addup_resources() call when 
you actually attach the ethernet controller to the PCI bus forces the allocations on 1MB boundaries.  The code is very 
upfront about requiring the 1MB calculations.  The solution is for the scan_windows() function to force all size 
calculations to round up to the nearest 1MB.

Portion of code from server.c below:

			if (verbose)
				pci_slogf (_SLOGC_PCI, _SLOG_INFO, "MEM 0x%llx 0x%llx %s", PCI_MEM_ADDR (addr64), size, addr64 & 0x08 ? "pref" : "")
;
			BaseReg->Address = device_enabled ? addr64 : (addr64 &= 0x0f);
			if (! device_enabled) {
				PCI_write_config32 (bus, devfn, Offset, 1, (char *)&addr64);
				if (reg_64) {
					addr64 >>= 32;
					PCI_write_config32 (bus, devfn, Offset + 4, 1, (char *)&addr64);
					}
				}
			else {
				uint64_t Address;

				(*pci_drivers->entry->map_addr) (ll_handle, addr64, &Address, (uint32_t) BaseReg->Flags | PCI_MAP_ADDR_CPU);
                original_size = size;
                if ((size % 0x100000) > 0)
                {
                  size += 0x100000;
                  size &= 0xfff00000;
                }
				if (alloc_resource (PCI_MEM_ADDR (Address), (uint32_t) size, RSRCDBMGR_PCI_MEMORY, bus,
					(BaseReg->Flags & PCI_MEM_PREFETCH) ? 1 : 0)) {
					pci_slogf (_SLOGC_PCI, _SLOG_ERROR, "%s: Alloc failed 0x%llx - Size 0x%llx",
						__FUNCTION__, Address, size);
//					BaseReg->Address = 0;
//					BaseReg->Flags &= ~PCI_DEVICE_ENABLED;
//					dword = 0;
//					PCI_write_config32 (bus, devfn, Offset, 1, (char *)&dword);
					}
//				else {
					BaseReg->Address = Address;
					BaseReg->Flags |= PCI_DEVICE_ENABLED;
					}
				}
			}