(no subject)

(no subject)

[Eric N. Johnson (ACD)]

Has anyone been able to use an I2S audio DAC connected to a Programmable 
Serial Controllers (PSC) on the Freescale MPC5200 CPU working under Linux?

The kernel included in the DENX ELDK v3.1.1 has two drivers:
   i2s_ring.c and i2s.c.
The ring driver appears to be RX only, and the i2s.c driver causes the FEC 
ethernet to hang at startup.  I've read some previous mailing list messages 
that suggest there are issues with bestcomm and i2s support.

We've tried adapting the i2s_ring.c driver for our needs.  By default, it 
only has a receive task.  It partially initializes the port, and we see 
appropriate waveforms on the MCLK, CLK, and FRAME lines, but have not been 
able to transmit data.

The stock i2s.c driver hung the boot sequence, but if we comment out the 
bestcomm startup code, it at least completes the boot cycle.  Again we see 
appropriate waveforms on the MCLK, CLK, and FRAME lines.  If we feed data 
to the device (after performing the port setup IOCTLs), we see a 750 us 
burst of data every 45 ms or so.

Is it feasible to send 44.1 or 48 KHz 16-bit audio this way or is the PSC 
only usable for lower data rate applications?

Thank you,
Eric
------------------------------------
Eric Johnson, Electrical Engineer
Advanced Communication Design
   7901 12th Avenue South
   Bloomington, MN 55425
Ph: 952-854-4000  Fax: 952-854-5774

Re: (no subject)

[Wolfgang Denk]

In message <6.2.1.2.1.20050412143653.02ae7720@mail.int.acdstar.com> you wrote:
> 
> The kernel included in the DENX ELDK v3.1.1 has two drivers:
>    i2s_ring.c and i2s.c.

i2s.c is not really a driver, but a (very OLD) test  version  of  one
used  to  demonstrate  certain  BestComm  related problems. Don't try
using it as a real driver ;-)


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
People are always a lot more complicated than you  think.  It's  very
important to remember that.             - Terry Pratchett, _Truckers_

Re: MPC5200 I2S driver

[Eric N. Johnson (ACD)]

At 04:13 PM 4/12/2005, Wolfgang Denk wrote:
>i2s.c is not really a driver, but a (very OLD) test  version  of  one
>used  to  demonstrate  certain  BestComm  related problems. Don't try
>using it as a real driver ;-)

Humm, any pointers on writing our own driver then then?  Digging through 
the source for other drivers, bestcomm seems to be a real house of 
cards.  We just want simple audio output capability.  No need to make it 
work with the standard Linux/OSS sound API.

Where can we keep track of the eratta/bugs in bestcomm?  Browsing through 
the mailing list, I've found references that:
   IDE and Ethernet DMA can't work at the same time
   I2S TX and RX DMA can't work at the same time
   AC-97 is terminally broken (no way to handle the slot tags properly
          for variable sampling rates)
Are these all still true?

We've tried asking our local Freescale rep, but they seem to think that 
Linux==Metrowerks, and they are looking into the bestcomm question, but 
official responses from Freescale tend to take >1 week.

This is for a custom MPC5200 board, heavily based on IceCube with a single 
I2S DAC on PSC2 running in "CODEC with MCLK" mode.

Sorry about the null subject line previously: fingers were working faster 
than brain...

Thanks
Eric


------------------------------------
Eric Johnson, Electrical Engineer
Advanced Communication Design
   7901 12th Avenue South
   Bloomington, MN 55425
Ph: 952-854-4000  Fax: 952-854-5774

Re: MPC5200 I2S driver

[Wolfgang Denk]

In message <6.2.1.2.1.20050412173010.02adaaa0@mail.int.acdstar.com> you wrote:
>
> Humm, any pointers on writing our own driver then then?  Digging through 
> the source for other drivers, bestcomm seems to be a real house of 
> cards.  We just want simple audio output capability.  No need to make it 
> work with the standard Linux/OSS sound API.

User the i2s_ring.c driver as model.

