OSDev.org

I've pushed it do github, here it is
https://github.com/Bonfra04/BonsOS/blob/master/serial.img

So far I have found two things, which may or may not fix your problem.

1) At line 253 in uhci.c, https://github.com/Bonfra04/BonsOS/blob/master/libk/src/drivers/usb/uchi/uhci.c#L253, you are reading a WORD when the register is a byte.

2) At line 17 in scsi.c, https://github.com/Bonfra04/BonsOS/blob/master/libk/src/drivers/storage/scsi.c#L17, you are setting the command length to 12. However, command 0x25 (Read Capacity) expects the length to be 10. Remove line 75 from scsi_types.h, https://github.com/Bonfra04/BonsOS/blob/master/libk/src/drivers/storage/scsi_types.h#L75, and see what happens.

The physical hardware may not like the incorrect command size and that is why it isn't working. I have added a check to BOCHS to give an error if this happens. (I will push this check with my other USB emulation additions when that time comes).

Ben

I mean yea this is wrong but while scanning through the code this wrong read only appears inside the logs. At line 58 for example (during the setup) the reading is performed correctly.


That is a typical bug that would've take me months to find XD, sadly this happens later than where the code gets stuck in real HW (which is during the assignment of the USB address, even before retrieving the device descriptros)

Anyway I implemented both things and tested the code, seems nothing have changed :(

I am still convinced that it is the reset code. Since you are using the PIT and delays (somewhat much) longer than microseconds (the 8253 having a ~1.2 MHz clock), the delays may not be correct for the UHCI.

I could be completely wrong, and it is something else. However, I personally experienced the same thing you are describing and once I used the reset code I posted earlier, it worked as expected.

The image you sent me shows that you are experimenting with the HPET. Is this true? If so, you can get much more accurate delays with the HPET. You are also reading from the MSR_APICBASE. Does this mean you are experimenting with the APIC?Where you can get a very accurate delay with it as well.

The former timer tells you the frequency, so it is a simple task to get delays with a microsecond (plus) accuracy. The latter, you have to do a little more effort by having to get the CPU's frequency or using a different clock (which may not exist) to calculate the incremental timer.

Anyway, please keep us posted. If I happen to find anything else, I will let you know.
Ben
- https://www.fysnet.net/osdesign_book_series.htm

Luckily, the code I am adding to Bochs found this little error. I am adding a bunch of checks to all four controller types and the devices supported to better help find bugs. The new code should be pushed to the Bochs Github as soon as I thoroughly test it.


Something that I didn't even check before, I don't know why, I just assumed I guess. Your code tries to set the address first thing. My book clearly states that you cannot do this. You must get the first 8 bytes of the Device Descriptor, reset the device, set the address, then get the full Device Descriptor. This is a must. Some devices (more than you think) expect this, even though this is not USB compliant, and the device won't function correctly without it.

1) reset device
2) get the first 8 bytes of the Device Descriptor
3) reset device
4) set address
5) get all 18 bytes of the Device Descriptor
6) now you can do the rest in an order that pertains to the device.

Try that and see what happens. (Sorry I didn't catch this before. I simply assumed you were doing this since you have my book, and that I have always done this sequence, it is just second nature for me now).

Ben

P.S. I have found that it is more that the first request (#2 above) must be less than or equal to the max packet size of the control endpoint rather than 8 bytes, though you don't know the max packet size until after reading in (at least the first 8 bytes of) the device descriptor. So I have found if you just read in only the first 8 bytes, it will work on all devices, no matter the speed of the device. For example, on devices that are full-speed or higher, you can request 64 bytes (instead of 8) and it still works, as long as the max packet size for the Control EP is not less than 64.

So something like this should do it right?


I don't technically need those eight bytes so I'm ignoring them for the moment.
Now it gets stuck inside this request and doesn't reach the second reset.. I've added some more logs, hopes this help.


About the HPET, Yes managed to make this code work but I'm still to implement a proper delay method with this one. I'll try to use this one for delays and update the post as soon as i get some results. I'm using LAPICs timers for the scheduler so maybe I'm going to use the HPET instead. (don't worry the schedule part happens a lot later in the code than where we are working so it doesn't interfere)