Needed: Assistance With USB

[xSMD]

My code has been minimal and experimental, thus far. I mean, once I figure out what I am doing wrong... Then I will begin to work on a larger, actual implementation of it.

Due to its ever-changing nature, my code is kind of a mess. Kind of awkward at times, I guess. The only copy has been that which I have written to my floppy's boot sector.

Here is the most recent version of it. To keep it small, I hard-coded all register values (after first confirming them). Below, all such values have been replaced with question marks. At least, I attempted to replace all of them...

To aid in reading it, I have translated it into assembly. It is still probably not the easiest thing to read, but maybe you guys can find any problems in/with it.

Code: Select all

FA ... CLI
31 C0 ... XOR AX, AX
8E D8 ... MOV DS, AX
66 B8 04 ?? ?? 80 ... MOV EAX, 80????04 (bits 23:8 are bus, device, and function)
BA F8 0C ... MOV DX, 0CF8
66 EF ... OUT DX, EAX
BA FC 0C ... MOV DX, 0CFC
66 B8 05 00 00 00 ... MOV EAX, 00000005
66 EF ... OUT DX, EAX
B9 00 10 ... MOV CX, 1000
- start of loop-
66 BB 00 80 00 00 ... MOV EBX, 00008000 (the base of my frame list)
66 67 C7 03 00 7D 00 00 ... MOV [EBX], 00007D00 (location of TD)
81 C3 04 ... ADD BX, 04
E2 F3 ... LOOP "start of loop"
BA ?? ?? ... MOV DX, ???? (legacy support register, base + C0)
B8 40 8F ... MOV AX, 8F40
EF ... OUT DX, AX
FB ... STI
66 B9 08 00 00 00 ... MOV ECX, 00000008
- waiting loop one -
F4 ... HLT
E2 FD ... LOOP "waiting loop one"
FA ... CLI
BA ?? ?? ... MOV DX, ???? (command register, base)
B8 02 00 ... MOV AX, 0002
EF ... OUT DX, AX
FB ... STI
66 B9 08 00 00 00 ... MOV ECX, 00000008
- waiting loop two -
F4 ... HLT
E2 FD ... LOOP "waiting loop two"
FA ... CLI
BA ?? ?? ... MOV DX, ???? (frame list base address register, base + 8)
66 B8 00 80 00 00 ... MOV EAX, 00008000
66 EF ... OUT DX, EAX
BA ?? ?? ... MOV DX, ???? (frame number register, base + 6)
B8 00 00 ... MOV AX, 0000
EF ... OUT DX, AX
FB ... STI
66 B9 08 00 00 00 ... MOV EAX, 00000008
- waiting loop three -
F4 ... HLT
E2 FD ... LOOP "waiting loop three"
FA ... CLI
BA ?? ?? ... MOV DX, ???? (status and control register, base + 10)
B8 00 02 ... MOV AX, 0200
EF ... OUT DX, AX
BA ?? ?? ... MOV DX, ???? (port 2 status and control register, base + 12)
B8 00 02 ... MOV AX, 0200
EF ... OUT DX, AX
FB ... STI
66 B9 08 00 00 00 ... MOV ECX, 00000008
- waiting loop four -
F4 ... HLT
E2 FD ... LOOP "waiting loop four"
FA ... CLI
BA ?? ?? ... MOV DX, ???? (port 1 status and control register, base + 10)
B8 00 00 ... MOV AX, 0000
EF ... OUT DX, AX
BA ?? ?? ... MOV DX, ???? (port 2 status and control register, base + 12)
B8 00 00 ... MOV AX, 0000
EF ... OUT DX, AX
FB ... STI
66 B9 08 00 00 00 ... MOV ECX, 00000008
- waiting loop five -
F4 ... HLT
E2 FD ... LOOP "waiting loop five"
FA ... CLI
BA ?? ?? ... MOV DX, ???? (port 2 status and control register, base + 12)
B8 4E 00 ... MOV AX, 004E
EF ... OUT DX, AX
FB ... STI
66 B9 08 00 00 00 ... MOV ECX, 00000008
- waiting loop six -
F4 ... HLT
E2 FD ... LOOP "waiting loop six"
FA ... CLI
BA ?? ?? ... MOV DX, ???? (interrupt enable register, base + 4)
B0 00 00 ... MOV AX, 0000
EF ... OUT DX, AX
FB ... STI
66 B9 08 00 00 00 ... MOV ECX, 00000008
- waiting loop seven -
F4 ... HLT
E2 FD ... LOOP "waiting loop seven"
FA ... CLI
BA ?? ?? ... MOV DX, ???? (command register, base)
B8 01 00 ... MOV AX, 0001
EF ... OUT DX, AX
FB ... STI
66 B9 08 00 00 00 ... MOV ECX, 00000008
- waiting loop eight -
F4 ... HLT
E2 FD ... LOOP "waiting loop eight"
FA ... CLI
E4 61 ... IN AL, 61
0C 03 ... OR AL, 03
E6 61 ... OUT 61, AL
- status loop -
B4 0A ... MOV AH, 0A
A0 06 7D ... MOV AL, [7D06]
BB 07 00 ... MOV BX, 0007
B9 01 00 ... MOV CX, 0001
CD 10 ... INT 10
EB F1 ... LOOP "status loop"

