OSDev.org

The Place to Start for Operating System Developers
It is currently Sat Mar 25, 2023 9:41 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: USB on real hw
PostPosted: Thu Feb 02, 2023 7:47 am 
Offline
Member
Member
User avatar

Joined: Wed Feb 19, 2020 1:08 pm
Posts: 241
Location: Italy
I've pushed it do github, here it is
https://github.com/Bonfra04/BonsOS/blob/master/serial.img

_________________
Greetings, Bonfra.


Top
 Profile  
 
 Post subject: Re: USB on real hw
PostPosted: Fri Feb 03, 2023 5:43 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 897
Location: USA
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


Top
 Profile  
 
 Post subject: Re: USB on real hw
PostPosted: Sat Feb 04, 2023 1:18 pm 
Offline
Member
Member
User avatar

Joined: Wed Feb 19, 2020 1:08 pm
Posts: 241
Location: Italy
BenLunt wrote:
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.

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.

BenLunt wrote:
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.

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 :(

_________________
Greetings, Bonfra.


Top
 Profile  
 
 Post subject: Re: USB on real hw
PostPosted: Sat Feb 04, 2023 2:50 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 897
Location: USA
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?
Code:
00425899964i[APIC0 ] set timer divide factor to 16
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


Top
 Profile  
 
 Post subject: Re: USB on real hw
PostPosted: Sat Feb 04, 2023 3:01 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 897
Location: USA
Bonfra wrote:
That is a typical bug that would've take me months to find XD...

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.

Bonfra wrote:
...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)

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.


Top
 Profile  
 
 Post subject: Re: USB on real hw
PostPosted: Sun Feb 05, 2023 4:57 am 
Offline
Member
Member
User avatar

Joined: Wed Feb 19, 2020 1:08 pm
Posts: 241
Location: Italy
BenLunt wrote:
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.


So something like this should do it right?
Code:
   for(uint64_t i = 0; i < bus->hci.num_ports; i++)
    {
        if(!bus->hci.driver->reset_port(bus->hci.data, i))
            continue;
        if(bus->hci.driver->port_status(bus->hci.data, i) == USB_PORT_STATUS_NOT_CONNECT)
            continue;

        kernel_trace("Found connected USB device");

        uint8_t eight[8];
        if(usb_get_standard_descriptor(&(usb_device_t){.bus = bus, .addr = 0}, USB_DESCRIPTOR_DEVICE, 0, eight, 8) != USB_TRANSFER_STATUS_OK)
            return;

        kernel_trace("Got first 8 bytes of device descriptor: %x %x %x %x %x %x %x %x", eight[0], eight[1], eight[2], eight[3], eight[4], eight[5], eight[6], eight[7]);

        if(!bus->hci.driver->reset_port(bus->hci.data, i))
            continue;
        if(bus->hci.driver->port_status(bus->hci.data, i) == USB_PORT_STATUS_NOT_CONNECT)
            continue;

        kernel_log("Registering...");

        usb_register_device(bus);
    }


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.
Image

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)

_________________
Greetings, Bonfra.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 6 hours


Who is online

Users browsing this forum: Majestic-12 [Bot] and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group