* Re: Compilation error in fsl_soc.c
From: Vitaly Bordug @ 2006-07-31 13:39 UTC (permalink / raw)
To: Demke Torsten-atd012; +Cc: linuxppc-embedded
In-Reply-To: <67194FEE6056B947B4EF756C9E497A2EA198F8@zuk35exm60.ds.mot.com>
On Mon, 31 Jul 2006 08:37:56 +0100
"Demke Torsten-atd012" <torsten.demke@motorola.com> wrote:
> Hi all,
>
> with a recent versions from Paulus merge-tree the compilation
> of MPC85xx CDS failed with following output:
> ...
> LD arch/powerpc/lib/built-in.o
> CC arch/powerpc/sysdev/mpic.o
> CC arch/powerpc/sysdev/indirect_pci.o
> AS arch/powerpc/sysdev/dcr.o
> CC arch/powerpc/sysdev/fsl_soc.o
> arch/powerpc/sysdev/fsl_soc.c: In function 'gfar_mdio_of_init':
> arch/powerpc/sysdev/fsl_soc.c:88: error: 'struct device_node' has no
> member name d 'n_intrs'
> arch/powerpc/sysdev/fsl_soc.c:91: error: 'struct device_node' has no
> member name d 'intrs'
> arch/powerpc/sysdev/fsl_soc.c: In function 'gfar_of_init':
> arch/powerpc/sysdev/fsl_soc.c:142: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:143: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:153: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:154: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:158: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:159: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:165: error: 'struct device_node' has no
> member nam ed 'n_intrs'
> arch/powerpc/sysdev/fsl_soc.c: In function 'fsl_i2c_of_init':
> arch/powerpc/sysdev/fsl_soc.c:254: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:255: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c: In function 'fsl_usb_of_init':
> arch/powerpc/sysdev/fsl_soc.c:391: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:392: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:440: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:441: error: 'struct device_node' has no
> member nam ed 'intrs'
> make[1]: *** [arch/powerpc/sysdev/fsl_soc.o] Error 1
> make: *** [arch/powerpc/sysdev] Error 2
No, since it is just going to be out.
I'll submit some patches addressing that this week...
--
Sincerely,
Vitaly
^ permalink raw reply
* DMA buffer synchronisation with ioremap()
From: Phil Nitschke @ 2006-07-31 13:10 UTC (permalink / raw)
To: linuxppc-embedded
(I go no replies last week, so I'll try again, with less explanation...)
If I master a DMA from a PCI device into a main memory buffer allocated
with dma_alloc_noncoherent(), I need to synchronise the destination
buffer using dma_sync_single_range_for_xxx() before and after the DMA.
But if the buffer is a very large chunk of memory (reserved at boot
time) which has been ioremap()-ed into the virtual address space, do I
need to still synchronise that memory?
Thanks,
--
Phil
^ permalink raw reply
* [PATCH] remove bogomips from /proc/cpuinfo
From: Olaf Hering @ 2006-07-31 12:59 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Remove bogomips from /proc/cpuinfo.
It is now really bogus since "timebase-frequency" is shown.
Signed-off-by: Olaf Hering <olh@suse.de>
---
arch/powerpc/kernel/setup-common.c | 14 --------------
1 file changed, 14 deletions(-)
Index: linux-2.6.18-rc3/arch/powerpc/kernel/setup-common.c
===================================================================
--- linux-2.6.18-rc3.orig/arch/powerpc/kernel/setup-common.c
+++ linux-2.6.18-rc3/arch/powerpc/kernel/setup-common.c
@@ -163,14 +163,6 @@ static int show_cpuinfo(struct seq_file
unsigned short min;
if (cpu_id == NR_CPUS) {
-#if defined(CONFIG_SMP) && defined(CONFIG_PPC32)
- unsigned long bogosum = 0;
- int i;
- for_each_online_cpu(i)
- bogosum += loops_per_jiffy;
- seq_printf(m, "total bogomips\t: %lu.%02lu\n",
- bogosum/(500000/HZ), bogosum/(5000/HZ) % 100);
-#endif /* CONFIG_SMP && CONFIG_PPC32 */
seq_printf(m, "timebase\t: %lu\n", ppc_tb_freq);
if (ppc_md.name)
seq_printf(m, "platform\t: %s\n", ppc_md.name);
@@ -263,12 +255,6 @@ static int show_cpuinfo(struct seq_file
seq_printf(m, "revision\t: %hd.%hd (pvr %04x %04x)\n",
maj, min, PVR_VER(pvr), PVR_REV(pvr));
-#ifdef CONFIG_PPC32
- seq_printf(m, "bogomips\t: %lu.%02lu\n",
- loops_per_jiffy / (500000/HZ),
- (loops_per_jiffy / (5000/HZ)) % 100);
-#endif
-
#ifdef CONFIG_SMP
seq_printf(m, "\n");
#endif
^ permalink raw reply
* RE: cpm_dpalloc
From: Li Yang-r58472 @ 2006-07-31 8:56 UTC (permalink / raw)
To: GSM909, linuxppc-embedded
In-Reply-To: <20060731085022.138740@gmx.net>
There is a bug in rheap for alignment. The patch is still hanging =
around. =20
Search rheap and alignment on the linuxppc-dev list for patch previously =
posted.
Best Regards,
Leo
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On =
Behalf Of
> GSM909@gmx.de
> Sent: Monday, July 31, 2006 4:50 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: cpm_dpalloc
>=20
> Hi All
>=20
> I have a MPC82xx Processor from Freescale with Linux 2.6.14 ( Can=B4t =
chance to an
> new version).
>=20
> My Problem is that I want to allocate a 64byte of memory in the dual =
ported ram
> with an alignment of 64bytes. (Needed for SPI Parameter Ram)
>=20
> the funktion cpm_dpalloc(64,64) returned 0x220 but that are not in a =
64 byte
> alignment.
>=20
> Regards
> Fred
> --
>=20
>=20
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> Ideal f=FCr Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* cpm_dpalloc
From: GSM909 @ 2006-07-31 8:50 UTC (permalink / raw)
To: linuxppc-embedded
Hi All
I have a MPC82xx Processor from Freescale with Linux 2.6.14 ( Can´t chance to an new version).
My Problem is that I want to allocate a 64byte of memory in the dual ported ram with an alignment of 64bytes. (Needed for SPI Parameter Ram)
the funktion cpm_dpalloc(64,64) returned 0x220 but that are not in a 64 byte alignment.
Regards
Fred
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* RE: Host USB on MPC8247
From: Li Yang-r58472 @ 2006-07-31 8:23 UTC (permalink / raw)
To: Uros Borovsak, linuxppc-embedded; +Cc: linux-usb-devel
In-Reply-To: <44CDBBDD.6000401@razvoj-verbic.si>
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On
Behalf Of
> Uros Borovsak
> Sent: Monday, July 31, 2006 4:14 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Host USB on MPC8247
>=20
> Thanks for reply,
>=20
> I made a mistake while typing the message.
>=20
> In reality I was asking how difficult would it be to port USB part of
> kernel from 2.6.10 to 2.6.13, but I mixed kernel version's when
typing.
USB subsystem is relatively stand-alone. So, try replace the whole
drivers/usb/ directory and update usb related header files under
include/.
ps: the question is off-topic on powerpc list.
>=20
> Mike Rapoport wrote:
> > Uros Borovsak wrote:
> >
> >
> >> Hello,
> >>
> >> Can you at least give me some idea how difficult would it be to
patch
> >> USB part of kernel from 2.6.13 to 2.6.10?
> >>
> >>
> >>
> > As far as I know USB core undergone signifcant changes between
2.6.10
> > and 2.6.13. Still it's hard to tell how difficult would it be to
> > backport USB from 2.6.13 to 2.6.10.
> > Besides, it maybe worth upgrading your kernel instead of backporing
> > USB to 2.6.10.
> >
> >
> Upgrading the whole kernel is not a way to go for me here, becouse
> company is using montavista kernel, and if I upgrade the whole kernel,
I
> would have to port all their patches also.
>=20
> I believe that MontaVista will use higher kernel version some time, so
I
> wouldn't go backporting driver to 2.6.10, but I would prefer to port
USB
> part of kernel from 2.6.10 to 2.6.13.
>=20
> Do you think that is possible and how hard would it be?
>=20
> Best regards
>=20
> Uros
> >> Are changes only in usb part of kernel, or are there also some
> >> changes in other parts of kernel, that I would have to port?
> >>
> >> Thanks,
> >>
> >> Best regards
> >>
> >> Uros
^ permalink raw reply
* Re: Host USB on MPC8247
From: Uros Borovsak @ 2006-07-31 8:14 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <44CDBA3C.2040402@compulab.co.il>
Thanks for reply,
I made a mistake while typing the message.
In reality I was asking how difficult would it be to port USB part of
kernel from 2.6.10 to 2.6.13, but I mixed kernel version's when typing.
Mike Rapoport wrote:
> Uros Borovsak wrote:
>
>
>> Hello,
>>
>> Can you at least give me some idea how difficult would it be to patch
>> USB part of kernel from 2.6.13 to 2.6.10?
>>
>>
>>
> As far as I know USB core undergone signifcant changes between 2.6.10
> and 2.6.13. Still it's hard to tell how difficult would it be to
> backport USB from 2.6.13 to 2.6.10.
> Besides, it maybe worth upgrading your kernel instead of backporing
> USB to 2.6.10.
>
>
Upgrading the whole kernel is not a way to go for me here, becouse
company is using montavista kernel, and if I upgrade the whole kernel, I
would have to port all their patches also.
I believe that MontaVista will use higher kernel version some time, so I
wouldn't go backporting driver to 2.6.10, but I would prefer to port USB
part of kernel from 2.6.10 to 2.6.13.
Do you think that is possible and how hard would it be?
Best regards
Uros
>> Are changes only in usb part of kernel, or are there also some
>> changes in other parts of kernel, that I would have to port?
>>
>> Thanks,
>>
>> Best regards
>>
>> Uros
>>
>>
>>
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>>
>>
>>
>
>
^ permalink raw reply
* Compilation error in fsl_soc.c
From: Demke Torsten-atd012 @ 2006-07-31 7:37 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
with a recent versions from Paulus merge-tree the compilation
of MPC85xx CDS failed with following output:
...
LD arch/powerpc/lib/built-in.o
CC arch/powerpc/sysdev/mpic.o
CC arch/powerpc/sysdev/indirect_pci.o
AS arch/powerpc/sysdev/dcr.o
CC arch/powerpc/sysdev/fsl_soc.o
arch/powerpc/sysdev/fsl_soc.c: In function 'gfar_mdio_of_init':
arch/powerpc/sysdev/fsl_soc.c:88: error: 'struct device_node' has no
member name d 'n_intrs'
arch/powerpc/sysdev/fsl_soc.c:91: error: 'struct device_node' has no
member name d 'intrs'
arch/powerpc/sysdev/fsl_soc.c: In function 'gfar_of_init':
arch/powerpc/sysdev/fsl_soc.c:142: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:143: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:153: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:154: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:158: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:159: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:165: error: 'struct device_node' has no
member nam ed 'n_intrs'
arch/powerpc/sysdev/fsl_soc.c: In function 'fsl_i2c_of_init':
arch/powerpc/sysdev/fsl_soc.c:254: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:255: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c: In function 'fsl_usb_of_init':
arch/powerpc/sysdev/fsl_soc.c:391: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:392: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:440: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:441: error: 'struct device_node' has no
member nam ed 'intrs'
make[1]: *** [arch/powerpc/sysdev/fsl_soc.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2
Did I missed a patch?
Regards,
Torsten
^ permalink raw reply
* Re: Host USB on MPC8247
From: Mike Rapoport @ 2006-07-31 8:07 UTC (permalink / raw)
To: Uros Borovsak; +Cc: linuxppc-embedded
In-Reply-To: <44C9F398.4060109@razvoj-verbic.si>
Uros Borovsak wrote:
>Hello,
>
>Can you at least give me some idea how difficult would it be to patch
>USB part of kernel from 2.6.13 to 2.6.10?
>
>
As far as I know USB core undergone signifcant changes between 2.6.10
and 2.6.13. Still it's hard to tell how difficult would it be to
backport USB from 2.6.13 to 2.6.10.
Besides, it maybe worth upgrading your kernel instead of backporing USB
to 2.6.10.
>Are changes only in usb part of kernel, or are there also some changes
>in other parts of kernel, that I would have to port?
>
>Thanks,
>
>Best regards
>
>Uros
>
>
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
>
--
Sincerely yours,
Mike Rapoport
^ permalink raw reply
* Re: [RFC] I2C-MPC: Fix up error handling
From: Jean Delvare @ 2006-07-31 6:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Munaut, Sylvain
In-Reply-To: <A18434C2-2C6F-4052-B3F3-AE9D2CE38BE3@kernel.crashing.org>
> > Quoting myself:
> > > Could anyone please comment on this i2c-mpc patch, and give it some
> > > testing on different systems? I'm fine with the error propagation
> > > fixes, but less fine with the random resets being added, and rather
> > > unhappy with the "retry once more just in case" thing, which I think,
> > > if really needed, should instead be implemented using the standard
> > > i2c_adapter.retries mechanism.
> >
> > Can anyone please comment on this patch? Andrew Morton keeps
> > forwarding it to me, but I don't think I can accept it as is (see
> > my complaints above.)
>
> If I find some time, let me split out the error propagation so we can
> get that fix up stream. The other code was to handle a buggy device
> that was connected in one system I was working on.
Sounds like a good plan, thanks.
--
Jean Delvare
^ permalink raw reply
* Re: USB flashdrive on Motorola MPC5200 (IceCube) board, linux ker nel 2.4.25 (DENX drop)
From: Roman Fietze @ 2006-07-31 5:53 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Furxhi, Orges
In-Reply-To: <162B449665D6D643AD9E1D50FC6F4B14042F1C9A@mdcexc05.na.ops.local>
[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]
Hello,
On Saturday 29 July 2006 00:07, Furxhi, Orges wrote:
> usb.c: USB device not accepting new address=2 (error=-110)
We had that problem on a few of our boards as well.
For the old Icecube exists the possibility to mount two different USB
transceivers, one of them the ISP1107DH, the other one the
P11PAPW. Which one of the two is mounted on your board?
On our own boards we had problems with low speed devices and the
ISP1107, the other transceiver that Freescale used worked
fine. Connecting those low speed devices via a hub worked. Sometimes
it helped to add an additional capacitor to the power lines, but
that's not really a viable solution.
We ended up using a Fairchild USB1T11A, the ISP1107 seemed to have a
problem, we just didn't have luck with them. The Fairchild's are pin
compatible, maybe you just give it a try.
Roman
--
Roman Fietze Telemotive AG Büro Mühlhausen
Breitwiesen 73347 Mühlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: please pull powerpc.git 'merge' branch
From: Paul Mackerras @ 2006-07-31 5:37 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from the "merge" branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
to get the commits listed below.
There is also a set of 5 patches for sound/aoa that need to go in
2.6.18. I'm trying to coordinate with Takashi Iwai about whether he
or I will send you those.
Paul.
arch/powerpc/Kconfig | 2
arch/powerpc/configs/pmac32_defconfig | 112 ++++++++-
arch/powerpc/kernel/head_64.S | 35 +++
arch/powerpc/kernel/legacy_serial.c | 13 +
arch/powerpc/kernel/misc_64.S | 2
arch/powerpc/kernel/prom_init.c | 36 +++
arch/powerpc/kernel/smp.c | 24 +-
arch/powerpc/kernel/udbg_16550.c | 6 -
arch/powerpc/mm/lmb.c | 3
arch/powerpc/platforms/chrp/setup.c | 12 +
arch/powerpc/platforms/maple/setup.c | 17 +
arch/powerpc/platforms/powermac/bootx_init.c | 35 ++-
arch/powerpc/platforms/powermac/cpufreq_64.c | 78 ++++---
arch/powerpc/platforms/pseries/setup.c | 6 -
drivers/ide/Kconfig | 14 -
drivers/macintosh/Kconfig | 11 +
drivers/macintosh/therm_pm72.c | 218 +++++++++++++++++-
drivers/macintosh/therm_pm72.h | 33 +++
drivers/macintosh/via-pmu-led.c | 2
drivers/video/offb.c | 307 ++++++++++++++------------
20 files changed, 703 insertions(+), 263 deletions(-)
Benjamin Herrenschmidt:
[POWERPC] Workaround Pegasos incorrect ISA "ranges"
[POWERPC] Fix 32 bits warning in prom_init.c
[POWERPC] Fix non-MPIC CHRPs with CONFIG_SMP set
[POWERPC] Fix default clock for udbg_16550
[POWERPC] Fix legacy_serial.c error handling on 32 bits
[POWERPC] More offb/bootx fixes
[POWERPC] Xserve G5 thermal control fixes
[POWERPC] Add cpufreq support for Xserve G5
Danny van Dyk:
[POWERPC] PMAC_APM_EMU should depend on ADB_PMU
Geoff Levand:
[POWERPC] Minor comment fix for misc_64.S
Jake Moilanen:
[POWERPC] Use H_CEDE on non-SMT
Johannes Berg:
[POWERPC] fix up front-LED Kconfig
Michael Ellerman:
[POWERPC] Fix mem= handling when the memory limit is > RMO size
Olaf Hering:
[POWERPC] force 64bit mode in fwnmi handlers to workaround firmware bugs
Segher Boessenkool:
[POWERPC] Fix new interrupt code (MPIC endianness)
[POWERPC] Fix new interrupt code (MPIC detection)
^ permalink raw reply
* how to download the ppclinux
From: hpchen @ 2006-07-31 3:47 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 223 bytes --]
hi,all
I've just begun to run linux on MPC8245.
I'll use a graphic card which interface with mpc8245.
Can anyone tell me where i can download the ppclinux
which also contains the driver for graphics card
3X!
[-- Attachment #2: Type: text/html, Size: 3362 bytes --]
^ permalink raw reply
* Re: [PATCH] Add rtas_set_indicator_fast() for RTAS call without extended delay
From: Nathan Lynch @ 2006-07-31 4:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: External List, Milton Miller
In-Reply-To: <17613.33093.767856.432771@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Haren Myneni writes:
>
> > + WARN_ON(rc == -2 || (rc >= 9900 && rc <= 9905));
>
> This worries me... do we know for sure that RTAS will never return a
> busy code? If it could possibly return a busy code, and we can't
> sleep, then we should spin doing the call again and again until it
> works, I think.
The PAPR marks certain RTAS calls as "fast", meaning they must not
return any kind of busy status. Manipulating the GIQ (set-indicator
with token 9005) is defined as "fast".
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Michael Ellerman @ 2006-07-31 4:33 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1154024834.29826.240.camel@goblue>
[-- Attachment #1: Type: text/plain, Size: 3003 bytes --]
On Thu, 2006-07-27 at 13:27 -0500, Jake Moilanen wrote:
> Rebased with the IRQ layer rewrite. The code is not deallocating the
> vectors on a pci_disable_msi(). This is to work around a firmware
> vector release bug. Plus it is really not needed, as
> irq_create_mapping() just returns mappings to irqs that it knows of.
>
> Additionally, the patch includes the client architecture bit for MSI,
> and correctly identifying that MSI is edge triggered.
Hey Jake, just a few niggles below ..
> Index: 2.6-msi/drivers/pci/msi-rtas.c
> ===================================================================
> --- /dev/null
> +++ 2.6-msi/drivers/pci/msi-rtas.c
> @@ -0,0 +1,111 @@
> +/*
> + * Jake Moilanen <moilanen@austin.ibm.com>
> + * Copyright (C) 2006 IBM
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; version 2 of the
> + * License.
> + *
> + */
> +
> +#include <linux/pci.h>
> +#include <linux/irq.h>
> +#include <asm/rtas.h>
> +#include <asm/hw_irq.h>
> +#include <asm/ppc-pci.h>
> +
> +int rtas_enable_msi(struct pci_dev* pdev)
> +{
> + static int seq_num = 1;
Do we really want seq_num to be static? By my reading of PAPR we only
need to maintain the seq number across calls that return -2/990x, and we
handle that all inside this function. If it does need to be unique for
_all_ calls, then I don't see how seq_num being static is going to work,
a different cpu could stomp on the seq_num value between calls, which
presumably would make firmware mad.
> + int i;
> + int rc;
> + int query_token = rtas_token("ibm,query-interrupt-source-number");
> + int devfn;
> + int busno;
> + u32 *reg;
> + int reglen;
> + int ret[3];
You only need ret[2] I think, the first return value (status) is handled
inside rtas_call for you.
> + int dummy;
> + int n_intr;
> + int last_virq = NO_IRQ;
> + int virq;
> + unsigned int addr;
> + unsigned long buid = -1;
No need to set buid to -1 as you unconditionally assign to it later.
> + struct device_node * dn;
> +
> + dn = pci_device_to_OF_node(pdev);
> +
> + if (!of_find_property(dn, "ibm,req#msi", &dummy))
> + return -ENOENT;
You don't need dummy, just pass NULL.
> +
> + reg = (u32 *) get_property(dn, "reg", ®len);
> + if (reg == NULL || reglen < 20)
> + return -ENXIO;
> +
> + devfn = (reg[0] >> 8) & 0xff;
> + busno = (reg[0] >> 16) & 0xff;
> +
> + buid = get_phb_buid(dn->parent);
> + addr = (busno << 16) | (devfn << 8);
Why do we need to read the reg here, can't we just use the existing
fields? ie:
addr = (pdev->bus->number << 16) | (pdev->devfn << 8);
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Paul Mackerras @ 2006-07-31 4:07 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev
In-Reply-To: <1154024834.29826.240.camel@goblue>
Jake Moilanen writes:
> -msiobj-y := msi.o msi-apic.o
> -msiobj-$(CONFIG_IA64_GENERIC) += msi-altix.o
> -msiobj-$(CONFIG_IA64_SGI_SN2) += msi-altix.o
> +msiobj-$(CONFIG_X86) += msi.o msi-apic.o
> +msiobj-$(CONFIG_IA64) += msi.o msi-apic.o
> +msiobj-$(CONFIG_IA64_GENERIC) += msi.o msi-apic.o msi-altix.o
> +msiobj-$(CONFIG_IA64_SGI_SN2) += msi.o msi-apic.o msi-altix.o
Doesn't this mean that ia64 configs might now get msi.o and msi-apic.o
listed twice? Why did you need to change the
msiobj-$(CONFIG_IA64_GENERIC) and msiobj-$(CONFIG_IA64_SGI_SN2) lines
at all?
Paul.
^ permalink raw reply
* Re: [PATCH] Add rtas_set_indicator_fast() for RTAS call without extended delay
From: Paul Mackerras @ 2006-07-31 4:04 UTC (permalink / raw)
To: Haren Myneni; +Cc: External List, Nathan Lynch, Milton Miller
In-Reply-To: <44C9301C.7080300@us.ibm.com>
Haren Myneni writes:
> + WARN_ON(rc == -2 || (rc >= 9900 && rc <= 9905));
This worries me... do we know for sure that RTAS will never return a
busy code? If it could possibly return a busy code, and we can't
sleep, then we should spin doing the call again and again until it
works, I think.
Paul.
^ permalink raw reply
* Help for IDMA/DMA PCI on MPC8250
From: jimmy liu @ 2006-07-30 22:39 UTC (permalink / raw)
To: embedded linuxppc
Did anyone use IDMA/DMA for PCI transactions
on MPC8250? Where I can find the sample driver code?
Thanks.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [RFC] I2C-MPC: Fix up error handling
From: Kumar Gala @ 2006-07-30 16:23 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, Sylvain Munaut
In-Reply-To: <20060730131440.1d4fcbe6.khali@linux-fr.org>
On Jul 30, 2006, at 6:14 AM, Jean Delvare wrote:
> Quoting myself:
>> Could anyone please comment on this i2c-mpc patch, and give it some
>> testing on different systems? I'm fine with the error propagation
>> fixes, but less fine with the random resets being added, and rather
>> unhappy with the "retry once more just in case" thing, which I think,
>> if really needed, should instead be implemented using the standard
>> i2c_adapter.retries mechanism.
>
> Can anyone please comment on this patch? Andrew Morton keeps
> forwarding
> it to me, but I don't think I can accept it as is (see my complaints
> above.)
If I find some time, let me split out the error propagation so we can
get that fix up stream. The other code was to handle a buggy device
that was connected in one system I was working on.
- kumar
>> From: Kumar Gala <galak@kernel.crashing.org>
>>
>> * If we have an Unfinished (MCF) or Arbitration Lost (MAL) error and
>> the bus is still busy reset the controller. This prevents the
>> controller from getting in a hung state for transactions for other
>> devices.
>>
>> * Fixed up propogating the errors from i2c_wait.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> Cc: Jean Delvare <khali@linux-fr.org>
>> Cc: Greg KH <greg@kroah.com>
>> Signed-off-by: Andrew Morton <akpm@osdl.org>
>> ---
>>
>> drivers/i2c/busses/i2c-mpc.c | 43 ++++++++++++++++++++++
>> +----------
>> 1 file changed, 31 insertions(+), 12 deletions(-)
>>
>> diff -puN drivers/i2c/busses/i2c-mpc.c~i2c-mpc-fix-up-error-
>> handling drivers/i2c/busses/i2c-mpc.c
>> --- devel/drivers/i2c/busses/i2c-mpc.c~i2c-mpc-fix-up-error-
>> handling 2006-06-01 20:22:55.000000000 -0700
>> +++ devel-akpm/drivers/i2c/busses/i2c-mpc.c 2006-06-01
>> 20:22:55.000000000 -0700
>> @@ -115,11 +115,20 @@ static int i2c_wait(struct mpc_i2c *i2c,
>>
>> if (!(x & CSR_MCF)) {
>> pr_debug("I2C: unfinished\n");
>> +
>> + /* reset the controller if the bus is still busy */
>> + if (x & CSR_MBB)
>> + writeccr(i2c, 0);
>> +
>> return -EIO;
>> }
>>
>> if (x & CSR_MAL) {
>> pr_debug("I2C: MAL\n");
>> +
>> + /* reset the controller if the bus is still busy */
>> + if (x & CSR_MBB)
>> + writeccr(i2c, 0);
>> return -EIO;
>> }
>>
>> @@ -160,7 +169,7 @@ static void mpc_i2c_stop(struct mpc_i2c
>> static int mpc_write(struct mpc_i2c *i2c, int target,
>> const u8 * data, int length, int restart)
>> {
>> - int i;
>> + int i, ret;
>> unsigned timeout = i2c->adap.timeout;
>> u32 flags = restart ? CCR_RSTA : 0;
>>
>> @@ -172,15 +181,17 @@ static int mpc_write(struct mpc_i2c *i2c
>> /* Write target byte */
>> writeb((target << 1), i2c->base + MPC_I2C_DR);
>>
>> - if (i2c_wait(i2c, timeout, 1) < 0)
>> - return -1;
>> + ret = i2c_wait(i2c, timeout, 1);
>> + if (ret < 0)
>> + return ret;
>>
>> for (i = 0; i < length; i++) {
>> /* Write data byte */
>> writeb(data[i], i2c->base + MPC_I2C_DR);
>>
>> - if (i2c_wait(i2c, timeout, 1) < 0)
>> - return -1;
>> + ret = i2c_wait(i2c, timeout, 1);
>> + if (ret < 0)
>> + return ret;
>> }
>>
>> return 0;
>> @@ -190,7 +201,7 @@ static int mpc_read(struct mpc_i2c *i2c,
>> u8 * data, int length, int restart)
>> {
>> unsigned timeout = i2c->adap.timeout;
>> - int i;
>> + int i, ret;
>> u32 flags = restart ? CCR_RSTA : 0;
>>
>> /* Start with MEN */
>> @@ -201,8 +212,9 @@ static int mpc_read(struct mpc_i2c *i2c,
>> /* Write target address byte - this time with the read flag set */
>> writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
>>
>> - if (i2c_wait(i2c, timeout, 1) < 0)
>> - return -1;
>> + ret = i2c_wait(i2c, timeout, 1);
>> + if (ret < 0)
>> + return ret;
>>
>> if (length) {
>> if (length == 1)
>> @@ -214,8 +226,9 @@ static int mpc_read(struct mpc_i2c *i2c,
>> }
>>
>> for (i = 0; i < length; i++) {
>> - if (i2c_wait(i2c, timeout, 0) < 0)
>> - return -1;
>> + ret = i2c_wait(i2c, timeout, 0);
>> + if (ret < 0)
>> + return ret;
>>
>> /* Generate txack on next to last byte */
>> if (i == length - 2)
>> @@ -246,8 +259,13 @@ static int mpc_xfer(struct i2c_adapter *
>> return -EINTR;
>> }
>> if (time_after(jiffies, orig_jiffies + HZ)) {
>> - pr_debug("I2C: timeout\n");
>> - return -EIO;
>> + writeccr(i2c, 0);
>> +
>> + /* try one more time before we error */
>> + if (readb(i2c->base + MPC_I2C_SR) & CSR_MBB) {
>> + pr_debug("I2C: timeout\n");
>> + return -EIO;
>> + }
>> }
>> schedule();
>> }
>> @@ -325,6 +343,7 @@ static int fsl_i2c_probe(struct platform
>> goto fail_irq;
>> }
>>
>> + writeccr(i2c, 0);
>> mpc_i2c_setclock(i2c);
>> platform_set_drvdata(pdev, i2c);
>
> --
> Jean Delvare
^ permalink raw reply
* Re: [RFC] I2C-MPC: Fix up error handling
From: Jean Delvare @ 2006-07-30 11:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sylvain Munaut
In-Reply-To: <20060609095421.7157dc53.khali@linux-fr.org>
Quoting myself:
> Could anyone please comment on this i2c-mpc patch, and give it some
> testing on different systems? I'm fine with the error propagation
> fixes, but less fine with the random resets being added, and rather
> unhappy with the "retry once more just in case" thing, which I think,
> if really needed, should instead be implemented using the standard
> i2c_adapter.retries mechanism.
Can anyone please comment on this patch? Andrew Morton keeps forwarding
it to me, but I don't think I can accept it as is (see my complaints
above.)
> From: Kumar Gala <galak@kernel.crashing.org>
>
> * If we have an Unfinished (MCF) or Arbitration Lost (MAL) error and
> the bus is still busy reset the controller. This prevents the
> controller from getting in a hung state for transactions for other
> devices.
>
> * Fixed up propogating the errors from i2c_wait.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> Cc: Jean Delvare <khali@linux-fr.org>
> Cc: Greg KH <greg@kroah.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
>
> drivers/i2c/busses/i2c-mpc.c | 43 +++++++++++++++++++++++----------
> 1 file changed, 31 insertions(+), 12 deletions(-)
>
> diff -puN drivers/i2c/busses/i2c-mpc.c~i2c-mpc-fix-up-error-handling drivers/i2c/busses/i2c-mpc.c
> --- devel/drivers/i2c/busses/i2c-mpc.c~i2c-mpc-fix-up-error-handling 2006-06-01 20:22:55.000000000 -0700
> +++ devel-akpm/drivers/i2c/busses/i2c-mpc.c 2006-06-01 20:22:55.000000000 -0700
> @@ -115,11 +115,20 @@ static int i2c_wait(struct mpc_i2c *i2c,
>
> if (!(x & CSR_MCF)) {
> pr_debug("I2C: unfinished\n");
> +
> + /* reset the controller if the bus is still busy */
> + if (x & CSR_MBB)
> + writeccr(i2c, 0);
> +
> return -EIO;
> }
>
> if (x & CSR_MAL) {
> pr_debug("I2C: MAL\n");
> +
> + /* reset the controller if the bus is still busy */
> + if (x & CSR_MBB)
> + writeccr(i2c, 0);
> return -EIO;
> }
>
> @@ -160,7 +169,7 @@ static void mpc_i2c_stop(struct mpc_i2c
> static int mpc_write(struct mpc_i2c *i2c, int target,
> const u8 * data, int length, int restart)
> {
> - int i;
> + int i, ret;
> unsigned timeout = i2c->adap.timeout;
> u32 flags = restart ? CCR_RSTA : 0;
>
> @@ -172,15 +181,17 @@ static int mpc_write(struct mpc_i2c *i2c
> /* Write target byte */
> writeb((target << 1), i2c->base + MPC_I2C_DR);
>
> - if (i2c_wait(i2c, timeout, 1) < 0)
> - return -1;
> + ret = i2c_wait(i2c, timeout, 1);
> + if (ret < 0)
> + return ret;
>
> for (i = 0; i < length; i++) {
> /* Write data byte */
> writeb(data[i], i2c->base + MPC_I2C_DR);
>
> - if (i2c_wait(i2c, timeout, 1) < 0)
> - return -1;
> + ret = i2c_wait(i2c, timeout, 1);
> + if (ret < 0)
> + return ret;
> }
>
> return 0;
> @@ -190,7 +201,7 @@ static int mpc_read(struct mpc_i2c *i2c,
> u8 * data, int length, int restart)
> {
> unsigned timeout = i2c->adap.timeout;
> - int i;
> + int i, ret;
> u32 flags = restart ? CCR_RSTA : 0;
>
> /* Start with MEN */
> @@ -201,8 +212,9 @@ static int mpc_read(struct mpc_i2c *i2c,
> /* Write target address byte - this time with the read flag set */
> writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
>
> - if (i2c_wait(i2c, timeout, 1) < 0)
> - return -1;
> + ret = i2c_wait(i2c, timeout, 1);
> + if (ret < 0)
> + return ret;
>
> if (length) {
> if (length == 1)
> @@ -214,8 +226,9 @@ static int mpc_read(struct mpc_i2c *i2c,
> }
>
> for (i = 0; i < length; i++) {
> - if (i2c_wait(i2c, timeout, 0) < 0)
> - return -1;
> + ret = i2c_wait(i2c, timeout, 0);
> + if (ret < 0)
> + return ret;
>
> /* Generate txack on next to last byte */
> if (i == length - 2)
> @@ -246,8 +259,13 @@ static int mpc_xfer(struct i2c_adapter *
> return -EINTR;
> }
> if (time_after(jiffies, orig_jiffies + HZ)) {
> - pr_debug("I2C: timeout\n");
> - return -EIO;
> + writeccr(i2c, 0);
> +
> + /* try one more time before we error */
> + if (readb(i2c->base + MPC_I2C_SR) & CSR_MBB) {
> + pr_debug("I2C: timeout\n");
> + return -EIO;
> + }
> }
> schedule();
> }
> @@ -325,6 +343,7 @@ static int fsl_i2c_probe(struct platform
> goto fail_irq;
> }
>
> + writeccr(i2c, 0);
> mpc_i2c_setclock(i2c);
> platform_set_drvdata(pdev, i2c);
--
Jean Delvare
^ permalink raw reply
* Re: Xilinx hard TEMAC
From: David H. Lynch Jr. @ 2006-07-30 1:08 UTC (permalink / raw)
To: Rick Moleres; +Cc: linuxppc-embedded
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C029DC9E5@XCO-EXCHVS1.xlnx.xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 3696 bytes --]
Rick Moleres wrote:
> That is the correct distinction between "soft" and "hard". Just know
> that in this case the "soft" TEMAC (whether LL TEMAC or PLB TEMAC) uses
> the "hard" TEMAC, and the "hard" TEMAC by itself is not that useful.
>
First, thanks, your remarks have been enormously helpful.
I have successfully put together a Driver for the TEMAC currently
used in the Pico E-12.
I am still having some difficulty corresponding this TEMAC
implimentation to any of Xilinx's documentation.
It is Exactly the TEMAC supported by the Xilinx uCOSII Treck Web
Server application.
It seems to be extremely minimal. Basically a DCR interface for most
things that closely matches the GSRD documents.
and TX and RX FIFO's that I can't seem to find documented anywhere,
but I have working based on the Treck WebServer code.
I am have two remaining problems and then I am done.
The first is I am currently doing polled I/O. The transmits
happen as they are requested and the receives are picked up ona a timer
interrupt.
But I am dropping about 50% or more of the receives. I will work
that out myself eventually.
The second is that this driver will serve as the basis for a
driver in other Pico supported OS's. Some of which have no means of
doing Polled Receives.
And I can not get interrupts working. Since my hardware does nto
match anything perfectly - except that Treck Webserver application and
that does not do interrupts.
I am reading all the Xilinx TEMAC Documents and the GSRD documents
reference an IRENABLE register and an IRSTATUS register, I cobbled
something together
assuming that they were access much as the other DCR registers in
that block and I assumed the bits in IRSTATUS and IRENABLE matched the
definitions of those
in larger TEMAC implimentations. It appeared after I enabled TX and
RX complete interrupts that when I have received data available the
IRSTATUS register has the
Bit set for an Rx interrupt. All fine - except that no interrupt
actually occurs.
I can force interrupts from the PHY using the same IRQ so the IRQ is
connected correctly and programmed correctly. Other TEMAC
implimentations seem to have a GIE - Global Interrupt enable
Bit, but I do not have a clue where to look here. What I could get
out of the Xilinx Webset GSRD seems to be a Linux driver that uses the
DMA unit and that generates its own interrupts.
I don't think I have the DMA in my bit image.
Anyway any clues as to where I can find some useful docs on
Interrupt handling for the LL_TEMAC that is used by the uCOSII WebServer
application ?
> Thereis a Linux driver for the LL_TEMAC that comes with GSRD, but my
>
> group's efforts go toward the PLB_TEMAC as that is the EDK IP we want to
>
> promote and whose drivers we'd like to see in kernel.org.
>
> You should be able to go to http://www.xilinx.com/gsrd to get the GSRD
> design, and inside of that design somewhere you'll find a Linux 2.4
> driver for the LL TEMAC.
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 5207 bytes --]
^ permalink raw reply
* RE: USB flashdrive on Motorola MPC5200 (IceCube) board, linux ker nel 2.4.25 (DENX drop)
From: Furxhi, Orges @ 2006-07-28 22:07 UTC (permalink / raw)
To: Furxhi, Orges, 'Wolfgang Denk'
Cc: 'linuxppc-embedded@ozlabs.org'
>Which defconfig file should I use?
>I just tried the icecube_5200_CoralP_defconfig file but now the board isnot
>booting; it hangs right after this message:
I figured out my mistake as far as booting the kernel, I did not have the
right bootm argument.
Even with the I figured out my mistake as far as booting the kernel, I did
not have the correct bootargs.
Even with the icecube_5200_CoralP_defconfig +scsi support, and usb
mas-storage enabled, I get the same message when I plug in the usb stick.
usb.c: USB device not accepting new address=2 (error=-110)
Orges
^ permalink raw reply
* RE: USB flashdrive on Motorola MPC5200 (IceCube) board, linux ker nel 2.4.25 (DENX drop)
From: Furxhi, Orges @ 2006-07-28 21:57 UTC (permalink / raw)
To: 'Wolfgang Denk', Furxhi, Orges; +Cc: linuxppc-embedded
Mr, Denk
>But if you tested so many devices, and none of them is working, then
>this is probably an indication of another problem.
It might be, but I can not figure out what it is. I am hoping it is just a
kernel configuration mater.
>Do you have a chance to try a different board? Did you ever
>succesfully use *any* USB device on your board? Maybe there is a
>hardware problem on your system.
I just have one icecube board (Lite5200 Ver 2.0), and I have 4 of our own
custom boards designed after the icecube. Right now I am testing on the
icecube board. I tried our boards but usb as mass storage is not working
there either.
>Ummm... stupid question: is the green LED behind the USB connector on
>your board on or off?
There is one and it was off, I shorted out R164 and the led came on. Our
custom board takes care of this as well
Which defconfig file should I use?
I just tried the icecube_5200_CoralP_defconfig file but now the board is not
booting; it hangs right after this message:
"Uncompressing Kernel Image ... OK"
Thanks,
Orges
PS.
>Argh... your message is very difficult to read, as there is no difference
>between your text and mine.
I assumed that outlook would do it automatically, but apparently it did not,
sorry about that.
>Also, please don't send separate mesages to the original poster and the
>mailing list; use Cc: instead.
I hit "reply" instead of "reply all" by mistake; sorry about that too, I
will not happen again.
^ permalink raw reply
* Re: USB flashdrive on Motorola MPC5200 (IceCube) board, linux ker nel 2.4.25 (DENX drop)
From: Wolfgang Denk @ 2006-07-28 21:31 UTC (permalink / raw)
To: Furxhi, Orges; +Cc: linuxppc-embedded
In-Reply-To: <162B449665D6D643AD9E1D50FC6F4B14042F1C97@mdcexc05.na.ops.local>
Dear Orges,
in message <162B449665D6D643AD9E1D50FC6F4B14042F1C97@mdcexc05.na.ops.local> you wrote:
>
> Are you just trying one specific type opf USB device, or does this
> happen with several 5 or more) different devices?
>
> We tried 6 different USB flash drives:
Argh... your message is very difficult to read, as there is no
difference between your text and mine. Please see
http://www.netmeister.org/news/learn2quote.html
Also, please don't send separate mesages to the original poster and
the mailing list; use Cc: instead.
> Are there any flashdrives that are known to always work?
I don't dare to say "always" ;-)
But if you tested so many devices, and none of them is working, then
this is probably an indication of another problem.
Do you have a chance to try a different board? Did you ever
succesfully use *any* USB device on your board? Maybe there is a
hardware problem on your system.
Ummm... stupid question: is the green LED behind the USB connector on
your board on or off?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Where there's no emotion, there's no motive for violence.
-- Spock, "Dagger of the Mind", stardate 2715.1
^ permalink raw reply
* RE: USB flashdrive on Motorola MPC5200 (IceCube) board, linux ker nel 2.4.25 (DENX drop)
From: Furxhi, Orges @ 2006-07-28 21:09 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
[-- Attachment #1: Type: text/plain, Size: 2256 bytes --]
-----Original Message-----
From: Furxhi, Orges
Sent: Friday, July 28, 2006 4:03 PM
To: 'Wolfgang Denk'
Subject: RE: USB flashdrive on Motorola MPC5200 (IceCube) board, linux
kernel 2.4.25 (DENX drop)
-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Friday, July 28, 2006 3:08 PM
To: Furxhi, Orges
Cc: 'Igor Luri'; linuxppc-embedded@ozlabs.org
Subject: Re: USB flashdrive on Motorola MPC5200 (IceCube) board, linux
kernel 2.4.25 (DENX drop)
Dear Orges,
in message <162B449665D6D643AD9E1D50FC6F4B14042F1C93@mdcexc05.na.ops.local>
you wrote:
>
> I have a LITE5200 Version 2.0 board and I have loaded the latest DENX drop
> of the 2.4 kernel on it. When I plug in the usb flash drive I get the
> following message:
>
> Usb.c: USB device not accepting new address=4 (error=-110)
> Usb.c: USB device not accepting new address=5 (error=-110)
>
> I must be doing something wrong, and I do not know what it is.
Are you just trying one specific type opf USB device, or does this
happen with several 5 or more) different devices?
We tried 6 different USB flash drives:
GE intelligent stick 2.0 (256MB)
PNY
SanDisk Cruzer Micro (256MB)
Version G (512MB)
Memorex traveldrive mini (512MB)
Unknown brand (64MB)
Are there any flashdrives that are known to always work?
> You said that you had the same board and kernel and that your USB as mass
> storage was working. Could you please send me your kernel's .config file
so
> that I can compare it with mine?
You can just use the default configuration as provided with the
kernel tree. Make sure to use a current kernel (top of tree in git
repo).
We have the latest 2.4 drop from the git repo. Which of the defconfig files
should we use? None of them had usb storage enabled (icecube board).
Thanks a lot,
Orges
And keep in mind that many USB devices are simply not strctly
standard conforming. Some will work, others won't.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The biggest difference between time and space is that you can't reuse
time. - Merrick Furst
[-- Attachment #2: Type: application/ms-tnef, Size: 3617 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox