OSDev.org

Hi. I have been working on a EHCI driver for some time now. I can't seem to get past setting the configure flag. When i set it, my pc resets. I already have ISR's for the standard errors and also a working PIT ISR, but i don't get any interrupt, the PC just resets. I have tried swapping the order of what i am doing but i still get this issue. Sometimes the PC does not reset but its almost like something overwrites memory, I am using the 0xB8000 video memory to print debug info, and i can see that info is being overwritten. This is the order i am doing everything in:

1: Claim Ownership of the Controller in the USBLEGSUP register.

2:Set the PCI Command word to 0x6 for bus mastering and MMIO.

3:Check if the HC is running, if it is switch it off.

4:Clear status register by writing 0x3F.

5:disable interrupts in the INTR register.

6: check if the DSSegment is 0, because i am writing for 32bit so it fails if it is not.

7:Reset HC and Check if the values are as expected.

8:Set Interrupt line in the PCI Config space.

9: Set interrupt threshold in USBCMD.

10:Set the INTR reg to 0x7.

11:Set Frameindex to 0.

12: Create FrameList and Async control structures.

13: Set AsyncList Addr and the PeriodicList Base.

14: Fill periodic list with relevant pointers to QH's and then disable it all by setting T bits, since i am trying to just get it run first.

15: Make sure both Schedules are off and then again clear status reg.

16: Start the controller and then try to set configure flag.

I Thought that maby because my Frame Pointer and Async Pointer were pointing in cachable memory that, it was the issue but i looked into MTRR's and disabled it in MSR 0x2FF by writing 0, since when its disabled apparently everything is uncachable. But that made no difference. I also Tried relocating the Controller by changing the BAR, but that made things worse haha. I am not sure what i have missed, started looking into PCI capabilities but could not find anything that might be related.

Z3NT0N wrote:1: Claim Ownership of the Controller in the USBLEGSUP register.

Do you claim ownership of all USB controllers at the same time? That's how Windows does it, and firmware tends to get upset if you don't do things the way Windows does them.

Z3NT0N wrote:6: check if the DSSegment is 0, because i am writing for 32bit so it fails if it is not.

A 32-bit OS can still access all memory using PAE. (But it doesn't make sense for this register to ever be non-zero.)

Z3NT0N wrote:I Thought that maby because my Frame Pointer and Async Pointer were pointing in cachable memory that, it was the issue but i looked into MTRR's and disabled it in MSR 0x2FF by writing 0, since when its disabled apparently everything is uncachable. But that made no difference.

PCI devices participate in the x86 cache coherency protocol, so you should never disable caching on ordinary RAM.

Z3NT0N wrote:I am not sure what i have missed,

Since you described memory corruption, maybe you have a bad address somewhere - either virtual when it should be physical, or just not in the right place.

Octocontrabass wrote: Do you claim ownership of all USB controllers at the same time? That's how Windows does it, and firmware tends to get upset if you don't do things the way Windows does them.

I have implemented this now, but seems to have made no difference.

I tried another test, where i print some info to see after i set the run bit and then sleeps for 5 seconds. Then i set configure flag and immediately print that i have set it and then its supposed to sleep 5 secs, but instead just for an instant shows the info that i printed after configure flag and then pc resets. So it "sleeps" just fine before i set Configure flag but then after it crashes.

Here's a small snippet of the code: The code works on Qemu, there is no crash. But my hardware is not so happy.

Octocontrabass wrote:Since you described memory corruption, maybe you have a bad address somewhere - either virtual when it should be physical, or just not in the right place.

I am not using paging yet, plan to keep paging out.

please use code tags

I have added them to your post this time, but in the future, remember to use code tags, as it makes code much easier to read

Z3NT0N wrote:

Code: Select all

mov bl,byte [ecx]
and ebx,0x000000FF

Do you get the same value if you perform a dword read instead of a byte read? I'm not so familiar with USB, but I know there's a lot of picky hardware out there, and I know Linux uses only dword reads.

Octocontrabass wrote:

Z3NT0N wrote:

Code: Select all

mov bl,byte [ecx]
and ebx,0x000000FF

Do you get the same value if you perform a dword read instead of a byte read? I'm not so familiar with USB, but I know there's a lot of picky hardware out there, and I know Linux uses only dword reads.

Octocontrabass makes a good point.

https://www.fysnet.net/blog/2021/10/

Though the blog post emphasizes the xHCI, this behavior on the EHCI could be found with real hardware as well.

Also, (for those using compilers instead of assembly) watch for optimizations, as noted in the blog post above.

Ben
- https://www.fysnet.net/the_universal_serial_bus.htm

I believe i found the problem. It was not an issue with the way i was working with the controller but instead my ISR. In my isr i was sending the EOI to the master PIC before the slave . I was also doing some stuff before IRET after EOI so that may have also contributed to the issue as well. I made sure that the EOI's were done last and in the right order, now i get port change interrupts and have been able to reset ports. I still have some more things that may be a problem but i don't think its related to this topic. Thanks for the help everyone. Oh yeah i also corrected the byte access in this function:
To:
I found no other byte reads or writes in the code.