01 00 00 00 00 00 80 00 2D 00 E0 00 20 7D 00 00 = TD (located at byte 100)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 01 00 05 00 = SET_ADDRESS request

55 AA ... boot signature

I am currently looking back over that tatOS source code to see if I can find any differences that might be causing whatever the problem is.

As you can see, my timing mechanism is very crude right now. Though, please note that this computer causes way more than one interrupt per second (hence why I loop eight times for each halt loop). The entire code takes no more than maybe two to three seconds to complete.

I have tried it with different lengths of timing loops. From no timing loops to ridiculously long ones, the end result is the same. So, I do not think that my timing is the problem. Unless the timing of everything needs to be unbelievably precise, that is.

[neato]

Are you actually receiving the Interrupt, you never turn on IOC, so I don't know how else you triggered one. Not sure why you need to loop for 8 times the IOC bit gets set on the last TD and fire only once after it has completed, unless there is an error. I myself have not gotten the controller to set the IOC bit, and I have not actually gotten the device to respond, that was my over eagerness to solve this issue, so I am still getting no where too. So, my same questions on page 1 still stand.

[Dex]

Also are you using paging ?.

[eddyb]

Also are you using paging ?.

This could be a trouble maker.
Is very important that the address you set for buffers in any kind of device is a physical address. UHCI doesn't know about your paging, neither any other device.
I had a big /facepalm when I discovered i was using a virtual address in my rtl8139 driver .

[neato]

I am using paging, so I went ahead and re-wrote my kmalloc to map some pages and allocate them, then on the way out I save the PDE, and from that I get the physical address and I save that, I save it's size, and I save the virtual address which also is the return. Unfortunately, its late and I can't test it until tomorrow. I hope this works, thanks for the info.

[neato]

Hi, I haven't really had to do this before and was wondering if I got it right. Here is what I have, does this look right for a phy addr considering the following info:

CR3: 0xA4E000
Virtual= 0xA4B000
Physical = 0x4E000

I don't know if you can tell from that information or not. If I have it right, then you should be able to. Thanks

[neato]

I'm sorry to hijack a thread, but this question goes with my last question above and I didn't want to make a new thread specifically for this question. I know I am probably going to get 40 lashes for it too, but it will be worth the info... hopefully.

All right. Let's say that my kmalloc goes through the necessary steps to request a chunk of memory, the return is its virtual address, and while that is happening, I manage to also save the physical address, which should be mapped to the virtual address. Now memory stuff has been my weakest point since I started developing and this may sound really dumb to a lot of you, but how can I know if I have the actual physical address? Can I write to the virtual address and then read the physical address to see if what I wrote at the virtual address is being pointed to by the physical address or vice-versa? I must be able to, because how will I receive data back from the USB device if it only excepts physical addresses? I tried to test my addresses in the way I described above, but I was just getting back 0xFFFFFFFF from the physical address in both instances. I could of course read and write to the virtual address. Please, some kind spirit set me straight. Thanks in advance.

[Selenic]

Let's say that my kmalloc goes through the necessary steps to request a chunk of memory, the return is its virtual address, and while that is happening, I manage to also save the physical address, which should be mapped to the virtual address.

Why not just do the 'standard' trick of mapping the PDE (or PML4 in long mode) as its own top entry? Then virtual-to-physical translation can simply look through your page table in the same way the processor itself does.

[neato]

Selenic, good man. I finally got it working. I did exactly what you said and it worked just as I was suspecting it should. Thanks a lot man.