Device Register Access

Hi. I am seriously confused as to how to access a memory address+offset and bit field. My attempt is below:

Code:

---

#define secPerTrk 0x3F //= 63
#define maxHeadNm 0xFE //= 254
#define intATACmd 0x91 //= initialize ata command

//initialize ata
pci_write_config_dword(&pci, ((BAR5+0x90)>>16), secPerTrk);
pci_write_config_dword(&pci, ((BAR5+0x94)>>16), maxHeadNm);
pci_write_config_dword(&pci, ((BAR5+0x94)>>24), intATACmd);

//poll status
pci_read_config_dword(&pci, (BAR5+0x94), &i);

while(!((i >> 24) & 0x80) == 0) //is busy?
{
        delay(10);
        pci_read_config_dword(&pci, ((BAR5+0x94)>>24), &i);
}

//ready
printf(0x0F,3,10,"Device Ready!");

---

I am returning Device Ready, but I just don't believe it is working as I do not trust my shifts. Can someone please take a look at my code and tell me what I am doing wrong?

Thanks

Even without knowing what BAR5 is your shifts still look suspect...

((BAR5+0x90)>>16)

if you are adding 0x90, then shifting right 16 bits, you're going to lose the bottom 16 bits... so having added the 0x90 is kinda inconsequential. Unless you're expecting some fancy carry but I doubt it.

What nonoob said, plus you should be OR'ing these flags, not adding them.

If BAR5 is a memory address and 0x90 and 0x94 are supposed to be offsets, then you would want BAR5[0x90] and BAR5[0x94] -- or if you insist on showing your work *(BAR5+0x90). As it is, you are shifting the pointer 16 or 24 bits, not the contents of the memory.

I was looking 'round the weeb... It's a good idea to get the definition of pci_write_config_dword, and understand the arguments. See some examples. The second parameter is usually some low 0xnn thingy. The shifts are probably meant for the third arguments where there are masks and such.

I tried mapping the address to a pointer but gcc wouldn't allow me to use the bitwise shift operator on the pointer. I tried:

Code:

---

//vars
unsigned char* pBar5;
unsigned int* tfreg0;

//map it
pBar5 = (unsigned char*)mapreg(BAR5&(~0xf), BAR5Sze);

//set it
tfreg0 = (unsigned int*)(pBar5+0x90);

//test it
pci_write_config_dword(&pci, (tfreg0>>24), 0x1234);
pci_read_config_dword(&pci, (tfreg0>>24), &i);

//print it
printf("res: 0x%x",((tfreg0>>24)&0xFF)); //should be 0x1234

---

My mapreg function works as it returns the right address range, but GCC complains about the bitwise shift operator, so I couldn't test that return. I definitely suspect my shifts, any help?

What do you think tfreg0>>24 should mean? If you want to access certain bits of the int that tfreg0 points to, then you need masking, not shifting. If you really only want the top eight bits of this address, then I guess that's what you want.

Edit: I'm deleting this edit because I think I misunderstood your original intent.

(Is this post confusing yet? I should just stop now.)

No, I think you are right, can you show me an example?

I'm still not clear on what you're trying to do, so I'm going to do everything I can think of:
The top eight bits (the slowest-changing) of the address is what you've got, intptr>>24.
The low eight bits (the fastest-changing) of the address is intptr&0xff.
The top eight bits of the memory pointed to, shifted down, would be (*intptr) >> 24.
The eight bits at offset 0x90 from a memory address would be charptr[0x90].

I'm sorry, I'll just show you what I am after:

So its BAR5+0x90 to get to the stuff below:

Quote:

---

Address Offset: 90H
Access Type: Read/Write
Reset Value: 0x0000_0000