> Where can we keep track of the eratta/bugs in bestcomm?  Browsing through 
> the mailing list, I've found references that:
>    IDE and Ethernet DMA can't work at the same time
>    I2S TX and RX DMA can't work at the same time
>    AC-97 is terminally broken (no way to handle the slot tags properly
>           for variable sampling rates)
> Are these all still true?

This probably depends on your definition  of  "can't  work".  If  you
allow  for  a  failure every now and then under certain (more or less
exotic) usage conditions ... ;-)


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
I have been over into the future, and it works.
                - Lincoln Steffens in _Letters_ (1938) vol. 1, p. 463

Re: MPC5200 I2S driver

[Hans Thielemans]

Hi Eric,

I have been working on a driver for a similar case:
mpc5200 talking to adi blackfin sport channel.

It is rather stable at the moment. Only now and then (~1/hour)
transmission stops due to bestcomm missing a taskstart.
When I check with the bdi2000 it is always the task active bit which
is cleared in the bestcomm registers.
When I kick the dma descriptor by setting the task active bit again with the
bdi2000 it continues normally. I suspect a problem with the bestcomm
api. The dma task active bit is cleared when dma is done. When this 
interferes with the
ppc setting the bit. the task is not started (so far my analysis).
I did not find yet a 100% secure way of getting the bit set.

My main problem was also that I wanted the blackfin to be master of the
link. But the mpc5200 has an anomaly on the frame sync. I managed to
get it work by using the mpc5200 psc spi slave mode and proper
settings at the blackfin side. I got reliable transmission for several hours 
at 16 Mbit/s

The driver supports simultaneous use of several psc channels. I tried psc2 
and psc3 together.
You can use the driver as master or slave by changing the control register 
with ioctl.
I'll forward the present version and a test program when i'm back at work 
tomorrow.

Regards,

Hans Thielemans
HAZO bvba

----- Original Message ----- 
From: "Eric N. Johnson (ACD)" <ejohnson@acdstar.com>
To: <linuxppc-embedded@ozlabs.org>
Sent: Wednesday, April 13, 2005 12:46 AM
Subject: Re: MPC5200 I2S driver


> At 04:13 PM 4/12/2005, Wolfgang Denk wrote:
>>i2s.c is not really a driver, but a (very OLD) test  version  of  one
>>used  to  demonstrate  certain  BestComm  related problems. Don't try
>>using it as a real driver ;-)
>
> Humm, any pointers on writing our own driver then then?  Digging through 
> the source for other drivers, bestcomm seems to be a real house of cards. 
> We just want simple audio output capability.  No need to make it work with 
> the standard Linux/OSS sound API.
>
> Where can we keep track of the eratta/bugs in bestcomm?  Browsing through 
> the mailing list, I've found references that:
>   IDE and Ethernet DMA can't work at the same time
>   I2S TX and RX DMA can't work at the same time
>   AC-97 is terminally broken (no way to handle the slot tags properly
>          for variable sampling rates)
> Are these all still true?
>
> We've tried asking our local Freescale rep, but they seem to think that 
> Linux==Metrowerks, and they are looking into the bestcomm question, but 
> official responses from Freescale tend to take >1 week.
>
> This is for a custom MPC5200 board, heavily based on IceCube with a single 
> I2S DAC on PSC2 running in "CODEC with MCLK" mode.
>
> Sorry about the null subject line previously: fingers were working faster 
> than brain...
>
> Thanks
> Eric
>
>
> ------------------------------------
> Eric Johnson, Electrical Engineer
> Advanced Communication Design
>   7901 12th Avenue South
>   Bloomington, MN 55425
> Ph: 952-854-4000  Fax: 952-854-5774
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

[PATCH v2 2/3] arm64: Support huge vmalloc mappings

[Kefeng Wang]

This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
vmalloc mappings.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 4 ++--
 arch/arm64/Kconfig                              | 1 +
 arch/arm64/kernel/module.c                      | 5 +++--
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 7b2f900fd243..e3f9fd7ec106 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1639,7 +1639,7 @@
 			precedence over memory_hotplug.memmap_on_memory.
 
 
