Robin,
Could you provide some more details of your problem with dma_alloc_init
for the 8xx. I posted a few days back on Saturday about problems I was
having getting an RPXLiteDW (based on the 823) to work with a late
2.6.xx kernel. I had traced the problem down (working without a probe)
to p
Greetings
Currently I have a MPC885 based board running at 50MHz. I want USB host
working at full speed with internal clock. Assuming I need to change the
General System Clock Frequency (GCLK2) to 48MHz, I got this calculation with
input frequency of 10MHz from an u-boot script.
pdf mfi mfn mfd s
Greetings
Currently I have a MPC885 based board running at 50MHz. I want USB
host working at full speed with internal clock. Assuming I need to
change the General System Clock Frequency (GCLK2) to 48MHz, I got this
calculation with input frequency of 10MHz from an u-boot script.
pdf mfi mfn mfd s
OK - I give up - whats the name of the device?
I've tried eth0, fsl-cpm-fec0 (and other combinations) with a
commandline of the form:
ip=172.25.206.113:172.25.140.15::255.255.0.0:unset:fsl-cpm-fec0:off \
panic=1 console=ttyCPM0
and I get the following errors:
[ 37.249708] TCP bic register
Roland Dreier wrote:
> Is this 44x work at the point where having more people would help? I
> have a 440SPe eval board that I'd like to get going with
> arch/powerpc. I could work on PCI Express or something like that...
>
> On the other hand, I'm happy to wait and work on other stuff...
>
> - R
Robin Gilks wrote:
> Greetings
>
> Having (sort of) mastered the bdi2000, I'm trying to bring up a 8xx card
> thats been debugged and working with a 2.4 kernel for the last 3 years
> but is failing miserably on a 2.6.18 kernel.
>
> My initial problems in dma_alloc_init I seem to have fixed by mov
Any one who has any experience when using IDMA on mpc82xx?
Currently, the status what I have got is, memory-to-memory mode, both Data bus
had been set to 60x-bus, which means DDTB and SDTB are working on 60x-bus. if set DMA_WRAP in DCM as 64-byte, SS_MAX,STS and DTS in
(IDMA Parameter RAM)
Any one who has any experience when using IDMA on mpc82xx? Currently, the status what I have got is, memory-to-memory mode, both Data bus had been set to 60x-bus,which means DDTB and SDTB are working on 60x-bus. if set DMA_WRAP in DCM as 64-byte, SS_MAX,STS and DTS in (IDMA Parameter RAM) all to 32
Greetings
Having (sort of) mastered the bdi2000, I'm trying to bring up a 8xx card
thats been debugged and working with a 2.4 kernel for the last 3 years
but is failing miserably on a 2.6.18 kernel.
My initial problems in dma_alloc_init I seem to have fixed by moving
CONFIG_CONSISTENT_START to 0x
Hi,It is working now. Thanks for the help. I am just curious that linux kernel does not know 1 interface's connection is down and check the other interface to see if it can reaches the destination with other interfaces?
Thanks,l.ngoOn 11/7/06, Andy Fleming <[EMAIL PROTECTED]> wrote:
On Nov 6, 2006,
Hello.
Vitaly Wool wrote:
>>We don't have any actual registers (at least "physmap" doesn't know about
>>them anyway) I think, just a memory range. What registers are you talking
>>about?
> We do have registers there, in query mode. The CFI registers.
Aren't they accessed thru the range
> We don't have any actual registers (at least "physmap" doesn't know about
> them anyway) I think, just a memory range. What registers are you talking
> about?
We do have registers there, in query mode. The CFI registers.
> > Okay, probably we can go you way naming of_device by what it's
Hello.
Vitaly Wool wrote:
>+ - memory_space : Offset and length of the register set for the
>device.
NAK. There's no need to define an extra property where "reg" should be
used.
>>
>>>The register set is actually not there and depends on flash chip type.
>>>So using
В Ср, 08/11/2006 в 00:25 +0300, Sergei Shtylyov пишет:
> Hello.
>
> Vitaly Wool wrote:
> >>>+ - memory_space : Offset and length of the register set for the
> >>>device.
> >>
> >>NAK. There's no need to define an extra property where "reg" should be
> >> used.
>
> > The register set is
Hello.
Vitaly Wool wrote:
>>>+ - memory_space : Offset and length of the register set for the device.
>>
>>NAK. There's no need to define an extra property where "reg" should be
>> used.
> The register set is actually not there and depends on flash chip type.
> So using regs here is misl
> > + - memory_space : Offset and length of the register set for the device.
>
> NAK. There's no need to define an extra property where "reg" should be
> used.
The register set is actually not there and depends on flash chip type.
So using regs here is misleading.
> > +
> > + /*
> > +
Grant Likely wrote:
> On 11/7/06, Sylvain Munaut <[EMAIL PROTECTED]> wrote:
>> Nicolas DET wrote:
>>
>> > This patch add MPC52xx Interrupt controller for ARCH=powerpc.
>> >
>> > It includes the main code in arch/powerpc/sysdev/ ad well as an
>> header file in
>> > include/asm-powerpc.
>> >
>> > The
Hi:
I have PPC440EP board, derived from AMCC Yosemite evaluation board. My
board has Dallas DS1743 NVRAM/RTC chip, connected to local bus (CS2). I
believe, I made necessary initializations for TODC structures (I had to
add CONFIG_GEN_RTC and CONFIG_GEN_RTC_X to my kernel configuration) - I
used ba
On Nov 6, 2006, at 17:51, Luong Ngo wrote:
> Hello,
>
> I am having a problem with the interfaces eth0 and eth1 when
> running 2.6.14 kernel on a board with MPC8343E. The problem I
> encounters is only one of the eth interface is really working. Only
> the one that is configured first, usin
> -Original Message-
> From: gear [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 07, 2006 10:43 AM
> To: Chaffin, Michael
> Subject: Re: Problem connecting a Ti TUSB2077a hub to Cypress
> SL811 host
>
> error -110 is time out.
>
> Is interrupt correctly treatable?
Which interrupt
Hi,
* Matthias Fechner <[EMAIL PROTECTED]> [07-11-06 10:00]:
> You can find what I did on:
> http://wiki.idefix.fechner.net/index.php/Xenomai
ok, problem is solved, everything is documented on my page. Hope that
helps some ppl.
(was a problem with the kernel configuration)
Best regards,
Matthias
Is this 44x work at the point where having more people would help? I
have a 440SPe eval board that I'd like to get going with
arch/powerpc. I could work on PCI Express or something like that...
On the other hand, I'm happy to wait and work on other stuff...
- R.
___
Hello Wolfgang,
* Wolfgang Denk <[EMAIL PROTECTED]> [05-11-06 22:48]:
> I'm not talking about a specific board, but about MPC5200 in general.
ah ok, thx for that hint. Maybe it will change in the future :)
Best regards,
Matthias
--
"Programming today is a race between software engineers stri
Pradeep;I found the process of "uprading" the xapp902 reference design to be troublesome when I removed the GMII loop-back; assuch, I aborted the process and just started from scratch.I am currently debugging my design and have a functional plb_temac but only at 10Mbps speeds.-R. Corley- Origin
Sergei Shtylyov wrote:
> Hello.
>
> Josh Boyer wrote:
>
>
>>>+
>>>+Required properties:
>>>+
>>>+ - device_type : has to be "rom"
>>Why "rom" instead of "NOR"?
> What does "NOR" mean -- logical operator? :-)
> I'd yet agree with "nor-flash", however, the physmap-driven device m
Hello, I was able to get the booting with a ramdisk working and also David B./Peter's uartlite patches to work. Now I see the linux command line without any kernel panics. Thanks to everybody out there. Next step is to get the PLB TEMAC 3.00.a working... Question 1: I have started with
On Nov 7, 2006, at 11:32 AM, Sylvain Munaut wrote:
>
> This patch use of_platform device to probe and install OHCI big
> endian HC.
>
> PS: I did not success to properly inline the file using
> thrunderbird.
>
You really copy the USB maintainers on this. Also,
This patch use of_platform device to probe and install OHCI big
endian HC.
PS: I did not success to properly inline the file using thrunderbird.
>>>
>>> You really copy the USB maintainers on this. Also, why bother with
>>> the Kconfig for USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_
Title: Problem connecting a Ti TUSB2077a hub to Cypress SL811 host
I have a running 2.4.26 Linux kernel (penguinppc.org) on a commercial built embedded PPC405 (Xilinx VirtexII Pro) attached to a Cypress SL811 shown to work, I am now trying to attach a Texas Instruments TUSB2077a Hub chip. Whe
On Nov 6, 2006, at 5:28 PM, Sylvain Munaut wrote:
> Kumar Gala wrote:
>> On Nov 6, 2006, at 4:35 AM, Nicolas DET wrote:
>>
>>
>>> This patch use of_platform device to probe and install OHCI big
>>> endian HC.
>>>
>>> PS: I did not success to properly inline the file using
>>> thrunderbird.
>>>
On 11/7/06, Sylvain Munaut <[EMAIL PROTECTED]> wrote:
> Nicolas DET wrote:
>
> > This patch add MPC52xx Interrupt controller for ARCH=powerpc.
> >
> > It includes the main code in arch/powerpc/sysdev/ ad well as an header file
> > in
> > include/asm-powerpc.
> >
> > The header file has now distinc
On Tue, Nov 07, 2006 at 02:45:22PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2006-11-06 at 19:26 -0800, Roland Dreier wrote:
> > > Also, while it's great to have somebody do this work, I doubt there is
> > > much interest in merging it for arch/ppc...
> >
> > On that subject, what's the la
Hello.
Vitaly Wool wrote:
> inlined below is the patch which adds support for flash device descriptions
> to the OF device tree. It's inspired by and partially borrowed from Sergei's
> patch which can be found at
> http://patchwork.ozlabs.org/linuxppc/patch?id=6526 but arranges things in a
>
On Tue, 7 Nov 2006 15:21:00 +0200 (EET)
Kalle Pokki wrote:
> On Tue, 7 Nov 2006, Vitaly Bordug wrote:
>
> > Well, yes, but are you _sure_ pram_base will be the same across all
> > the 82xx PQ2, that happen to have smc wired to Ethernet?
> >
> > If not I am considering storing it in the platform_d
i've tryed to install u-boot using minicom, but i'm not able to
configure in shell boot params,
using this...
boot device : motfcc
unit number : 0
processor number : 0
host name: motfcc0
inet on ethernet (e) : 192.168.0.4
inet on backplane (b): 192.168.0.4
host
On Tue, 7 Nov 2006, Vitaly Bordug wrote:
> Well, yes, but are you _sure_ pram_base will be the same across all the
> 82xx PQ2, that happen to have smc wired to Ethernet?
>
> If not I am considering storing it in the platform_data is better approach.
Yes, pram_base is always 0x87fc for SMC1 and 0
On Mon, 6 Nov 2006 22:49:49 +0200 (EET)
Kalle Pokki <[EMAIL PROTECTED]> wrote:
> On Mon, 6 Nov 2006, Vitaly Bordug wrote:
>
> >> This patch renames these the two existing resources, and introduces a
> >> new one, "pram_base", which is a pointer to the parameter RAM. The
> >> parameter RAM for SMC
On Tue, 2006-11-07 at 14:45 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2006-11-06 at 19:26 -0800, Roland Dreier wrote:
> > > Also, while it's great to have somebody do this work, I doubt there is
> > > much interest in merging it for arch/ppc...
> >
> > On that subject, what's the latest on
Hello folks,
inlined below is the patch which adds support for flash device descriptions to
the OF device tree. It's inspired by and partially borrowed from Sergei's patch
which can be found at http://patchwork.ozlabs.org/linuxppc/patch?id=6526 but
arranges things in a different way.
It should
Nicolas DET wrote:
> This patch add MPC52xx Interrupt controller for ARCH=powerpc.
>
> It includes the main code in arch/powerpc/sysdev/ ad well as an header file in
> include/asm-powerpc.
>
> The header file has now distinct section for the struct and the IRQ
> mapping/enconding define
>
> Signe
This patch add MPC52xx Interrupt controller for ARCH=powerpc.
It includes the main code in arch/powerpc/sysdev/ ad well as an header file in
include/asm-powerpc.
The header file has now distinct section for the struct and the IRQ
mapping/enconding define
Signed-off-by: Nicolas DET <[EMAIL PROTE
Sylvain Munaut wrote:
+
+ /*
+* Most of ours IRQs will be level low
+* Only external IRQs on some platform may be others
+*/
+ type = IRQ_TYPE_LEVEL_LOW;
I've been wondering : Why LEVEL_LOW ?
Aren't they LEVEL_HIGH ?
(not that it changes much here ...)
I
Hello Wolfgang,
* Wolfgang Grandegger <[EMAIL PROTECTED]> [06-11-06 12:21]:
> unpack it and apply the relevant patches from the kernel-patches-target
> diretory to linux-2.6-denx#v2.6.18. I think the following patches should
> be sufficient (in that order):
>
>fec_mpc52xx_bestcomm.diff
>f
43 matches
Mail list logo
