Re: MPC8313E-RDB and USB OTG
Leo, sorry for sending this twice. Forgot to cc the list. I am hoping someone can shed some light on the state of the USB support in the 2.6.28 kernel for USB OTG on the MPC8313E RDB. The configuration options are a bit different than the ones from the provided LTIB kernel--- for obvious reasons--- and I am trying to figure out how to get OTG working in this version of the kernel on my board. USB OTG support for Freescale USB has not been included in mainline. So you need to bring the OTG code up-to-date, or stay with the LTIB kernel. - Leo Thanks Leo. I will look into getting the OTG code included. Do you have a general outline of what would need to be done to it? Any potential trouble spots? Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC8313E-RDB and USB OTG
Hi all,
I am hoping someone can shed some light on the state of the USB support in
the
2.6.28 kernel for USB OTG on the MPC8313E RDB. The configuration options are
a bit different than the ones from the provided LTIB kernel--- for obvious
reasons---
and I am trying to figure out how to get OTG working in this version of the
kernel
on my board.
I have tried to configure the kernel as close as I could to the config for
the LTIB
kernel (2.6.23). This is what it looks like right now:
Kernel config
Device drivers ---
[*] USB support ---
--- USB support
* Support for Host-side USB
[*] USB verbose debug messages
[*] USB announce new devices
*** Miscellaneous USB options ***
[*] USB device filesystem
[*] USB device class-devices (DEPRECATED)
[*] USB Monitor
*** USB Host Controller Drivers ***
* EHCI HCD (USB 2.0) support
-*- Root Hub Transaction Translators
[*] Support for Freescale on-chip EHCI USB controller
[*] EHCI support for PPC USB controller on OF platform bus
*** USB Device Class drivers ***
* USB Mass Storage support
[*] USB Mass Storage verbose debug
*** USB Miscelaneous drivers ***
* USB Gadget Support ---
--- USB gadget support
(2) Maximum VBUS Power usage (2-500 mA)
USB Peripheral Controller (Freescale Highspeed USB
DR Peripheral Controller) ---
Freescale Highspeed USB DR Peripheral
Controller
* USB Gadget Drivers (Ethernet Gadget (with CDC
Ethernet support)) ---
Ethernet Gadget (with CDC Ethernet support)
[*] RNDIS support
The device tree node seems to be pretty straight forward.
Device tree node:
u...@23000 {
compatible = fsl-usb2-dr;
reg = 0x23000 0x1000;
#address-cells = 1;
#size-cells = 0;
interrupt-parent = ipic;
interrupts = 38 0x8;
phy_type = ulpi;
dr_mode = otg;
sleep = pmc 0x0030;
};
Here is the output I get from the kernel when bringing up the USB:
usbmon: debugfs is not available
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: Freescale On-Chip EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.28 ehci_hcd
usb usb1: SerialNumber: fsl-ehci.0
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007)
udc: request mem region for fsl-usb2-udc failed
fsl-usb2-udc: probe of fsl-usb2-udc.0 failed with error -16
I tracked down the error to the fsl_udc_probe function in fsl_usb2_udc.c:
static int __init fsl_udc_probe(struct platform_device *pdev)
{
struct resource *res;
int ret = -ENODEV;
unsigned int i;
u32 dccparams;
if (strcmp(pdev-name, driver_name)) {
VDBG(Wrong device);
return -ENODEV;
}
udc_controller = kzalloc(sizeof(struct fsl_udc), GFP_KERNEL);
if (udc_controller == NULL) {
ERR(malloc udc failed\n);
return -ENOMEM;
}
spin_lock_init(udc_controller-lock);
udc_controller-stopped = 1;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
ret = -ENXIO;
goto err_kfree;
}
if (!request_mem_region(res-start, res-end - res-start + 1,
driver_name)) {
ERR(request mem region for %s failed\n, pdev-name);
ret = -EBUSY;
goto err_kfree;
}
...
Now, I can stick in a USB flash drive and mount it. So, I know the host side
is working fine. The gadget driver doesn't appear to be able to load,
presumably because the host driver has already registered its memory
resources and will not release/share them.
What is the correct configuration to have real OTG working? Specifically,
what is the configuration that will allow me to plug in a flash drive and
mount it, unmount it, plug in a host (laptop or such) and have it think it
is connected to a USB Ethernet gadget WITHOUT having to manually
load and unload modules?
Thanks any help you can provide.
Mike
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Re: Can not get new MPC8313e-RDB to boot as-shipped flash image
Hi guys, I have the Rev B board and I have it working quite well. I'll share what I have discovered so far. In Eric's case, the board seems suspect. There is already a Rev C of this board, but I am not sure if it is actually available yet. You may want to check on that. Regarding U-Boot, mine shipped with v. 1.3.0. The LTIB provided dts files follow the original dts format. There is a new dts spec and if you ever intend to use a mainline kernel, you will need to use the newer dts provided in the kernel source. Did I mention this board has at least basic support in 2.6.28 :). I have not determined the extent of the support though. I have successfully used the provided U-Boot v1.3.0 to boot a 2.6.28 kernel with the dts-v1 device tree. Hence, I hope that will clear your speculation about the device tree being the problem. I have seen the same problem that you guys have seen where U-Boot gets to the Uncompressing kernel ... then reboots. This happened to me when I passed the wrong device tree .dtb. I have also had this happen if I made a change to the kernel config. I haven't been able to determine what exactly that I changed that caused the problem though. Also, if you are feeling adventurous, you can also get the latest U-Boot. There is a specifc branch for this board: $ git clone git://git.denx.de/u-boot-mpc83xx.git I haven't attempted this since I don't currently have a probe to recovery a bad boot loader flash. Hope this helps, Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Newby trying to get Ethernet going on MPC83xx series device.
Great. Glad you have it working. I actually did the very same thing not too long ago. Amazing how well things work, when you pass the right information :) On Mon, Feb 23, 2009 at 12:28 AM, Dushara Jayasinghe dusha...@optiscan.comwrote: -Original Message- From: linuxppc-dev-bounces+dusharaj=optiscan@ozlabs.org [mailto:linuxppc-dev-bounces+dusharaj linuxppc-dev-bounces%2Bdusharaj= optiscan@ozlabs.org] On Behalf Of Dushara Jayasinghe Sent: Friday, 20 February 2009 6:18 PM To: 'Michael Bergandi' Cc: linuxppc-dev@ozlabs.org; Aggrwal Poonam-B10812; Timur Tabi Subject: RE: Newby trying to get Ethernet going on MPC83xx series device. Hi all, I've solved this issue. I was passing the wrong .dtb file to the kernel. Sorry for adding noise the list. Thanks again for all you help. D -- Michael Bergandi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: soc vs localbus for flash in device tree
I'm working on the kernel version Linux-2.6.29-rc5 with U-Boot 1.2.0-g88e21e7b-dirty. I recommend you use a more current version of U-Boot. That one is quite old. Does the flash node HAVE to be within a localbus node or can it reside within the soc node? I've been basing my work on mpc834x_mds.dts And hence haven't defined a localbus node. I think it can be in either, but the most common place I've seen is in the soc node. BTW is there a way to search the ML archive? Currently I browse each month to search for prior postings. Yes, Google site:ozlabs.org what ever you are looking for Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Newby trying to get Ethernet going on MPC83xx series device.
Hi Dushara,
Sorry, I'm a late comer here, but I might have an idea. First off, I don't
see below what
kernel version you are using? I may have missed it somewhere.
The devices are successfully probed, but I'm getting this error on the
debug console:
[7.119389] m...@24520:00 not found
[7.161370] eth0: Could not attach to PHY
[7.209600] IP-Config: Failed to open eth0
[7.258879] IP-Config: Device `eth0' not found.
I have similar output on my MPC8313E RDB. In my case, eth0 shared lines with
the external USB OTG and its PHY. I modified the resister banks on the board
that essentially cuts off the interrupt to the eth0 PHY. So, I don't expect
it to find it. Here is the kernel output at init time:
24520:01 not found
eth0: Could not attach to PHY
My mdio Ethernet nodes are as follows (commenting out device_type below is
an experiment)
m...@24520 {
/*device_type = mdio;*/
compatible = fsl,gianfar-mdio;
#address-cells = 1;
#size-cells = 0;
reg = 24520 20;
Hmm, well, the first thing I catch is this is an old dts format. Depending
on your kernel version, you
may want to comply with the dts v1 spec. The v1 spec is much more strict on
the format of the values
that are provided for the properties.
ex. reg = 0x24520 0x20 makes it very clear that these values are hex, not
decimal.
You will notice this ambiguity below with the 'interrupts' properties. Are
the values decimal or hex?
Turns out that the values are hex. You will find dts version specifier
/dts-v1/; at the top or just before
the root node in any dts file that meets the v1 spec.
phy0: ethernet-...@0 {
interrupt-parent = ipic;
interrupts = 3 8;
reg = 0;
device_type = ethernet-phy;
};
phy1: ethernet-...@1 {
interrupt-parent = ipic;
interrupts = 3 8;
reg = 1;
device_type = ethernet-phy;
};
};
Are you sure both PHY's use interrupt 3? I would think not.
enet0: ether...@24000 {
cell-index = 0;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 24000 1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 20 8 21 8 22 8;
interrupt-parent = ipic;
phy-handle = phy0;
linux,network-index = 0;
};
enet1: ether...@25000 {
cell-index = 1;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 25000 1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 23 8 24 8 25 8;
interrupt-parent = ipic;
phy-handle = phy1;
linux,network-index = 1;
phy-connection-type = gmii;
};
Finally, I don't know which silicon rev that you are using, but I have seen
the enet0 and enet1 interrupts swapped.
As in the very latest silicon may have the interrupt lines switched between
them. You can find a statement to that
affect on this list somewhere. I am using a revB MPC8313E and I specify the
interrupts as you have them here.
However, the dts file for the mpc8313erdb in the 2.6.28 kernel has them
reversed. Presumably for a revC chip.
ex.
enet0: ether...@24000 {
...
interrupts = 23 8 24 8 25 8;
...
};
enet1: ether...@25000 {
...
interrupts = 20 8 21 8 22 8;
...
};
BTW, I assume CCing all those who replied to me is accepted/expected
conduct or should I avoid this and just write to the list?
Yes, you should cc those who have replied. It is expected --- well, at least
by me.
Also is top posting ok? I haven't figured out how to enable '' on bloody
Microsoft Outlook, for incoming plain text messages.
I'm a little new to this list, but in general top posting is frowned upon.
Unfortunately, I can't help you with the Outlook problem.
I can tell you that not being able to determine what part of a message came
when is extremely annoying. I hope you find a fix
for it. Or, you could try Thunderbird :)
Mike
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