-	hugevmalloc=	[PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
+	hugevmalloc=	[KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
 			Format: { on | off }
 			Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
 
@@ -3424,7 +3424,7 @@
 
 	nohugeiomap	[KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
 
-	nohugevmalloc	[PPC] Disable kernel huge vmalloc mappings.
+	nohugevmalloc	[KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
 
 	nosmt		[KNL,S390] Disable symmetric multithreading (SMT).
 			Equivalent to smt=1.
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3bb0b67292b5..c34bbb4482b0 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -142,6 +142,7 @@ config ARM64
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_ARCH_BITREVERSE
 	select HAVE_ARCH_COMPILER_H
+	select HAVE_ARCH_HUGE_VMALLOC
 	select HAVE_ARCH_HUGE_VMAP
 	select HAVE_ARCH_JUMP_LABEL
 	select HAVE_ARCH_JUMP_LABEL_RELATIVE
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 309a27553c87..af7b4cbace2b 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
 		module_alloc_end = MODULES_END;
 
 	p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
-				module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
+				module_alloc_end, gfp_mask, PAGE_KERNEL,
+				VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
 				NUMA_NO_NODE, __builtin_return_address(0));
 
 	if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
@@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
 		 */
 		p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
 				module_alloc_base + SZ_2G, GFP_KERNEL,
-				PAGE_KERNEL, 0, NUMA_NO_NODE,
+				PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
 				__builtin_return_address(0));
 
 	if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
-- 
2.26.2

Re: (No subject)

[William Kucharski]

You should also fix the existing typo in the documentation (inline):

> On Dec 27, 2021, at 07:49, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> 
> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
> vmalloc mappings.
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
> arch/arm64/Kconfig                              | 1 +
> arch/arm64/kernel/module.c                      | 5 +++--
> 3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 7b2f900fd243..e3f9fd7ec106 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1639,7 +1639,7 @@
>            precedence over memory_hotplug.memmap_on_memory.
> 
> 
> -    hugevmalloc=    [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
> +    hugevmalloc=    [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>            Format: { on | off }
>            Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.

"Reguires" should be "Requires." 

> 
> @@ -3424,7 +3424,7 @@
> 
>    nohugeiomap    [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
> 
> -    nohugevmalloc    [PPC] Disable kernel huge vmalloc mappings.
> +    nohugevmalloc    [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
> 
>    nosmt        [KNL,S390] Disable symmetric multithreading (SMT).
>            Equivalent to smt=1.
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 3bb0b67292b5..c34bbb4482b0 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -142,6 +142,7 @@ config ARM64
>    select HAVE_ARCH_AUDITSYSCALL
>    select HAVE_ARCH_BITREVERSE
>    select HAVE_ARCH_COMPILER_H
> +    select HAVE_ARCH_HUGE_VMALLOC
>    select HAVE_ARCH_HUGE_VMAP
>    select HAVE_ARCH_JUMP_LABEL
>    select HAVE_ARCH_JUMP_LABEL_RELATIVE
> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> index 309a27553c87..af7b4cbace2b 100644
> --- a/arch/arm64/kernel/module.c
> +++ b/arch/arm64/kernel/module.c
> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
>        module_alloc_end = MODULES_END;
> 
>    p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> -                module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
> +                module_alloc_end, gfp_mask, PAGE_KERNEL,
> +                VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
>                NUMA_NO_NODE, __builtin_return_address(0));
> 
>    if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
>         */
>        p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>                module_alloc_base + SZ_2G, GFP_KERNEL,
> -                PAGE_KERNEL, 0, NUMA_NO_NODE,
> +                PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>                __builtin_return_address(0));
> 
>    if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
> -- 
> 2.26.2
> 
> 

Re: (No subject)

[Kefeng Wang]

On 2021/12/28 1:35, William Kucharski wrote:
> You should also fix the existing typo in the documentation (inline):
>
>> On Dec 27, 2021, at 07:49, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>>
>> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
>> vmalloc mappings.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
>> arch/arm64/Kconfig                              | 1 +
>> arch/arm64/kernel/module.c                      | 5 +++--
>> 3 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 7b2f900fd243..e3f9fd7ec106 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -1639,7 +1639,7 @@
>>             precedence over memory_hotplug.memmap_on_memory.
>>
>>
>> -    hugevmalloc=    [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>> +    hugevmalloc=    [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>>             Format: { on | off }
>>             Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
> "Reguires" should be "Requires."
Will fix, thanks.
>
>> @@ -3424,7 +3424,7 @@
>>
>>     nohugeiomap    [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
>>
>> -    nohugevmalloc    [PPC] Disable kernel huge vmalloc mappings.
>> +    nohugevmalloc    [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
>>
>>     nosmt        [KNL,S390] Disable symmetric multithreading (SMT).
>>             Equivalent to smt=1.
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 3bb0b67292b5..c34bbb4482b0 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -142,6 +142,7 @@ config ARM64
>>     select HAVE_ARCH_AUDITSYSCALL
>>     select HAVE_ARCH_BITREVERSE
>>     select HAVE_ARCH_COMPILER_H
>> +    select HAVE_ARCH_HUGE_VMALLOC
>>     select HAVE_ARCH_HUGE_VMAP
>>     select HAVE_ARCH_JUMP_LABEL
>>     select HAVE_ARCH_JUMP_LABEL_RELATIVE
>> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
>> index 309a27553c87..af7b4cbace2b 100644
>> --- a/arch/arm64/kernel/module.c
>> +++ b/arch/arm64/kernel/module.c
>> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
>>         module_alloc_end = MODULES_END;
>>
>>     p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>> -                module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
>> +                module_alloc_end, gfp_mask, PAGE_KERNEL,
>> +                VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
>>                 NUMA_NO_NODE, __builtin_return_address(0));
>>
>>     if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
>> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
>>          */
>>         p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>>                 module_alloc_base + SZ_2G, GFP_KERNEL,
>> -                PAGE_KERNEL, 0, NUMA_NO_NODE,
>> +                PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>>                 __builtin_return_address(0));
>>
>>     if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
>> -- 
>> 2.26.2
>>
>>

(no subject)

[Awad, Sinan (GE Healthcare)]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

Hello all
 
I'm trying to understand if we need to move from MPC8347 to MPC8360 in
our boards.
One of the features that most attracts, is the eTSEC which includes
support for IEEE 1588 PTP time synchronization.
I need to synchronize the clock of 3 boards via ethernet, I need a time
resolution of under 1ms.
 
Has anyone had the pleasure of playing around with time synchronization
?
Do I really need the hardware capabilities for this type of time
resolution ? or can I implement it in software ?
 
Thanks in advance.
Sinan
 


[-- Attachment #2: Type: text/html, Size: 2013 bytes --]

Re: (no subject)

[Misbah khan]

I can tell you from Software point of view ....There should be One Time
Master and others as time slave data would be transmitted via Ethernet and
PPS through OFC ...Ntp should be runing ...I guess this is a way in which we
could Sync all the other boards ....

----Misbah <><

Awad, Sinan (GE Healthcare) wrote:
> 
> Hello all
>  
> I'm trying to understand if we need to move from MPC8347 to MPC8360 in
> our boards.
> One of the features that most attracts, is the eTSEC which includes
> support for IEEE 1588 PTP time synchronization.
> I need to synchronize the clock of 3 boards via ethernet, I need a time
> resolution of under 1ms.
>  
> Has anyone had the pleasure of playing around with time synchronization
> ?
> Do I really need the hardware capabilities for this type of time
> resolution ? or can I implement it in software ?
>  
> Thanks in advance.
> Sinan
>  
> 
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

-- 
View this message in context: http://www.nabble.com/%28no-subject%29-tp14593723p14594687.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

(no subject)

[Jochen Maes]

(no subject)

[siman]

Hi All:
I want port Linux system to the MVME6100, I found moto has this kind of
patch for the MOTO SBC, just like patch-2.6.6-mcg.rm01.gz file.
Any know how and where can I download it? 
Thank you very much.

(no subject)

[Otavio Salvador]

---

 arch/ppc/platforms/chrp_setup.c |    1 -
 arch/ppc/platforms/prep_setup.c |    1 -
 2 files changed, 0 insertions(+), 2 deletions(-)

applies-to: 8622c40782404c8fb13aa2a4dd4a7b0ebc44e896
66697dfc757179883127a3ae53bc486320b38374
diff --git a/arch/ppc/platforms/chrp_setup.c b/arch/ppc/platforms/chrp_setup.c
index f1b70ab..056ac2a 100644
--- a/arch/ppc/platforms/chrp_setup.c
+++ b/arch/ppc/platforms/chrp_setup.c
@@ -404,7 +404,6 @@ static struct irqaction xmon_irqaction =
 void __init chrp_init_IRQ(void)
 {
 	struct device_node *np;
-	int i;
 	unsigned long chrp_int_ack = 0;
 	unsigned char init_senses[NR_IRQS - NUM_8259_INTERRUPTS];
 #if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(XMON)
diff --git a/arch/ppc/platforms/prep_setup.c b/arch/ppc/platforms/prep_setup.c
index 4415748..f4ef267 100644
--- a/arch/ppc/platforms/prep_setup.c
+++ b/arch/ppc/platforms/prep_setup.c
@@ -954,7 +954,6 @@ prep_calibrate_decr(void)
 static void __init
 prep_init_IRQ(void)
 {
-	int i;
 	unsigned int pci_viddid, pci_did;
 
 	if (OpenPIC_Addr != NULL) {
---
0.99.9k

(no subject)

[Bob Brose]

I'm trying to fix some of the AX25 code in the 2.6 kernel and traced down
a problem to the use of a char var which was being assigned
the value of -1. On x86 when the var was compared to -1 it succeded but
on PPC it failed. So I tried a simple test:

main()
{
char atest;
atest=-1;
printf("%i,%X\n",atest,atest);
}

With GCC 3.3.5 on 2.6.14-rc1 x86 I get:
./atest
-1,FFFFFFFF

With GCC 3.3.5 on 2.6.14-rc1 PPC I get:
./atest
255,FF

If I change the declaration of atest to a signed char on PPC I get the
same result as x86.

Does this mean the char in x86 is signed and in PPC it's unsigned?
Has it always been thus?
 

Re: (no subject)

[Andreas Schwab]

Bob Brose <linuxppcdev@qbjnet.com> writes:

> Does this mean the char in x86 is signed and in PPC it's unsigned?

Yes.

> Has it always been thus?

Yes.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

(no subject)

[ÏÄÓê]

I have plugged a PCI net card (i82559)on the ICECUBE board (mpc5200), but could not make it work .Which environment should i config in U-BOOT?

Re: (no subject)

[Wolfgang Denk]

In message <200509272153.AA292552812@NARI-RELAYS.COM> you wrote:
> I have plugged a PCI net card (i82559)on the ICECUBE board (mpc5200), but could not make it work .Which environment should i config in U-BOOT?

What are you talking about? Make it work in U-Boot?  In  Linux?  What
exactly  did you try, and what did not work? What was the exact error
messages?

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
Der Horizont vieler Menschen ist ein Kreis mit Radius Null --
und das nennen sie ihren Standpunkt.

(no subject)

[董晓凡]

[-- Attachment #1.1: Type: text/plain, Size: 321 bytes --]

 

Hi，everybody.Recently,I focus on kernel 2.6.10,I want to migrate it to
mpc8260.

But,I can not compile it successfully when I choose fcc .And it seems some
wrong with cpm2_immap.h.

Would you like to tell me if it need a patch.

Thankyou very much!

**********************************************

 


[-- Attachment #1.2: Type: text/html, Size: 4265 bytes --]

[-- Attachment #2: image001.jpg --]
[-- Type: image/jpeg, Size: 4389 bytes --]

[-- Attachment #3: image002.gif --]
[-- Type: image/gif, Size: 7830 bytes --]

Re: (no subject)

[evilninja]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

董晓凡 schrieb:
>  
> 
> Hi，everybody.Recently,I focus on kernel 2.6.10,I want to migrate it to
> mpc8260.
> 
> But,I can not compile it successfully when I choose fcc .And it seems some
> wrong with cpm2_immap.h.

mind to show us the compile errors?

Christian.
PS: and *please* don't send HTML only messages.
- --
BOFH excuse #147:

Party-bug in the Aloha protocol.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCwsrXC/PVm5+NVoYRApx4AKDmCtqASeh3uRzoC1nO94k4LFlTmgCeKOc2
vbEH4lwXt/zZV+JhA0zwOxc=
=pk9/
-----END PGP SIGNATURE-----

(no subject)

[FLAMENT David]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

hello, 
 
I use a EP8248 and I search a Kernel 2.6 for this board because I use a kernel 2.4.26 of arabella and the usb isn't supported in this version.
When I compile with USB option ( uhci, scsi + usb mastorage), there is this message "usb-ohci currently requires PCI-based controllers".
If you have a sugget, thank you.
 
 
--------------------------------
Flament David
d.flament@sofrel.com
Lacroix Sofrel, 1 rue plessis, 35770 Vern sur seiche (France)
(+33)2.99.04.84.23
 
 

[-- Attachment #2: Type: text/html, Size: 1677 bytes --]

(no subject)

[colui77]

Hi guys, 
any of you knows a version of JVM running on Montavista linux for ML300
(PPC405)
I tried the Blackdown 1.3.1 for PPC but it doesn't seem to work...
Any suggestion?
Thanks,
Luigi

Support for Adder875 in Linux 2.4

[Markus Westergren]

Hi,

I'm working on a project which will use hardware based on Analogue & Micro
Adder875 module together with Linux 2.4.

I use RedBoot as bootloader and kernel 2.4.27-pre1, both came with the Adder
module.

The project require:

 - dual ethernet support with AM79C874 PHY
   The driver I've found (fec.c) only supports one ethernet. I'v started
	modifying a newer version of this driver which have support for my PHY. I
	have made some progress but it's not working yet. Found out that the first
	FEC is used to communicate with both PHY's. Both devices are detected
	correctly and the first seems to work but the second hangs the kernel when
	the first packet is sent or received.
 - SPI support
   Have found a simple driver (cpm_spi.c), which I have not tested yet.
 - PCMCIA support
   Will try to modify the m8xx_pcmcia driver.

Not required but would be good to have:
 - USB host support
   Have no clue where to start looking.

Have anyone used this module together with Linux and are there working drivers
for it? Any tips/ideas?

Thanks

/Markus

------------------
Markus Westergren
Biologigrand 17
S-907 32 Umea
SWEDEN

Re: Support for Adder875 in Linux 2.4

[Yuli Barcohen]

>>>>> Markus Westergren writes:

    Markus> Hi, I'm working on a project which will use hardware based
    Markus> on Analogue & Micro Adder875 module together with Linux 2.4.

    Markus> I use RedBoot as bootloader and kernel 2.4.27-pre1, both
    Markus> came with the Adder module.

    Markus> The project require:

    Markus> - dual ethernet support with AM79C874 PHY
    Markus>    The driver I've found (fec.c) only supports one
    Markus>    ethernet. I'v started
    Markus> 	modifying a newer version of this driver which have
    Markus> 	support for my PHY. I have made some progress but it's
    Markus> 	not working yet. Found out that the first FEC is used to
    Markus> 	communicate with both PHY's. Both devices are detected
    Markus> 	correctly and the first seems to work but the second
    Markus> 	hangs the kernel when the first packet is sent or
    Markus> 	received.
    Markus> - SPI support
    Markus>    Have found a simple driver (cpm_spi.c), which I have not
    Markus>    tested yet.
    Markus> - PCMCIA support
    Markus>    Will try to modify the m8xx_pcmcia driver.

    Markus> Not required but would be good to have:
    Markus> - USB host support
    Markus>    Have no clue where to start looking.

    Markus> Have anyone used this module together with Linux and are
    Markus> there working drivers for it? Any tips/ideas?

Arabella Linux supports all these. Not sure how you are going to use
PCMCIA on this specific board - it's not connected.

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli@arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

Re: Support for Adder875 in Linux 2.4

[Markus Westergren]

On Mon, 14 Feb 2005, Yuli Barcohen wrote:

> >>>>> Markus Westergren writes:
>
>     Markus> Hi, I'm working on a project which will use hardware based
>     Markus> on Analogue & Micro Adder875 module together with Linux 2.4.
>
>     Markus> I use RedBoot as bootloader and kernel 2.4.27-pre1, both
>     Markus> came with the Adder module.
>
>     Markus> The project require:
>
>     Markus> - dual ethernet support with AM79C874 PHY
>     Markus>    The driver I've found (fec.c) only supports one
>     Markus>    ethernet. I'v started
>     Markus> 	modifying a newer version of this driver which have
>     Markus> 	support for my PHY. I have made some progress but it's
>     Markus> 	not working yet. Found out that the first FEC is used to
>     Markus> 	communicate with both PHY's. Both devices are detected
>     Markus> 	correctly and the first seems to work but the second
>     Markus> 	hangs the kernel when the first packet is sent or
>     Markus> 	received.
>     Markus> - SPI support
>     Markus>    Have found a simple driver (cpm_spi.c), which I have not
>     Markus>    tested yet.
>     Markus> - PCMCIA support
>     Markus>    Will try to modify the m8xx_pcmcia driver.
>
>     Markus> Not required but would be good to have:
>     Markus> - USB host support
>     Markus>    Have no clue where to start looking.
>
>     Markus> Have anyone used this module together with Linux and are
>     Markus> there working drivers for it? Any tips/ideas?
>
> Arabella Linux supports all these. Not sure how you are going to use
> PCMCIA on this specific board - it's not connected.
>
The board in my project is almost like a Adder875 but unlike the Adder it has a
PCMCIA slot connected.

I have tested a version of Arabella (FREE v2.1, kernel 2.4.25). It looks like
that the fec driver only supports general PHY and no link interrupts.

/Markus

(no subject)

[Yuli Barcohen]

>>>>> Markus Westergren writes:

    Markus> The board in my project is almost like a Adder875 but unlike
    Markus> the Adder it has a PCMCIA slot connected.

No problems, it's supported

    Markus> I have tested a version of Arabella (FREE v2.1, kernel
    Markus> 2.4.25). It looks like that the fec driver only supports
    Markus> general PHY and no link interrupts.

Yes, because nobody of our customers needed PHY-specific support. It's
trivial to add if necessary.

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli@arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

(no subject)

[Ratin Kumar]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

Hi,

I am trying to build a toolchain for MPC5200 using gcc 3.4.1.

The bootstrap compiler build fails with a complain that it could not
locate "signal.h". This happens even though I have the kernel headers
(with signal.h) installed. A quick search on google shows that some
other people have also run into this issue, although no patches/sloution
appears. Any ideas??

Also, has anyone tried using 3.4.1 compiler for kernel 2.4.23 ????

What are the matching glibc and binutils to use with 3.4.1?? Any
patches??

Thanks,
Rk.

[-- Attachment #2: Type: text/html, Size: 1144 bytes --]

Re: (no subject)

[Kumar Gala]

Ratin,

I would suggest looking at Dan Kegel's crosstool @ 
http://www.kegel.com/crosstool/.  Very helpful in pairing various parts 
of the GNU toolchain together to get a working version.  For MPC5200 
you want the ppc750 build.

- kumar

On Nov 22, 2004, at 1:23 PM, Ratin Kumar wrote:

> Hi,
>
> I am trying to build a toolchain for MPC5200 using gcc 3.4.1.
>
> The bootstrap compiler build fails with a complain that it could not 
> locate "signal.h". This happens even though I have the kernel headers 
> (with signal.h) installed. A quick search on google shows that some 
> other people have also run into this issue, although no 
> patches/sloution appears. Any ideas??
>
> Also, has anyone tried using 3.4.1 compiler for kernel 2.4.23 ????
>
> What are the matching glibc and binutils to use with 3.4.1?? Any 
> patches??
>
> Thanks,
>  Rk.
> <ATT949193.txt>