Bit [31:00]: IDE0 Task File Data (R/W). This bit field defines the IDE0 Task File Data register. This register
can be accessed as an 8-bit, 16-bit, or 32-bit word, depending upon the PCI bus Byte Enables. The data written
to this register must be zero-aligned. To access 8-bit Task File Data, the PCI bus Byte Enable for byte 0 must
be active. To access 16-bit Task File Data, the Byte Enables for byte 1 and byte 0 must be active. To access
32-bit Task File Data, the Byte Enables for all four bytes must be active.
• Bit [31:24]: IDE0 Task File Starting Sector Number (R/W). This bit field defines the IDE0 Task File Starting
Sector Number register. Access to this bit field is permitted only if the PCI bus Byte Enable for byte 3 is active.
• Bit [23:16]: IDE0 Task File Sector Count (R/W). This bit field defines the IDE0 Task File Sector Count register.
Access to this bit field is permitted only if the PCI bus Byte Enable for byte 2 is active.
• Bit [15:08]: IDE0 Task File Features (W). This write-only bit field defines the IDE0 Task File Features register.
Access to this bit field is permitted only if the PCI bus Byte Enable for byte 1 is active.
• Bit [15:08]: IDE0 Task File Error (R). This read-only bit field defines the IDE0 Task File Error register. Access
to this bit field is permitted only if the PCI bus Byte Enable for byte 1 is active.

---

I need to read and write bit field 23:16. Hope this helps clear it up.

I have failed here -- I can't even find two sources that agree on what data types this pci_whatever_write function takes, let alone what they mean. So unless you pony up that, I can't help you with your arguments.

I can deal with bitwise access, though: if we manage to get an int variable i whose bits are as above, then we can get the bitfield by doing (i&0xff0000)>>16 (the mask to throw away the other bits, and the shift to move it to the least significant spots). If we have such a variable i, and we want to change just those bits, then we would have to do (i&0xff00ffff) + (newval<<16) -- the first bit keeps the stuff around our bitfield, and the other part stuffs the bitfield in the appropriate place.

Sorry man, I wrote that function, here it is:

Code:

---

int pci_read_config_dword (pci_t *pci, unsigned reg,
                unsigned long *val)
{
        outl(PCI_CONFIG_ADDR, 0x80000000L |
                ((unsigned long)pci->bus << 16) |
                ((unsigned)pci->dev << 11) |
                ((unsigned)pci->fn << 8) |
                (reg & ~3));
        *val = inl(PCI_CONFIG_DATA+ 0);
        return 0;
}

---

Do I just:

Code:

---

pci_read_config_dword(&pci,BAR5+0x90,&i);
result=((i&0xFF000000)>>16);

---

And that should read the 23:16 bit field? The entire register is 32 bits.

Then to write to that field:

Code:

---

value=(i&0xFF00FFFFFF) + (0x3F<<16);
pci_write_config_dword(&pci, BAR5+0x90, value);

---

And that should write 0x3F to bit field 23:16? Thanks

So, ok, it looks like the second argument would be 0x90/BAR5+0x90/whatever, and the third argument would be the address of a long, like &i the way you have it. Then to read out the bitfield you can do what I have up above.

sorry, could you please look at my edits above and just check if I understood you correctly? Thanks in advance.

The bitmask should only have four zeroes at the end. You can actually do that in probably less typing and less prone to errors by saying

Code:

---

result = (i>>16) & 0xff;

---

that is, shift first and mask second.
And again, you're off with the other bit mask too -- there are only four F's in the bitfield 0:15, not six.

Not sure what your background is, but if you have never written a device driver before I can tell you from first hand experience that you definitely could. Have you ever written drivers or kernels before? Anyway, thanks a lot for helping me out here. I feel a lot less confused now, so I will go ahead and try this out and post back if I hit a snag. Much appreciated.

At any rate, I am still having issues, perhaps I am still doing it wrong:

Code:

---

#define secPerTrk 0x3F //= 63
#define maxHeadNm 0xFE //= 254
#define intATACmd 0x91 //= initialize ata command

unsigned long val;
unsigned long res;

// read, then write
pci_read_config_dword(&pci,BAR5+0x90,&i);
val=(i&0xFF00FFFF) + (secPerTrk<<16);
pci_write_config_dword(&pci, BAR5+0x90, val);
res=(i>>16) & 0xff;

//print
printf(0x0F,3,10,"res: 0x&#37;x, val: 0x%x", res, val);

---

Output:

Quote:

---

res: 0x0, val: 0x3F0000

---

