EHCI on Rev C

GoogleGroups
1

Folks,
I tend to lurk in the shadows and read posts. Jason finally nudged me enough to start posting myself and getting into git more. I typically get early boards to make sure they work and help with tests for anything new.

I’ve been validating the EHCI port on the Rev C1 Beagleboard. It works rather nicely. I haven’t done any kind of throughput testing, but I am able to insert a USB memory stick and copy files on/off it. And use a USB Wireless adapter, too.

I have attached a patch that Jason helped me create. Since I’ve never put patches out, I’m interested in comments and advice. I started with a git clone from linux-omap in December. 2.6.28-rc9. Basically, I modified the ehci-omap.c driver to support the reset line on Beagle and then commented out the GPIO code in usb-ehci.c. That code needs to be modifed to properly support powering on the phy. Right now I do that in u-boot.

My plan is to update the code I have and then fix usb-ehci.c so that it properly powers the phy and then push that out.

Then on to 256M x-loader changes!

Steve K.

0001-This-merges-Steve-Kipisz-USB-EHCI-support.-He-star.patch (6.5 KB)

2

Steve Kipisz wrote:

Folks,
I tend to lurk in the shadows and read posts. Jason finally nudged me
enough to start posting myself and getting into git more. I typically get
early boards to make sure they work and help with tests for anything new.

Great. Welcome!

I've been validating the EHCI port on the Rev C1 Beagleboard. It works
rather nicely. I haven't done any kind of throughput testing, but I am able
to insert a USB memory stick and copy files on/off it. And use a USB
Wireless adapter, too.

I have attached a patch that Jason helped me create. Since I've never put
patches out, I'm interested in comments and advice. I started with a git
clone from linux-omap in December. 2.6.28-rc9. Basically, I modified the
ehci-omap.c driver to support the reset line on Beagle and then commented
out the GPIO code in usb-ehci.c. That code needs to be modifed to properly
support powering on the phy. Right now I do that in u-boot.

My plan is to update the code I have and then fix usb-ehci.c so that it
properly powers the phy and then push that out.

Then on to 256M x-loader changes!

Hmm, why do we need to change x-loader for 256MB ram? Isn't existing x-loader already working fine with 256MB (Beagle, Overo) devices? U-Boot then auto-detects 128MB/256MB and does the init.

Best regards

Dirk

3

Folks,
I tend to lurk in the shadows and read posts. Jason finally nudged me
enough to start posting myself and getting into git more. I typically get
early boards to make sure they work and help with tests for anything new.

I've been validating the EHCI port on the Rev C1 Beagleboard. It works
rather nicely. I haven't done any kind of throughput testing, but I am able
to insert a USB memory stick and copy files on/off it. And use a USB
Wireless adapter, too.

I have attached a patch that Jason helped me create. Since I've never put
patches out, I'm interested in comments and advice. I started with a git
clone from linux-omap in December. 2.6.28-rc9. Basically, I modified the
ehci-omap.c driver to support the reset line on Beagle and then commented
out the GPIO code in usb-ehci.c. That code needs to be modifed to properly
support powering on the phy. Right now I do that in u-boot.

Thanks for posting your patch!

I attempted to test it. Your patch applied successfully, but would not compile:

In file included from drivers/usb/host/ehci-hcd.c:1018:
drivers/usb/host/ehci-omap.c: In function 'omap_start_ehc':
drivers/usb/host/ehci-omap.c:243: error: 'PHY_STP_PULLUP_DISABLE'

undeclared (first use in this function)

Looks like the patch is missing a definition for PHY_STP_PULLUP_DISABLE.

Steve

4

I don't have the updated patch handy, but you can pull a better patch from this commit: http://www.beagleboard.org/gitweb/?p=linux-2.6.git;a=commitdiff;h=4c79dd4e88c57a860692eb23864b3f2030d6d459

5

I believe the correct pinmux fixes in u-boot are at http://www.beagleboard.org/gitweb/?p=u-boot-arm.git;a=commitdiff;h=64c4ee2a8ac2a37d9f9d8bed456c9abadf537c2b. Sorry I haven't had time to make this neat yet, but I don't want to leave you hanging.

6

Try http://cgit.openembedded.net/cgit.cgi?url=openembedded/tree/packages/linux/linux-omap-2.6.28/0001-This-merges-Steve-Kipisz-USB-EHCI-support.-He-star.patch

regards,

Koen

7

Is it intentional that the HSUSB2_DATA1 pullup is enabled? None of
the other data lines are.

+ MUX_VAL(CP(ETK_D15_ES2), (IEN | PTU | EN | M3)) /*HSUSB2_DATA1*/\

Probably won't hurt anything, just looks strange.

Steve

8

I checked with the code I got from S. Kipisz and it does indeed have this one signal different. I'd have to let him comment. My guess is that you are right. There might be some minimal impact on power consumption.

9

This is most likely a hold over from some previous testing on Rev C. I don’t believe it is required. I would remove it and if we determined it was needed, we can always add it.

Gerald

10

As I am populating the u-boot changes for Validation version, can some
one consolidate on what all are the things I need to push into the
default u-boot on Rev C.

Regards,
Khasim

11

I’m pretty sure Gerald is correct and it is a hold over from some testing. It is not required.

Steve K.

12

The x-loader code I have for Beagle is very old. It only configures SDRC CS0 for 128M. If I read the Rev C changes correctly, there should be 128M on CS0 and 128M on CS1 for the 256M boards. My x-loader would have to be modified to support CS1. Maybe I should just pull the latest x-loader and u-boot and look at those.

Steve K.

13

Steve Kipisz wrote:

The x-loader code I have for Beagle is very old. It only configures SDRC
CS0 for 128M. If I read the Rev C changes correctly, there should be 128M
on CS0 and 128M on CS1 for the 256M boards. My x-loader would have to be
modified to support CS1. Maybe I should just pull the latest x-loader and
u-boot and look at those.

u-boot should detect and enable the second bank automatically. No x-loader
change is needed.

14

Everything works "automagically" for me, I use the same x-load and uboot built from sakomans tree on my beagles[1] and it does the correct thing.

regards,

Koen

[1] Since yesterday I use Jasons u-boot on my rev C to get EHCI

15

Another thing I noticed was:

+ MUX_VAL(CP(ETK_D11_ES2), (IDIS | PTU | DIS | M3)) /*HSUSB2_STP*/\

Previously (and in the default setup for HSUSB0 and HSUSB1) the pullup
was enabled. Was this change intentional?

Obviously, it works :slight_smile: I just want to check to make sure it was intentional.

Steve