Re: Oops: of_platform_serial_probe
Hi, Arnd!
Arnd Bergmann schrieb:
On Monday 19 November 2007, Clemens Koller wrote:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc018f03c
Oops: Kernel access of bad area, sig: 11 [#1]
MPC85xx ADS
Modules linked in:
NIP: c018f03c LR: c018f00c CTR: c00127b4
REGS: c0821cf0 TRAP: 0300 Not tainted (2.6.24-rc2-ge6a5c27f)
MSR: 00029000 EE,ME CR: 42022088 XER: 2000
DEAR: , ESR:
TASK = c081e000[1] 'swapper' THREAD: c082
GPR00: b100 c0821da0 c081e000 c0833e10 0004 c0821d80 c03d3064
c05eea80
GPR08: 0200 0002 002a 13ab6680 82022042 c03318a4
c033188c
GPR16: c0331908 c03318f0 c03a0e30 c0331930 c033191c 007fff00 0ffeccbc
c03a
GPR24: c0821dc4 0003 c0934cf8 cba8 c0833e00
c07fdc6c
NIP [c018f03c] of_platform_serial_probe+0x118/0x1e4
LR [c018f00c] of_platform_serial_probe+0xe8/0x1e4
Call Trace:
Ok, that is a NULL pointer access, probably somewhere in the
of_platform_serial_setup that can be inlined. Please post the
device tree entries for your serial ports so we can see what
goes wrong there.
The device tree is the default one which comes with the kernel:
paulus.git/arch/powerpc/boot/dts/mpc8540ads.dts
which contains:
[EMAIL PROTECTED] {
device_type = serial;
compatible = ns16550;
reg = 4500 100; // reg base, size
clock-frequency = 0; // should we fill in in uboot?
interrupts = 2a 2;
interrupt-parent = mpic;
};
[EMAIL PROTECTED] {
device_type = serial;
compatible = ns16550;
reg = 4600 100; // reg base, size
clock-frequency = 0; // should we fill in in uboot?
interrupts = 2a 2;
interrupt-parent = mpic;
};
One potential problem that I can see is a missing 'current-speed'
property in your tree, which would cause this behavior.
That's correct. Should be fixed in all .dts' ?
It looks
like many device trees set this, but it is not required by all
bindings.
How should someone know, when it's really needed and when not?
If that's the case, the patch below should fix your
problem, but you probably want to set the current-speed anyway,
according to your boot loader settings.
I think there was no need to set it again, because of: console=ttyS0,115200
But I'll verify...
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -56,7 +56,8 @@ static int __devinit of_platform_serial_setup(struct
of_device *ofdev,
port-flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
| UPF_FIXED_PORT;
port-dev = ofdev-dev;
- port-custom_divisor = *clk / (16 * (*spd));
+ if (spd)
+ port-custom_divisor = *clk / (16 * (*spd));
return 0;
}
Ack! However, I changed it similar to the available code.
No idea what's better here. At least it should tell the user:
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
console [ttyS0] enabled
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 42) is a 16550A
of_serial e0004500.serial: no current-speed property set
of_serial e0004600.serial: no current-speed property set
Patch attached.
Regards,
--
Clemens Koller
__
RD Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
Warn user when current-speed property isn't set and exit.
Signed-off-by: Clemens Koller [EMAIL PROTECTED]
CC: Arnd Bergmann [EMAIL PROTECTED]
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..e035cb2 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -36,6 +36,10 @@ static int __devinit of_platform_serial_setup(struct
of_device *ofdev,
memset(port, 0, sizeof *port);
spd = of_get_property(np, current-speed, NULL);
clk = of_get_property(np, clock-frequency, NULL);
+ if (!spd) {
+ dev_warn(ofdev-dev, no current-speed property set\n);
+ return -ENODEV;
+ }
if (!clk) {
dev_warn(ofdev-dev, no clock-frequency property set\n);
return -ENODEV;
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 2.6 kernel hangs after loading device tree
charanya venkatraman wrote: Hi all Sorry about the previous mail.Got sent by mistake. Iam using the 2.6.22.5 kernel on MPC 8560 and MPC8540 on my custom board.Mykernel hangs after loading the device tree in both the processors. There is no output on the serial port after loading the device tree. I have tried the following console arguments: MPC8540: bootargs root=/dev/ram rw console=ttyS0,115200 MPC8560:bootargs root=/dev/ram rw console=ttyCPM0,115200 Any help on this issue?? Maybe your problem is related to... See the thread at: http://ozlabs.org/pipermail/linuxppc-embedded/2007-November/028968.html (I use Paulus' git tree.) Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Oops: of_platform_serial_probe
On Tuesday 20 November 2007, Clemens Koller wrote:
The device tree is the default one which comes with the kernel:
paulus.git/arch/powerpc/boot/dts/mpc8540ads.dts
which contains:
[EMAIL PROTECTED] {
device_type = serial;
compatible = ns16550;
reg = 4500 100; // reg base, size
clock-frequency = 0; // should we fill in in
uboot?
interrupts = 2a 2;
interrupt-parent = mpic;
};
[EMAIL PROTECTED] {
device_type = serial;
compatible = ns16550;
reg = 4600 100; // reg base, size
clock-frequency = 0; // should we fill in in
uboot?
interrupts = 2a 2;
interrupt-parent = mpic;
};
One potential problem that I can see is a missing 'current-speed'
property in your tree, which would cause this behavior.
That's correct. Should be fixed in all .dts' ?
It depends a lot on how the systems are used. current-speed only makes
sense if there is a boot loader that also does some serial I/O at a
speed it sets up itself.
It looks
like many device trees set this, but it is not required by all
bindings.
How should someone know, when it's really needed and when not?
The point of current-speed is that the kernel can tell what bitrate
was used by the boot loader and set up the same speed so that your
terminal emulation does not get garbled output when changing from
boot loader messages to kernel messages.
If that's the case, the patch below should fix your
problem, but you probably want to set the current-speed anyway,
according to your boot loader settings.
I think there was no need to set it again, because of: console=ttyS0,115200
But I'll verify...
When current-speed is set, you don't need to override the speed at the
command line.
@@ -36,6 +36,10 @@ static int __devinit of_platform_serial_setup(struct
of_device *ofdev,
memset(port, 0, sizeof *port);
spd = of_get_property(np, current-speed, NULL);
clk = of_get_property(np, clock-frequency, NULL);
+ if (!spd) {
+ dev_warn(ofdev-dev, no current-speed property set\n);
+ return -ENODEV;
+ }
if (!clk) {
dev_warn(ofdev-dev, no clock-frequency property set\n);
return -ENODEV;
This looks wrong. Since the current-speed property is not mandated by open
firmware,
we should not error out here, but simply use the setting from the command line
or whatever other defaults can be used. Not setting port-custom_divisor at all
should do the job.
Arnd
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Problem with uboot on lite5200
Hello, Wolfgang! Wolfgang Denk schrieb: In message [EMAIL PROTECTED] you wrote: How should people get a glue what's current, when in the section Latest News at http://sourceforge.net/projects/u-boot/ the people still find a more or less official looking u-boot-1.1.5 release. Maybe by reading the very first two lines on the SF page: ... NOTE: current source code is available from DENX git repository and FTP server; see http://www.denx.de/en/Software/GIT I tried to convince you to point them to the releases... and _not_ to any repository. The problem is that you cannot really shut down a SourceForge project (please correct me if I'm wrong). I don't like SourceForge for some reasons... now, if that's true, I got one more. But anyway, there should be a way to update the Latest News... in a way it points to current stuff. Current U-Boot is 1.3.0-rc4. Please wake up. Well... maybe it's better to remove all references to the old releases at sourceforge and point them to ftp://ftp.denx.de/pub/u-boot/ Can you please teach me how to do that? I would expect that one of the project admins (i.e. you) is able to update the site information. You could update the SF project as you did since u-boot-0.2.0. If you don't want to continue with SF, propably an update to a last SF version with nothing more than an README should suffice. Well, I know you expect people to read... I'm just wondering why so many people use ancient versions. (-: And 1.3.0 will be out in less than 2 hours from now :-) Well... that's great... thank you all! Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Oops: of_platform_serial_probe
@@ -36,6 +36,10 @@ static int __devinit of_platform_serial_setup(struct
of_device *ofdev,
memset(port, 0, sizeof *port);
spd = of_get_property(np, current-speed, NULL);
clk = of_get_property(np, clock-frequency, NULL);
+ if (!spd) {
+ dev_warn(ofdev-dev, no current-speed property set\n);
+ return -ENODEV;
+ }
if (!clk) {
dev_warn(ofdev-dev, no clock-frequency property set\n);
return -ENODEV;
This looks wrong. Since the current-speed property is not mandated by open
firmware,
we should not error out here, but simply use the setting from the command
line
or whatever other defaults can be used. Not setting port-custom_divisor at
all
should do the job.
Understood... but then, my console just stops / gets reinitialized to some
unknown
baudrate when I get to of_serial.c. :-(
Regards,
Clemens Koller
__
RD Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
ML403 USB driver
Hi, we just tried the USB driver (from Peter Korsgaard) from Grant's virtex tree. Nevertheless we could not get the peripheral ports work as gadgets. Has anyone tried (and probably fixed) that before? Anyway, only one of the two peripheral ports seems to be active. We use kernel 2.6.22 (as some usb related stuff has recently changed and the driver would have to be changed), usb host works (usb-storage, cdc_ether, some more stuff we tested) Regards, Lorenz Kolb -- View this message in context: http://www.nabble.com/ML403-USB-driver-tf4844098.html#a13858912 Sent from the linuxppc-embedded mailing list archive at Nabble.com. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ML403 USB driver
On 11/20/07, Lorenz Kolb [EMAIL PROTECTED] wrote: Hi, we just tried the USB driver (from Peter Korsgaard) from Grant's virtex tree. Nevertheless we could not get the peripheral ports work as gadgets. Has anyone tried (and probably fixed) that before? That driver does not work for gadget ports. Anyway, only one of the two peripheral ports seems to be active. Yes, I've got that problem here too. I haven't yet solved it. Any help would be appreciated. We use kernel 2.6.22 (as some usb related stuff has recently changed and the driver would have to be changed), usb host works (usb-storage, cdc_ether, some more stuff we tested) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] powerpc: Change _tlbie arguments to reflect new API
A new pid argument has been added to _tlbie for 4xx platforms.
Add this argument to the 8xx path in mem.c, as well. As 8xx
does not need th epid information, this argument can always be 0.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
CC arch/powerpc/mm/mem.o
arch/powerpc/mm/mem.c: In function 'update_mmu_cache':
arch/powerpc/mm/mem.c:467: error: too few arguments to function '_tlbie'
make[1]: *** [arch/powerpc/mm/mem.o] Error 1
make: *** [arch/powerpc/mm] Error 2
---
arch/powerpc/mm/mem.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 81eb96e..e07852e 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -464,7 +464,7 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned
long address,
* we invalidate the TLB here, thus avoiding dcbst
* misbehaviour.
*/
- _tlbie(address);
+ _tlbie(address, 0);
#endif
if (!PageReserved(page)
!test_bit(PG_arch_1, page-flags)) {
--
1.5.3.4
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH try2] powerpc: Add support for PORTA and PORTB odr registers
PORTA and PORTB have odr registers, as well. However, the PORTB odr
register is only 16bit.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
arch/powerpc/sysdev/commproc.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index d5a0dcf..c0d00c2 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -411,7 +411,7 @@ EXPORT_SYMBOL(cpm_dpram_phys);
#endif /* !CONFIG_PPC_CPM_NEW_BINDING */
struct cpm_ioport16 {
- __be16 dir, par, sor, dat, intr;
+ __be16 dir, par, odr_sor, dat, intr;
__be16 res[3];
};
@@ -441,6 +441,13 @@ static void cpm1_set_pin32(int port, int pin, int flags)
else
clrbits32(iop-par, pin);
+ if (port == CPM_PORTB) {
+ if (flags CPM_PIN_OPENDRAIN)
+ setbits16(mpc8xx_immr-im_cpm.cp_pbodr, pin);
+ else
+ clrbits16(mpc8xx_immr-im_cpm.cp_pbodr, pin);
+ }
+
if (port == CPM_PORTE) {
if (flags CPM_PIN_SECONDARY)
setbits32(iop-sor, pin);
@@ -474,11 +481,17 @@ static void cpm1_set_pin16(int port, int pin, int flags)
else
clrbits16(iop-par, pin);
+ if (port == CPM_PORTA) {
+ if (flags CPM_PIN_OPENDRAIN)
+ setbits16(iop-odr_sor, pin);
+ else
+ clrbits16(iop-odr_sor, pin);
+ }
if (port == CPM_PORTC) {
if (flags CPM_PIN_SECONDARY)
- setbits16(iop-sor, pin);
+ setbits16(iop-odr_sor, pin);
else
- clrbits16(iop-sor, pin);
+ clrbits16(iop-odr_sor, pin);
}
}
--
1.5.3.4
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 2.6 kernel hangs after loading device tree
Hi, I got a solution to this.The problem was with the current speed parameter in the DTS,as stated.You need to explicity specify the speed.It doesnot get filled in from U-boot.You can also probabaly check the kernel log buf to see what values are set for these parameters.Anyways,changing the current speed made it work me and my 2.6 kernel is now up. Thanks. Charanya. Date: Mon, 19 Nov 2007 16:08:03 -0800 (PST) From: abhi_linux [EMAIL PROTECTED] Subject: Re: 2.6 kernel hangs after loading device tree To: linuxppc-embedded@ozlabs.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Hello Did u get a solution to this? I have similar issues. How do u enable debugging in UBoot? Thanks charanya venkatraman wrote: Hi all Sorry about the previous mail.Got sent by mistake. Iam using the 2.6.22.5 kernel on MPC 8560 and MPC8540 on my custom board.Mykernel hangs after loading the device tree in both the processors .There is no output on the serial port after loading the device tree.Am using U-boot 1.2.0 as the bootloader.After enabling debug in u-boot i could see that the control is getting transferred to the kernel after which it hangs.Earlier i tried using 2.6.21 which also hangs at the same point.The config files used were MPC8540ADS_defconfig and MPC8560ADS_defconfig under powerpc directory. The changes that were made to the device tree are: 1.The reg and ranges properties of the soc node have been changed to account for the change in CCSRBAR of my board. 2.Removed the PCI,mdio nodes and ethernet nodes since i dont need support for these as of now. I have tried the following console arguments: MPC8540: bootargs root=/dev/ram rw console=ttyS0,115200 MPC8560:bootargs root=/dev/ram rw console=ttyCPM0,115200 Any help on this issue?? Thanks. Charanya. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
linux2.6.19.2- mpc8xx_wdt.c: timeout extended to reach several seconds... but I have a problem
Till yesterday I thought I was able to code a simple driver but now I'm facing
a problem that is puzzling me.
I added a kernel timer (triggering every 500 ms) to reset the watchdog of
mpc8xx. This timer starts when the driver is opened. The timer is rearmed till
a counter reaches a zero value. A process can use the write method of the
driver to set the counter to a preferred value. If the application misses to
set the counter, it will decrease to zero and then the board will restart.
Unfortunately as soon as my application calls the write method the kernel
freezes. If the watchdog is enabled the board restarts otherwise the kernel
remains blocked forever without any indication. Even if I empty the write
method leaving only the get_user the board freezes. Below you can find the
code, if anyone has an hint I would really appreciate his advice:
___
/*
* mpc8xx_wdt.c - MPC8xx watchdog userspace interface
*
* Author: Florian Schirmer [EMAIL PROTECTED]
*
* 2002 (c) Florian Schirmer [EMAIL PROTECTED] This file is licensed under
* the terms of the GNU General Public License version 2. This program
* is licensed as is without any warranty of any kind, whether express
* or implied.
*/
#include linux/fs.h
#include linux/init.h
#include linux/kernel.h
#include linux/miscdevice.h
#include linux/module.h
#include linux/watchdog.h
#include asm/8xx_immap.h
#include asm/uaccess.h
#include asm/io.h
#include syslib/m8xx_wdt.h
#define KTIMER_TIMEOUT (HZ/2)
static struct timer_list wd_timer; /* structure for timer administration
*/
static unsigned long mpc8xx_wdt_dummy;
static int timer_count = 600;
static unsigned long wdt_opened;
static int wdt_status;
static spinlock_t counter_spinlock;
static void mpc8xx_wdt_handler_disable(void)
{
volatile ushort __iomem *piscr;
piscr = (ushort *)((immap_t*)IMAP_ADDR)-im_sit.sit_piscr;
if (!m8xx_has_internal_rtc)
m8xx_wdt_stop_timer();
else
out_be16(piscr, in_be16(piscr) ~(PISCR_PIE | PISCR_PTE));
printk(KERN_NOTICE mpc8xx_wdt: keep-alive handler deactivated\n);
}
static void mpc8xx_wdt_handler_enable(void)
{
volatile ushort __iomem *piscr;
piscr = (ushort *)((immap_t*)IMAP_ADDR)-im_sit.sit_piscr;
if (!m8xx_has_internal_rtc)
m8xx_wdt_install_timer();
else
out_be16(piscr, in_be16(piscr) | PISCR_PIE | PISCR_PTE);
printk(KERN_NOTICE mpc8xx_wdt: keep-alive handler activated\n);
}
static int mpc8xx_wdt_open(struct inode *inode, struct file *file)
{
if (test_and_set_bit(0, wdt_opened))
return -EBUSY;
m8xx_wdt_reset();
wd_timer.expires = jiffies + KTIMER_TIMEOUT;
add_timer (wd_timer); /* ...re-activate timer */
mpc8xx_wdt_handler_disable();
return 0;
}
static int mpc8xx_wdt_release(struct inode *inode, struct file *file)
{
m8xx_wdt_reset();
#if !defined(CONFIG_WATCHDOG_NOWAYOUT)
mpc8xx_wdt_handler_enable();
#endif
clear_bit(0, wdt_opened);
return 0;
}
static void mpc8xx_wdt_ktimer_handler(unsigned long data)
{
int counter;
spin_lock(counter_spinlock);
counter = timer_count--;
spin_unlock(counter_spinlock);
printk(Counter %d\n, counter);
if (counter 0)
{
wd_timer.expires = jiffies + KTIMER_TIMEOUT;
add_timer (wd_timer);/* ...re-activate timer */
m8xx_wdt_reset();
}
else
{
printk(KERN_NOTICE mpc8xx_wdt: Watchdog expired ... restarting\n);
}
}
static ssize_t mpc8xx_wdt_write(struct file *file, const char *data, size_t
len, loff_t * ppos)
{
unsigned long flags;
int new_count;
if (len != sizeof(new_count))
{
return -EINVAL;
}
/* copy count value into kernel space */
get_user(new_count, (int *) data);
printk(new_count %d\n, new_count);
/* Removing the following three lines doesn't prevent
the kernel freeze */
spin_lock_irqsave(counter_spinlock, flags);
timer_count = (HZ*new_count)/KTIMER_TIMEOUT;
spin_unlock_irqrestore(counter_spinlock, flags);
return (sizeof(new_count));
}
static int mpc8xx_wdt_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
{
int timeout;
static struct watchdog_info info = {
.options = WDIOF_KEEPALIVEPING,
.firmware_version = 0,
.identity = MPC8xx watchdog,
};
switch (cmd) {
case WDIOC_GETSUPPORT:
if (copy_to_user((void *)arg, info, sizeof(info)))
return -EFAULT;
break;
case WDIOC_GETSTATUS:
case WDIOC_GETBOOTSTATUS:
if
Debugging with gdbserver slow
Hi everyone, Im using gdbserver to debug Linux apps on my embedded board, but it takes like 3-6 sec to step one line of code. Its about the same to go from breakpoint to breakpont. Im using TCP to connect the host to the target. Is this typical or is there some setting wrong or was it built wrong. Its a PPC405 in a Xilinx FPGA. Thanks khollan -- View this message in context: http://www.nabble.com/Debugging-with-gdbserver-slow-tf4846374.html#a13865715 Sent from the linuxppc-embedded mailing list archive at Nabble.com. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH try2] powerpc: Add support for PORTA and PORTB odr registers
Jochen Friedrich wrote: PORTA and PORTB have odr registers, as well. However, the PORTB odr register is only 16bit. Signed-off-by: Jochen Friedrich [EMAIL PROTECTED] Acked-by: Scott Wood [EMAIL PROTECTED] BTW, you may want to send the patches to linuxppc-dev rather than linuxppc-embedded... Despite what MAINTAINERS says, the former is where most patches get posted. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ML403 USB driver
Grant Likely-2 wrote: On 11/20/07, Lorenz Kolb [EMAIL PROTECTED] wrote: Anyway, only one of the two peripheral ports seems to be active. Yes, I've got that problem here too. I haven't yet solved it. Any help would be appreciated. Cheers, g. Well that's what we have found out till now, maybe it helps, or at least what we think to have found out: - First of all to the non functioning peripheral port: It is USB Peripheral 1. According to the schematics it should be powered using the OTGVBus-Port of the Cypress-Controller (nevertheless it has currently no level) - Secondly there is no configuration 1 Host + 2 Peripherals according to the datasheet from Cypress - Thirdly the initial configuration (at least that is what we are guessing) seems to be done via some standalone program coming from an Eeprom. - The three pins near the UART port are the serial console for the Cypress chip (we have not yet done any tests with that). - At least the peripherals are connected in a right way, as one SIE can only have one peripheral Some question aside the peripheral topic: Has anyone any idea how to make the cypress chip to have a _normal_ Host not an OTG one (as some USB-Hub might save us from our dilemma why we tried to use gadgets in peripheral mode)? Regards, Lorenz Kolb -- View this message in context: http://www.nabble.com/ML403-USB-driver-tf4844098.html#a13872475 Sent from the linuxppc-embedded mailing list archive at Nabble.com. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