Shouldn't *res* be the same as *val*, and shouldn't val = 0x003F0000?

The value of res depends on the value of i, which depends on what came in from your read_config. Apparently the original value of your bit_field was 0. (If you had done

Code:

---

res=(val>>16) & 0xff;

---

I would expect res to be the same secPerTrk, i.e., 0x3F.

And val is 0x003F0000. (Leading zeroes don't print unless you do something fancy. Granted you're using an outre version of printf, but %x by default doesn't pad zeroes.)

still having trouble understanding this. I tried mapping the memory to a pointer, but I am sure I am using it wrong as it keeps causing a double-fault:

Code:

---

unsigned char* pBar5;
unsigned int* pTFR0;

pBar5 = (unsigned char*)mapreg(BAR5, BAR5Sze); //map bar5
                                   
pTFR0 = (unsigned int*)(pBar5+0x90); //map offset to pointer

//initialize ata
*pTFR0 = (pTFR0&0xFF00FFFF) + (secPerTrk<<16); //write to memory
pci_read_config_dword(&pci,pBar5[0x90],&i); //read offset to i
res=(i>>16) & 0xff; //shift and mask
printf("res: 0x%x", res);

---

thanks in advance

If you plan to mask off what is pointed to by pTFR0, you would use (*pTFR0&0xFF00FFFF).
Also pBar5[0x90] corresponds to *(pBar5+0x90), in other words the contents of your 0x90, not the pointer itself, which I'm pretty sure you were using before. (In other words: pBar5[0x90] is a character while pBar5+0x90 is a pointer.)

I am not able to test this now, but if I:

Code:

---

unsigned char* pBar5;
unsigned int* pTFR0;

pBar5 = (unsigned char*)mapreg(BAR5, BAR5Sze); //map bar5
                                   
pTFR0 = (unsigned int*)(pBar5+0x90); //map offset to pointer

//initialize ata
*pTFR0 = (*pTFR0&0xFF00FFFF) + (secPerTrk<<16); //write to memory
pci_read_config_dword(&pci,pBar5+0x90,&i); //read offset to i
res=(i>>16) & 0xff; //shift and mask
printf("res: 0x%x", res);

---

that should work and if not then it is a problem with my mapping?

The read_config thing is at least consistent with what you had before that appeared to give you an answer, so that's probably right. And the *pTFR0 is what you wanted.

I tried this:

Code:

---

unsigned char* pBar5;
unsigned int* pTFR0;

// Map the memory
pBar5 = (unsigned char*)mapReg(BAR5, BAR5Sze);
                                                                         
pTFR0 = (unsigned int*)(pBar5+0x90); //map offset to pointer

//initialize ata
*pTFR0 = (*pTFR0&0xFF00FFFF) + (secPerTrk<<16); //write to memory
pci_read_config_dword(&pci,(unsigned)(pBar5+0x90),&i); //read offset to i
res=(i>>16) & 0xff; //shift and mask
printf(0x0f,3,10,"res: 0x&#37;x", res);

---

And it double-faults the CPU. I think what is happening is that I am trying to map an address to a part of memory that I am not allowed to access as it is not apart of my kernels address space. So is there a way to access a memory address without mapping it? If so, how?

to pick back up on our discussion about bitfields, suppose I have this dilema:

I must use outb and inb to read from an IO address at 0x9804, this address contains four 8bit registers totaling 32bits wide. How would I access bitfield 23:16 for both read and write; knowing I can only read and write 8 bits at a time?

That depends on the specifics of how you can read and write 8 bits at a time.
Is your IO address byte-based? If so, then with your address at 0x9804 the bitfield you want is 0x9805, and we're done. However, if you can only access aligned addresses, then you'll have to think. OTOH, if you can only read and write 8 bits at a time, I would be somewhat surprised to be restricted to an alignment.

So the question is: can you read/write to address 0x9805?

oh, your right, I am sure it must be aligned by doing ~3, just as I was doing with the pci config registers. I'll try though, brb.

EDIT:

I tried it and it returned the right value, but how would I align as I think I must.

Well, but wait. 0x9805 & ~3 is 0x9804. Can you do inb (or whatever your "read eight bits at a time" function is) on address 0x9805 (no ~3 stuff), or does it have to be aligned to a 32-bit boundary (which is what the ~3 is doing for you)?

I think it must be aligned to a 32 bit boundary because each new base address starts with 0x00 as an offset and this one has two 32 bit boundaries one at offset 0x00 and the other at 0x04, then like I said the next base address starts with an offset of 0x00. I could show you the data sheet if you want.

There are a total of 6 base addresses 5 of which are I/O addresses. The address I am after is the first base address (I/O) and it starts at 9800 with two offsets (0x00 and 0x04) each containing 32 bits, then the next base address (I/O) starts at 9C00 with one offset (0x00) containing 32 bits.

EDIT: found out they are standard byte-aligned.

By "returned the right value", you mean you have a BYTE with the correct eight bits in it? If so, then that part's done. Or do you have an int, with the proper bits in 23..16? And then outb is probably the same way.

As I said, if you can access just the eight bits at address 0x9805, then do so. Somewhere on your data sheet it should say whether those base addresses are the only places you can start or if you can get single bytes (or maybe the function that you're using has documentation). I don't know enough about PCI to be able to tell you. If you must start at 0x9804, then you'll need to read eight bits, throw them away, and then read the next eight bits.

Edit: If they are byte-aligned, then address 0x9805 should be a perfectly cromulent address to read from/write to.

here is the data sheet: http://gkernel.sourceforge.net/specs...095-B2.pdf.bz2

here is what I tried that returned what was written:

Code:

---

//let base = 9800
unsigned char i;
outb(base+0x05, 0x3F);
i=inb(base+0x05);

---

return: 0x3F

my inb and outb are just inline asm to work with asm instructions inb and outb as normal. If I am to start at 9804 and throw away bytes how would I do that, in a loop counting down from 8? /me confused

It looks like you maybe don't need to, if this is working. (But I was envisioning reading in two bytes and only keeping the low one, or something similar; surely there's an index register that you would increment if you needed to read two consecutive bytes with inb, or has MMIX messed with my head way too much?)

EDIT: I take back what I thought. I agree with you. I think that if I access it the way you suggested that would be right. Because I looked at device manager and saw the IO range for the bar I am r/w from is 9800 - 9807, so 4 bits * 8 = 32 bits. So if this is true then to r/w from bits 23:16 I should write to 9806 first four bits and 9805 last four bits to r/w bits 23:16? So I would just do:

outb(0x9800+0x05, 0x3f&0xff); //write last four bits
outb(0x9800+0x06,0x3f>>4); //write top 4 bits

and it would be the relative same for inb:

i=inb(0x9800+0x05); //write last four bits
j=inb(0x9800+0x06); //write top 4 bits
printf("9805: 0x&#37;x", i&0xff); //read last four bits
printf("9806: 0x%x",j>>4); //read top four bits

something like that?

Erm. Usually each address has eight bits in it, not four? That is, addresses go by bytes, not nybbles. So 0x9805 would have eight bits in it, and those eight bits would be 23..16 of the whole 32-bit thing.

(Remember, you said 9800 to 9804 was 32 bits; 32 divided by 4 is 8.)

How would those addresses work out then, would it work like so:

9800+0x00 to 9800+0x03

9800 - 31:24
9801 - 23:16
9802 - 15:8
9803 - 7:0

9800+0x04 to 9800+0x07

9804 - 31:24
9805 - 23:16
9806 - 15:8
9807 - 7:0

thanks

Right. (There's nothing special about PCI here, except the numbers being really low -- the same thing would be true about 32-bit integers on the stack:

Code:

---

int main(void) {
    int foo = 0x64656d6f;
    char *bar = &foo;
    for (int i = 0; i < 4; i++) {
        printf("Address &#37;p is %x: %c\n", bar+i, bar[i], bar[i]);
    }
    return 0;
}

---

generally speaking, each address represents a byte.)

to pick up on our discussion about bit placement and ports. I have learned that in the x86 machine the smallest bits associate with the smallest ports, so what we have is actually the opposite of what we should have, so:

9800 = 7:0
9801 = 15:8

etc...