Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
On Sun, May 6, 2012 at 4:37 PM, Robert Berger wrote: > On 04/02/2012 09:28 AM, Tony Breeds wrote: >> On Mon, Apr 02, 2012 at 12:01:55PM +1000, Benjamin Herrenschmidt wrote: >> >>> Ok, I've asked Tony to have a look at splitting the build decision >>> in arch/powerpc/boot along the same lines as the CPU families... ie only >>> wrappers for platforms potentially supported by the built kernel. That >>> should fix it. >> >> Please try this patch. Only lightly tested here. I haven't "split up" >> src-wlib yet as I wanted to verify I'm on the right track. > > I can confirm that it fixes the kilauea problem. Builds and runs so far. > Are you going to push this upstream? > I can confirm this too (applied to 3.4-rc7). Tony? Best regards, Frank ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
On Mon, Mar 26, 2012 at 3:36 PM, Josh Boyer wrote: > On Sat, Mar 24, 2012 at 7:53 PM, Benjamin Herrenschmidt > wrote: >> On Wed, 2012-03-21 at 17:25 +0100, Wolfgang Denk wrote: >>> > > The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes >>> with the >>> > > ELDK 4.2) this assembly instruction is not known and the build >>> breaks. >>> > >>> > Sigh. GCC 4.2 is pretty old at this point. >>> >>> But still rock-solid ... We use it a lot, especially as reference for >>> more recent (and sometimes more broken) versions of GCC. >> >> Isn't this a binutils rather than gcc issue ? > > Pretty much. > Hi Josh Boyer, just wanted to add that I'm experiencing the same problem that Robert reported, but on 8xx instead of 4xx. The mpc8xx does not support the mfdcrx instruction, so maybe it's more to it than just a binutils bug? Best regards, Frank ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Problem with futex call on 8xx
Hi I'm having a problem with ~100% CPU load on MPC8xx when calling pthread_cond_wait. Running strace, I get: futex(0x10040d5c, FUTEX_WAIT, 1, NULL) = -1 ENOSYS (Function not implemented) .. and this call is inifinitely repeating, which explains the high load. I'm running Linux 2.6.26-rc2 (not newer due to the slowdown problem introduced by commit 8d30c14cab30d405a05f2aaceda1e9ad57800f36, as pointed out by Rex Feany this week), and glibc v2.6 (part of ELDK 4.2). Is this a problem due to an error in the futex implementation in glibc, or a kernel problem? Best regards, Frank ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with futex call on 8xx
I'll answer myself, since I just found the solution to the problem - with help from 'kos_tom' at #uclibc on freenode. The problem is caused by a missing 'CONFIG_FUTEX=y' in the defconfig for our target. The system we're developing is based on the Adder port by Scott Wood, which is also missing this, so a patch should be committed for this and possible other 8xx targets as well. Best regards, Frank On Sat, Sep 26, 2009 at 2:00 PM, Frank Svendsbøe wrote: > Hi > I'm having a problem with ~100% CPU load on MPC8xx when calling > pthread_cond_wait. > Running strace, I get: > > futex(0x10040d5c, FUTEX_WAIT, 1, NULL) = -1 ENOSYS (Function not implemented) > > .. and this call is inifinitely repeating, which explains the high load. > > I'm running Linux 2.6.26-rc2 (not newer due to the slowdown problem > introduced by commit > 8d30c14cab30d405a05f2aaceda1e9ad57800f36, as pointed out by Rex Feany > this week), and > glibc v2.6 (part of ELDK 4.2). > > Is this a problem due to an error in the futex implementation in > glibc, or a kernel problem? > > Best regards, > Frank > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux booting fine but running slow
Hi Gao and Stevan I've observed the same slow-down issue on an MPC875 a while now, but haven't had the time to do a git-bisect and find the patch that causes the problem. So far, I'm running torvalds 2.6.29-rc6, and the slow-down problem was introduced somewhere between 2.6.26-rc6 and 2.6.30-rc2. What options did you specify to improve the performance? Regards, Frank On Fri, Sep 11, 2009 at 1:59 PM, Gao Ya'nan wrote: > Hi, stevan, I had met a similarly problem with U-Boot-v2009.08 and > DENX-v2.6.30.3 Linux. > > Today, I add some options to Linux, everythings worked well, but I got > a fat kernel. Do you solve it now ? > > Gao Ya'nan > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RAMDISK on EP88xc
On Thu, Jul 2, 2009 at 8:42 PM, Mikhail Zaturenskiy wrote: >> Just as an intermediate update on the issue, I've made progress and it >> hangs later down the line, see below: >> >> Using Embedded Planet EP88xC machine description >> Linux version 2.6.30-rc2-01402-gd4e2f68-dirty (dev...@localhost.localdomain) >> (gc >> c version 4.2.2) #3 Thu Jul 2 11:00:54 CDT 2009 >> Found initrd at 0xc3dbb000:0xc3f6d056 >> Zone PFN ranges: >> DMA 0x -> 0x4000 >> Normal 0x4000 -> 0x4000 >> Movable zone start PFN for each node >> early_node_map[1] active PFN ranges >> 0: 0x -> 0x4000 >> MMU: Allocated 72 bytes of context maps for 16 contexts >> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 >> Kernel command line: console=ttyCPM0,9600n8 root=/dev/ram loglevel=7 >> init=/sbin/ >> init >> NR_IRQS:512 >> PID hash table entries: 256 (order: 8, 1024 bytes) >> Decrementer Frequency = 0x5f5e10 >> clocksource: timebase mult[2800] shift[22] registered >> console [ttyCPM0] enabled >> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) >> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) >> Memory: 60716k/65536k available (2136k kernel code, 4752k reserved, 100k >> data, 9 >> 9k bss, 112k init) >> SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 >> Calibrating delay loop... 12.39 BogoMIPS (lpj=61952) >> Mount-cache hash table entries: 512 >> net_namespace: 296 bytes >> NET: Registered protocol family 16 >> bio: create slab at 0 >> NET: Registered protocol family 2 >> IP route cache hash table entries: 1024 (order: 0, 4096 bytes) >> TCP established hash table entries: 2048 (order: 2, 16384 bytes) >> TCP bind hash table entries: 2048 (order: 1, 8192 bytes) >> TCP: Hash tables configured (established 2048 bind 2048) >> TCP reno registered >> NET: Registered protocol family 1 >> checking if image is initramfs... >> rootfs image is not initramfs (no cpio magic); looks like an initrd >> Freeing initrd memory: 1736k freed >> msgmni has been set to 122 >> io scheduler noop registered >> io scheduler deadline registered (default) >> Generic RTC Driver v1.07 >> fa80.serial: ttyCPM0 at MMIO 0xc500ea80 (irq = 19) is a CPM UART >> fa20.serial: ttyCPM1 at MMIO 0xc5016a20 (irq = 29) is a CPM UART >> brd: module loaded >> loop: module loaded >> eth0: fs_enet: 00:00:00:00:00:00 >> eth1: fs_enet: 00:00:00:00:00:00 >> FEC MII Bus: probed >> fe00.flash: Found 2 x16 devices at 0x0 in 32-bit bank >> Amd/Fujitsu Extended Query Table at 0x0040 >> fe00.flash: CFI does not contain boot bank location. Assuming top. >> number of CFI chips: 1 >> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness. >> TCP cubic registered >> NET: Registered protocol family 17 >> RPC: Registered udp transport module. >> RPC: Registered tcp transport module. >> RAMDISK: gzip image found at block 0 >> VFS: Mounted root (ext2 filesystem) readonly on device 1:0. >> Freeing unused kernel memory: 112k init >> >> >> Now searching for cause, looks like it's "init" related... >> > > Wow... I just found out that it's not actually "hanging" at this > point.. it's just working in "slow motion"... I found out by leaving > the machine and coming back half an hour later to find additional > output and eventually even a prompt. > Hi Mikhail, This is very interesting. I recently experienced a similar problem when upgrading from 2.6.26-rc6 to 2.6.31-rc1 (torvalds mainline kernel). I didn't had the time to figure out what was happening, so I went back to 2.6.26-rc6. Just for the test, could you try to go back to 2.6.26 and see if the problem remains? - Frank > Here is what's happening: > * > RAMDISK: gzip image found at block 0 > VFS: Mounted root (ext2 filesystem) on device 1:0. > Freeing unused kernel memory: 112k init > > <4 minutes pass> > > init started: BusyBox v1.7.1 (2008-04-02 09:14:47 MEST) > > <2 minutes pass> > > starting pid 403, tty '': '/etc/rc.sh' > > < etc... > > * > > I've tried a couple different ramdisk images (another one with a much > older version of busybox), with similar results. Anybody have an idea > about what's going on here? > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RAMDISK on EP88xc
On Wed, Jul 1, 2009 at 10:14 PM, Mikhail Zaturenskiy wrote: >> Hi Mikhail, >> Try setting CONFIG_EXT2_FS=y, then recompile your kernel and reboot. > > Hi Frank, just tried that but still getting the same "Unpacking > initramfs... failed!" output > Hmm... according to "Kernel command line: console=ttyCPM0,9600n8 loglevel=7" you haven't specified where root is. Add root=/dev/ram to the kernel command line, and specify where the init process is located (for instance init=/sbin/init). I haven't tried Denks ramdisk image. You can create one for yourself using dd, gzip and U-Boots mkimage tool. If the ramdisk image is larger than 4MB, you must either change the default CONFIG_BLK_DEV_RAM_SIZE=4096, or set ramdisk size in the kernel command line. Btw, I use an older kernel than you use, but I have these defined: CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 Maybe they're obsolete now, but you can try to add them to your defconfig file. Good luck ;-) - Frank ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RAMDISK on EP88xc
On Wed, Jul 1, 2009 at 8:04 PM, Mikhail Zaturenskiy wrote: > Hello, > I'm trying to get a ramdisk working on my EP88xc with uboot and linux > kernel v2.6.30. The ramdisk image is from > ELDK_4.2/ppc_8xx/images/uRamdisk. > > At first I thought my issue was similar to > http://ozlabs.org/pipermail/linuxppc-embedded/2008-August/031204.html > but I'm not so sure anymore. I think my problem is with incorrectly > configuring my kernel. > Hi Mikhail, Try setting CONFIG_EXT2_FS=y, then recompile your kernel and reboot. - Frank ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Trouble "Transferring control to Linux (at address 00000000)"
On Fri, Jun 26, 2009 at 7:12 PM, Mikhail Zaturenskiy wrote: > Hi Scott, > >> This isn't the denx list; > I've noticed :) but I'm still learning about this whole process so I > though I could get some general suggestions. > >> what kernel version is that, and with what >> modifications from mainline? > Kernel is v2.6.30, I'm not yet familiar enough with it to know what's > been modified from mainline, just following instructions. > >> Note that ep88xc.dts in mainline is intended for use with PlanetCore, which >> is what ships on that board. You may need to make modifications for it to >> work with u-boot (at the least, the IMMR base is probably different). > Hmm, this hasn't occurred to me, thank you for pointing it out. > I don't have access to this board, but have experience with a similar one (Adder 875), and I might be able to help out. Scott's right. According to U-Boots include/configs/EP88x.h, CONFIG_SYS_IMMR is 0xf000, but the Linux the ep88xc.dts is referring to an IMMR set to 0xfa20. Replace every instance of 0xfa20 with 0xf000, and it may work. >> Also, make sure u-boot is properly updating the memory size in the device >> tree. Can you dump the post-fixup device tree in u-boot? > Not sure, but I'll try to find out if that's possible. It'd certainly > answer a lot of questions... > > Thanks, > Mikhail Zaturenskiy > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- "no_irq_chip" error
On Fri, May 29, 2009 at 7:18 PM, Scott Wood wrote: > On Fri, May 29, 2009 at 12:56:13PM +0200, Frank Svendsbře wrote: >> FYI. The same applies to mpc8xx targets: No default host interrupt >> controller. >> The following patch was needed for our target: >> --- >> diff --git a/arch/powerpc/sysdev/mpc8xx_pic.c >> b/arch/powerpc/sysdev/mpc8xx_pic.c >> index 5d2d552..92b2b66 100644 >> --- a/arch/powerpc/sysdev/mpc8xx_pic.c >> +++ b/arch/powerpc/sysdev/mpc8xx_pic.c >> @@ -186,6 +186,7 @@ int mpc8xx_pic_init(void) >> ret = -ENOMEM; >> goto out; >> } >> + irq_set_default_host(mpc8xx_pic_host); >> return 0; > > This patch is whitespace mangled. > >> >> out: >> --- >> Maybe setting a default host ought to be mandatory? Or is doing the >> mapping manually >> (without device tree descriptions) considered being a hack? > > I consider it a hack -- not so much doing it manually (though the device > tree is better), but relying on a default interrupt controller when doing > so. IRQ numbers only make sense in the context of a specific > controller. It's especially misleading on 8xx, which has separate > regular and CPM PICs. > > -Scott > I agree, and was the reason I mentioned "hack". The patch wasn't meant for commit, just for reference (sorry for whitemangling ;-) Regarding doing manual mapping: Is there another way to retrieve the host controller from a driver module without modifying kernel source? In case not, do you think exporting the mpc8xx_pic_host symbol is a better solution? Anyway, now that I'm beginning to understand dts I guess I might as well just do it properly. - Frank ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- "no_irq_chip" error
FYI. The same applies to mpc8xx targets: No default host interrupt controller.
The following patch was needed for our target:
---
diff --git a/arch/powerpc/sysdev/mpc8xx_pic.c b/arch/powerpc/sysdev/mpc8xx_pic.c
index 5d2d552..92b2b66 100644
--- a/arch/powerpc/sysdev/mpc8xx_pic.c
+++ b/arch/powerpc/sysdev/mpc8xx_pic.c
@@ -186,6 +186,7 @@ int mpc8xx_pic_init(void)
ret = -ENOMEM;
goto out;
}
+irq_set_default_host(mpc8xx_pic_host);
return 0;
out:
---
Maybe setting a default host ought to be mandatory? Or is doing the
mapping manually
(without device tree descriptions) considered being a hack?
Frank
On Thu, May 28, 2009 at 2:33 PM, Wolfram Sang wrote:
>> this is an example of how a simple 8313 Periodic Interval Timer (PIT) kernel
>> driver
>> registers for the PIT IRQ (Interrupt ID 65)
>>
>> #define PIT_IRQ 65
>>
>> virq = irq_create_mapping(NULL, PIT_IRQ);
>> set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
>>
>> if(request_irq(virq, (irq_handler_t)timerEvent, 0, "timer2", (void *)0))
>> {
>> printk(KERN_ERR "request_irq() returned error for irq=%d virq=%d\n",
>> PIT_IRQ, virq);
>> }
>
> It is some time ago, but when I did something similar I needed the
> following patch in order to use NULL for irq_create_mapping(). Have a
> try, and if it is still needed (as it looks from a glimpse), then maybe
> we should get it merged?
>
> ===
>
> From: Wolfram Sang
> Subject: [PATCH] powerpc/cpm2: make cpm2_pic the default host
>
> Signed-off-by: Wolfram Sang
> ---
> arch/powerpc/sysdev/cpm2_pic.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/cpm2_pic.c b/arch/powerpc/sysdev/cpm2_pic.c
> index 78f1f7c..7a7d4e5 100644
> --- a/arch/powerpc/sysdev/cpm2_pic.c
> +++ b/arch/powerpc/sysdev/cpm2_pic.c
> @@ -272,4 +272,5 @@ void cpm2_pic_init(struct device_node *node)
> printk(KERN_ERR "CPM2 PIC: failed to allocate irq host!\n");
> return;
> }
> + irq_set_default_host(cpm2_pic_host);
> }
>
> --
> Pengutronix e.K. | Wolfram Sang |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkoehIYACgkQD27XaX1/VRsAygCePysW72eSPbW0rdM5DZ6lJS+7
> lEwAoItsU+K2CO9Eqfrwj64TgwEskB85
> =+3mh
> -END PGP SIGNATURE-
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
