(no subject)

(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>

(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)

[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_

(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

(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)

[董晓凡]

[-- 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)

[ÏÄÓê]

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)

[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)

[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)

[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)

[Jochen Maes]

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.

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
>>
>>