GP2X Usb Host Mode == Not Working

[torpor]

check out http://wiki.gp2x.org/wiki/EXT_Port .. i've updated it with details about my latest set of tests to get USB Host mode working on the EXT Port .. looks like there is some disinformation on the EXT port details, actually, because: USB Host isn't wired!

 

[Julius]

Uhhh, that is bad news

Got any hardware based evidence for this, or is it all software evidence?

 

[BradN]

I'm not sure how you reached this conclusion - your drivers aren't even finding the port(s). On my computer, it detects the ports even if nothing's connected.

 

[calqlater]

The theory goes (I think) that if the driver isn't finding any ports, then the USB pins on the cpu are not connected to anything.

Basically, there is USB 1.1 host support inside the MMSP2 (this is shown by the fact that the drivers load correctly, if nothing else), but that it is NOT, in fact, attached to anything which would facilitate USB connections to the chip (ie - there are no ports connected to the USB host lines on the MMSP2).

Not being totally familiar with the workings of USB, I guess it's possible that there is a connection between the EXT port and the USB host lines, but that something intermediate, which makes those lines act like an actual "USB port" is missing.

Anyway, there was more discussion by torpor and others in this thread:

http://www.gp32x.de/board/index.php?showtopic=25085

 

[Series-8]

Ok, well stick an logging ocilloscope or something on those lines and watch what happens.

My suspicion is that some revisions of the board either do not have USB connected to EXT or are missing parts. And/or missing traces from CPU to well anything else.

Does the other USB port work ok? there were two connections remember, and they were not really marked well (like USB+/- Host, USB +/- Slave). So you could have been testing the wrong one.
(assuming the EXT schematic is EVEN ACCURATE...personnaly I would DISMANTLE and TRACE each connection on the EXT port or make 100% shure everything is wired where it should be)

Also there is that whole lack of 5V power thing... thats annother tricky issue.

 

[torpor]

Ok, well stick an logging ocilloscope or something on those lines and watch what happens.

did that, nothing.

Does the other USB port work ok?

neither one of the so-marked USB pins on EXT2 do what they're supposed to do .. i've test host and device on both .. no results.

(assuming the EXT schematic is EVEN ACCURATE...personnaly I would DISMANTLE and TRACE each connection on the EXT port or make 100% shure everything is wired where it should be)

yeah, at this point i'm only concluding that the accuracy of the EXT pinout is suspect .. i'm not giving up on it, but i'm not hopeful as i was ..

Also there is that whole lack of 5V power thing... thats annother tricky issue.

not a problem if you've got a hub in the works .. but the hub is not detected .. no ports are detected, so ..

 

[BradN]

Damn. That sort of kills any hope I had for using it as a portable web browser type thing.

 

[Squidge]

I know the driver your using should do it for you, but have you checked to make sure the GPIO pins are configured for USB? I think they are multiplexed between several devices.

Also, if you monitor the register containing the usb reset, you should see it trigger when place a load onto the lines (see the usb spec for the appropriate resistance).

 

[torpor]

I know the driver your using should do it for you, but have you checked to make sure the GPIO pins are configured for USB? I think they are multiplexed between several devices.

yup... i dunno about this comment, but it screams "doesn't properly work yet" to me ..

from usb-ohci-mmsp2.c:

/*
 * FIXME
 */
static void __init mmsp2_ohci_configure(void)
{
    unsigned long fclk = mmsp2_get_fclk();
    unsigned long aclk = mmsp2_get_aclk();
    unsigned long uclk = mmsp2_get_uclk();
    unsigned long f_fact = fclk / DESIRED_CLOCK;
    unsigned long a_fact = aclk / DESIRED_CLOCK;
    unsigned long u_fact = uclk / DESIRED_CLOCK;
    unsigned long f_clk = (fclk / f_fact);
    unsigned long a_clk = (aclk / a_fact);
    unsigned long u_clk = (uclk / u_fact);
    unsigned long f_err = abs(DESIRED_CLOCK - f_clk);
    unsigned long a_err = abs(DESIRED_CLOCK - a_clk);
    unsigned long u_err = abs(DESIRED_CLOCK - u_clk);

    printk("f_fact = %ld, f_clk = %ld, f_err = %c%ld\n",
            f_fact, f_clk, f_clk > DESIRED_CLOCK ? '+':'-', f_err);
    printk("a_fact = %ld, a_clk = %ld, a_err = %c%ld\n",
            a_fact, a_clk, a_clk > DESIRED_CLOCK ? '+':'-', a_err);
    printk("u_fact = %ld, u_clk = %ld, u_err = %c%ld\n",
            u_fact, u_clk, u_clk > DESIRED_CLOCK ? '+':'-', u_err);

    /* from EBOOT */
    UIRMCSET &= 0xff00;
    UIRMCSET |= ((0x02) << 6) | 1;

    gpio_pad_select(USB_PAD_3T, 0);     // PAD3 --> USB device^M
    gpio_pad_select(USB_PAD_1T, 0);     // PAD1 --> USB host
#ifdef CONFIG_MMSP2_UPAD3_TO_DEVICE
    gpio_pad_select(USB_PAD_3T, 1);     // PAD3 --> USB device
    gpio_pad_select(USB_PAD_1T, 0);     // PAD1 --> USB host

#endif

    udelay(11);
}

static int __init mmsp2_ohci_init(void)
{
    int ret;

    mmsp2_ohci_configure();

    ret = hc_add_ohci((void*)(1), IRQ_USBH,
              (void *)(io_p2v(0xc0004300)), 0, "usb-ohci", "mmsp2_ohci");
    if((ret & 0xF0000000)==0xC0000000) {
        mmsp2_ohci = (ohci_t *)ret;
        ret = 0;
    }
    return ret;
}

Also, if you monitor the register containing the usb reset, you should see it trigger when place a load onto the lines (see the usb spec for the appropriate resistance).

i do not see this trigger .. have tried it twice now ..

time to dig through the mmsp2 docs and see if there's anything in there that will give us clues about how to get past that "FIXME" paranoia ...

 

[KaosOverride]

Sounds like an stupid suggestion, but... what about inverting the polarity of the USB lines? I mean, USB+ to deviceUSB- and USB- to deviceUSB+

Sounds stupid but I remember an XboX which i tried to attach an USB keyboard, didn't work as some internet schmes show (I respected the cable colors on the Xbox Pad cable), then I joined the cables inverted and worked.. (Red with green and green with red, or something like that...) I get hallucinated...

as you say, the pinout description is not considered 100% accurate, is it?

 

[BradN]

I wonder what happens if you force the "detected ports" count to 1...