PCI Scanning (finding mass storage controllers)

[hegde1997]

when i call the following pci_ata_try() it prints that 0 mass sorage controllers detected. what is wrong? pls tell me

Code: Select all

void pci_ata_try()
{
	uint32 bus,dev,func,t=0,tmp=0;
		
	for(bus=0;bus<256;bus++)
	{
		for(dev=0;dev<32;dev++)
		{
			for(func=0;func<8;func++)
			{
				t=pci_configread32(bus,dev,func,8)>>24;
				 if(t==1)
				  tmp++;				
			}
		}
	}
	
	_print_int(tmp); _printf(" Mass Storage Controllers detected ");	
}

Code: Select all

uint32 pci_configread32(uint16 bus, uint16 slot, uint16 func, uint16 offset)
 {
    uint64 address;
    uint64 lbus = (uint64)bus;
    uint64 lslot = (uint64)slot;
    uint64 lfunc = (uint64)func;

    address = (uint64)((1<<31)(lbus << 16) | (lslot << 11) |(lfunc << 8) | (offset & 0xfc) | ((uint32)0x80000000));
    outl(0xCF8,address);
    return inl(0xCFC);
 }

Code: Select all

uint32 inl(uint16 _port)
{
	uint32 result;
	__asm__  ("inl %%dx,%%eax" : "=a" (result) : "d" (_port));
	return result;
	
}

Code: Select all

void outl(uint16 _port, uint32 _data)
{
	 __asm__ ("out %%al, %%dx" : :"a" (_data), "d" (_port));
}

[Brendan]

Hi,

As far as I can tell, it should work (for a limited definition of "work" - e.g. assuming there's no problems caused by not caring if the device actually exists or not, and not caring if the device supports multiple functions or not).

You could try putting " _print_int(t); _printf(" ");" just before the "if(t==1)" so that it shows you all the base class codes it does see. That might give some hint at what is going wrong.


Cheers,

Brendan

[hegde1997]

No luck. i did that but it kept on printing 17 or 0x11 which is Data Acquisition and Signal Processing Controllers
one more thing. after enumeration the function told that it found 10890 devices (by checking device id).
is it abnormal? i think so.

[Brendan]

Hi,

No luck. i did that but it kept on printing 17 or 0x11 which is Data Acquisition and Signal Processing Controllers
one more thing. after enumeration the function told that it found 10890 devices (by checking device id).
is it abnormal? i think so.

That makes me think the problem is in "pci_configread32()". Can you post a disassembly of this function?


Cheers,

Brendan

[uri]

The inline assembly in your outl() function looks wrong:

Code: Select all

void outl(uint16 _port, uint32 _data)
{
	 __asm__ ("out %%al, %%dx" : :"a" (_data), "d" (_port));
}

It should probably be

Code: Select all

	 __asm__ ("outl %%eax, %%dx" : :"a" (_data), "d" (_port));

to match your inl().

[hegde1997]

The inline assembly in your outl() function looks wrong:

Code: Select all

void outl(uint16 _port, uint32 _data)
{
	 __asm__ ("out %%al, %%dx" : :"a" (_data), "d" (_port));
}

It should probably be

Code: Select all

	 __asm__ ("outl %%eax, %%dx" : :"a" (_data), "d" (_port));

to match your inl().

I changed it but not much difference. I think there is something wrong somewhere else.

[bluemoon]

address = (uint64)((1<<31)(lbus << 16) | (lslot << 11) |(lfunc << | (offset & 0xfc) | ((uint32)0x80000000));

This seems weird, is that actual code in your OS?

it found 10890 devices, is it abnormal?

No, usually there is only a few to tens of devices with valid info.

[hegde1997]

Hi,

No luck. i did that but it kept on printing 17 or 0x11 which is Data Acquisition and Signal Processing Controllers
one more thing. after enumeration the function told that it found 10890 devices (by checking device id).
is it abnormal? i think so.

That makes me think the problem is in "pci_configread32()". Can you post a disassembly of this function?


Cheers,

Brendan

public pci_configread32
pci_configread32 proc near

arg_0= dword ptr 8
arg_4= dword ptr 0Ch
arg_8= dword ptr 10h
arg_C= dword ptr 14h

push ebp
mov ebp, esp
sub esp, 8
mov eax, [ebp+arg_0]
shl eax, 10h
mov edx, eax
mov eax, [ebp+arg_4]
shl eax, 0Bh
or edx, eax
mov eax, [ebp+arg_8]
shl eax, 8
or edx, eax
mov eax, [ebp+arg_C]
or eax, edx
or eax, 80000000h
sub esp, 8
push eax
push 0CF8h
call outl
add esp, 10h
sub esp, 0Ch
push 0CFCh
call inl
add esp, 10h
leave
retn
pci_configread32 endp

[Brendan]

Hi,

Doh - I was hoping the "out %%al, %%dx" bug (that I failed to notice) would've fixed it.

That makes me think the problem is in "pci_configread32()". Can you post a disassembly of this function?

Code: Select all

public pci_configread32
pci_configread32 proc near

arg_0= dword ptr  8
arg_4= dword ptr  0Ch
arg_8= dword ptr  10h
arg_C= dword ptr  14h

push    ebp
mov     ebp, esp
sub     esp, 8
mov     eax, [ebp+arg_0]
shl     eax, 10h
mov     edx, eax
mov     eax, [ebp+arg_4]
shl     eax, 0Bh
or      edx, eax
mov     eax, [ebp+arg_8]
shl     eax, 8
or      edx, eax
mov     eax, [ebp+arg_C]
or      eax, edx
or      eax, 80000000h
sub     esp, 8
push    eax
push    0CF8h
call    outl
add     esp, 10h
sub     esp, 0Ch
push    0CFCh
call    inl
add     esp, 10h
leave
retn
pci_configread32 endp

This code looks like it was generated with optimisation disabled; but somehow the "offset & 0x000000FC" part is missing. It is correct though, and the "offset & 0x000000FC" part isn't necessary (as nothing calls this function with strange values for offset).

It should probably be

Code: Select all

	 __asm__ ("outl %%eax, %%dx" : :"a" (_data), "d" (_port));

to match your inl().

I changed it but not much difference. I think there is something wrong somewhere else.

"Not much difference" means that there was some difference.

I think you need to post the current code (as the code you originally posted wasn't your current code at the time, and you've made other changes like checking if the device is valid and fixing "outl" since then); and also post the current results (e.g. how many devices of which classes it detects now).


Cheers,

Brendan

[Combuster]

This code looks like it was generated with optimisation disabled;

The code looks spoofed. The input code shown uses GCC specifics, while the output is some TASM lookalike with the aforementioned compiler errors. Furthermore, the same output contains names for locals yet does not contain offset values, both of which are signature features of a disassembly.

Now I have absolutely no reason left to trust any of the posted code as actual. Congratulations on being a timewaster.