AMD Geode nano-size motherboard sometimes hangs at usb_uhci: no devices found

[scottmc]

I've got a nano-size AMD Geode LX800 CPU motherboard and have had it sometimes boot all the way into Haiku and other times it hangs on the 4th icon and serial debug shows it at usb_uchi: no devices found. Pressing any key on the keyboard when it is hung and the numlock LED will flash on/off once per key. Attaching serial debug and a listdev output from one of the successful boots.

[scottmc]

Serial Debug output from the AMD Geode nano motherboard

[mmlr]

Well except if when booting through there is a UHCI controller found this is entirely possible. It might be an OHCI controller for which the driver is currently not in the image or it might in fact be an EHCI only controller that has a hub/transaction translator built in. From what I see in the (distorted?) serial log it does not really indicate a problem with USB. It's probably rather what would come after the initialization of the USB stack that makes problems. To verify that you could "#define TRACE_USB" in "src/add-ons/kernel/bus_managers/usb/usb_p.h" which will then dump a load of information so we can see if it fully initializes the USB stack or if it hangs somewhere in there.

[scottmc]

42 device Serial bus controller (USB Controller, OHCI) [c|3|10] 43 vendor 1022: Advanced Micro Devices [AMD] 44 device 2094: CS5536 [Geode companion] OHC 45 46 device Serial bus controller (USB Controller, EHCI) [c|3|20] 47 vendor 1022: Advanced Micro Devices [AMD] 48 device 2095: CS5536 [Geode companion] EHC

The full listdev is shown on #2062 Looks like it's using OHCI / EHCI. I have also noticed that sometimes when I boot up that the USB mouse doesn't respond. Unplugging it and plugging it back in doesn't help on this board. I'll put in the #define TRACE_USB and try it again later today or tomorrow, and report the results back.

[scottmc]

Stall at USB with TRACE_USB defined

[scottmc]

This board boots most of the time now, but if booted without a USB mouse plugged in with ignore one once it is attached

[scottmc]

Ok, rebuilt with TRACE_USB defined. New serial debug attached. One with it stalling at USB at the 4th icon, and the second with it booting up ok, but then ignoring a USB mouse that was plugged in after a successful boot up. Check the last 20 lines or so of that one to see how the serial debugging reacted when I plugged in the mouse (a logitech model if that matters). This was tested with hrev25002. Seems that it boots up fully about 80-90% of the time now, only occasionally halting on the 4th icon.

[mmlr]

The mouse cannot work, as the host controller that you have is not supported by any driver right now. If it works then this is only because of legacy emulation. That you get messages from EHCI indicates that EHCI is working properly, but as the device you're attaching is low or fullspeed, EHCI will just hand over control to the companion host controller (OHCI). This will then not do anything with the device as there is no driver for OHCI. What concerns me more is that the serial logs you are posting are completely distorted. Are those actual serial logs or are those syslogs? In any case it looks to me like some synchronization / locking is not working, so messages from different places get mixed up completely. Maybe someone else can have a look and maybe has an idea as to what could be going wrong here?

[mmlr]

As OHCI is implemented now, an updated status would be nice. The controller should now have a driver and so USB input devices should work when booted. I would be interested in hearing if it still hangs at boot sometimes. If it was related to the missing OHCI this should now hopefully be fixed.

[scottmc]

Ok, it seems to be better with hrev25673 running on it now. I've tried 5 or 6 reboots and restarts but always boots all the way up now. Can close this one now.

[stippi]

Cool, thanks for checking. Please reopen if it isn't fixed after all!