multiprocessor
i am trying to make a exam about Multiprocessor on the Xilinx Virtex-4 with two PowerPc hard core. please give me some advices about bootloader and os. how can i start my work. keng_629 2007-11-17 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx software reset problems from paulus.git
On Nov 16, 2007 4:46 PM, Kumar Gala <[EMAIL PROTECTED]> wrote: > > > On Nov 16, 2007, at 3:28 PM, robert lazarski wrote: > > > On Nov 16, 2007 3:44 PM, robert lazarski <[EMAIL PROTECTED]> > > wrote: > >> On Nov 16, 2007 10:27 AM, Clemens Koller > >> <[EMAIL PROTECTED]> wrote: > >>> The SRESET# (pin AF20) is the soft reset input, causes > >>> an mcp assertion to the core (RTFM) > >>> > >> > >> That's what we are doing. The 85xx docs say "Soft reset. Causes a > >> machine check interrupt to the e500 core. Note that if the e500 core > >> is not configured to process machine check interrupts, the assertion > >> of SRESET causes a core checkstop. SRESET need not be asserted during > >> a hard reset." > >> > > > > Sorry for replying to myself, but thought I'd mention SRESET works > > fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It > > doesn't work for me on 2.6.24rc2 . > > What actual 85xx are you using? > > - k > Custom 8548 board. I'm using the cds 85xx code for a reference and I calling the same reset functions. Robert ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx software reset problems from paulus.git
On Nov 16, 2007, at 3:28 PM, robert lazarski wrote: > On Nov 16, 2007 3:44 PM, robert lazarski <[EMAIL PROTECTED]> > wrote: >> On Nov 16, 2007 10:27 AM, Clemens Koller >> <[EMAIL PROTECTED]> wrote: >>> The SRESET# (pin AF20) is the soft reset input, causes >>> an mcp assertion to the core (RTFM) >>> >> >> That's what we are doing. The 85xx docs say "Soft reset. Causes a >> machine check interrupt to the e500 core. Note that if the e500 core >> is not configured to process machine check interrupts, the assertion >> of SRESET causes a core checkstop. SRESET need not be asserted during >> a hard reset." >> > > Sorry for replying to myself, but thought I'd mention SRESET works > fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It > doesn't work for me on 2.6.24rc2 . What actual 85xx are you using? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Latest paulus.git PCI broken on mpc8540?
On Nov 16, 2007, at 3:09 PM, Benjamin Herrenschmidt wrote: > > On Fri, 2007-11-16 at 13:18 -0600, Kumar Gala wrote: >> >> >> Well, for one the generic pci code will complain if its not able to >> allocate the resource which is the true failure. >> >> I'm thinking maybe we just make these pr_debug() instead of standard >> printk? > > I was thinking about changing the message to "cannot allocate initial > resource, will reallocate" or something like that. That is, make it > clear it's non fatal. Yeah, something that on those lines would be good, and maybe mark them KERN_WARNING instead of KERN_ERR. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx software reset problems from paulus.git
On Nov 16, 2007 3:44 PM, robert lazarski <[EMAIL PROTECTED]> wrote: > On Nov 16, 2007 10:27 AM, Clemens Koller <[EMAIL PROTECTED]> wrote: > > The SRESET# (pin AF20) is the soft reset input, causes > > an mcp assertion to the core (RTFM) > > > > That's what we are doing. The 85xx docs say "Soft reset. Causes a > machine check interrupt to the e500 core. Note that if the e500 core > is not configured to process machine check interrupts, the assertion > of SRESET causes a core checkstop. SRESET need not be asserted during > a hard reset." > Sorry for replying to myself, but thought I'd mention SRESET works fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It doesn't work for me on 2.6.24rc2 . Robert ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Latest paulus.git PCI broken on mpc8540?
> > I don't know much of the code, so, propably a stupid question: > Can we avoid to do the initial resource allocation, when it's known to fail? > > It seems to me like things are done twice here: > 1. try > 2. reallocate > 3. retry Well, we don't know it's going to fail until we try :-) Ben. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Latest paulus.git PCI broken on mpc8540?
Hi, Ben! Benjamin Herrenschmidt schrieb: > On Fri, 2007-11-16 at 13:18 -0600, Kumar Gala wrote: >> >> Well, for one the generic pci code will complain if its not able to >> allocate the resource which is the true failure. >> >> I'm thinking maybe we just make these pr_debug() instead of standard >> printk? > > I was thinking about changing the message to "cannot allocate initial > resource, will reallocate" or something like that. That is, make it > clear it's non fatal. I don't know much of the code, so, propably a stupid question: Can we avoid to do the initial resource allocation, when it's known to fail? It seems to me like things are done twice here: 1. try 2. reallocate 3. retry Regards, -- Clemens Koller ___ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Latest paulus.git PCI broken on mpc8540?
On Fri, 2007-11-16 at 13:18 -0600, Kumar Gala wrote: > > > Well, for one the generic pci code will complain if its not able to > allocate the resource which is the true failure. > > I'm thinking maybe we just make these pr_debug() instead of standard > printk? I was thinking about changing the message to "cannot allocate initial resource, will reallocate" or something like that. That is, make it clear it's non fatal. Ben. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx software reset problems from paulus.git
On Nov 16, 2007 10:27 AM, Clemens Koller <[EMAIL PROTECTED]> wrote: > Hello, Robert! > > robert lazarski schrieb: > > Hi all, on my custom 85xx board I can't do a soft reset. I'm using > > u-boot 1.3rc3 that has the latest cpu/mpc85xx/cpu.c patch to fix some > > type of reset problem. When I press the software reset button on my > > board after my nfs kernel panic, I get this: > > Please define "software reset button" in your case. :-) > I consider a "button" clearly as hardware. > I mean a hardware button that calls SRESET , ie, Soft reset machine check. > > The SRESET# (pin AF20) is the soft reset input, causes > an mcp assertion to the core (RTFM) > That's what we are doing. The 85xx docs say "Soft reset. Causes a machine check interrupt to the e500 core. Note that if the e500 core is not configured to process machine check interrupts, the assertion of SRESET causes a core checkstop. SRESET need not be asserted during a hard reset." Is the 85xx kernel "not configured to process machine check interrupts" ? Do I need to do that myself in my boards restart function via the special registers? Is there code already for this? Robert ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Latest paulus.git PCI broken on mpc8540?
On Nov 15, 2007, at 11:35 PM, Benjamin Herrenschmidt wrote: > > On Thu, 2007-11-15 at 22:37 -0600, Kumar Gala wrote: >>> PCI: Probing PCI hardware >>> PCI: Cannot allocate resource region 0 of device :00:12.0 >>> PCI: Cannot allocate resource region 1 of device :00:12.0 >>> PCI: Cannot allocate resource region 2 of device :00:12.0 >>> PCI: Cannot allocate resource region 3 of device :00:12.0 >>> PCI: Cannot allocate resource region 4 of device :00:12.0 >>> PCI: Cannot allocate resource region 0 of device :00:14.0 >>> PCI: Cannot allocate resource region 2 of device :00:14.0 >> >> this isn't really an error. Its more of a warning, the kernel will >> try and allocate these later and I'm guessing based on what you are >> seeing it succeeded. >> >> Benh, can we possibly change these messages in pci_32.c? > > Heh, well, I've been working on 44x PCI lately and got annoyed by the > exact same messages, though I'm still pondering what would be a better > replacement. Well, for one the generic pci code will complain if its not able to allocate the resource which is the true failure. I'm thinking maybe we just make these pr_debug() instead of standard printk? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Kexec on powerpc
On Thu, Nov 15, 2007 at 01:14:27PM +, [EMAIL PROTECTED] wrote: > I'm using the latest kernel and I need the kexec support for 85xx > processor. When I use the menuconfig with ARCH=ppc and the 85xx and > e500 support, I have the kexec support, but when I use ARCH=powerpc I > haven't it, but I'm selecting the same processor!! Is it a bug in > kconfig? Somebody can explain to me why? I don't think kexec works for ppc-32 arch/powerpc at the present. We have been working on kexec/kdump support for 32-bit arch/powerpc. It requires changes both to the kernel and to the kexec-tools package. I plan to post a first round of patches to linuxppc-dev early next week. -Dale Farnsworth ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx software reset problems from paulus.git
Hello, Robert! robert lazarski schrieb: > Hi all, on my custom 85xx board I can't do a soft reset. I'm using > u-boot 1.3rc3 that has the latest cpu/mpc85xx/cpu.c patch to fix some > type of reset problem. When I press the software reset button on my > board after my nfs kernel panic, I get this: Please define "software reset button" in your case. :-) I consider a "button" clearly as hardware. In my case (my button) asserts the HRESET# CPU pin low. As far as I understood the details (not verified again): To trigger a hard reset via software, the CPU (8540 at least) should assert the HRESET_REQ# (Pin AG20) low (which needs to be triggered in software, somehow). Some external glue logic should then issue the HRESET# (pin AH16) low to reset the CPU (hard, Power On Reset). The SRESET# (pin AF20) is the soft reset input, causes an mcp assertion to the core (RTFM) So, the detailed explanation seems to be implementation specific (if HRESET_REQ# can get triggered and if HRESET_REQ# assertion is glued to assert HRESET# from the HW guys). > Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(2,0) > Rebooting in 10 seconds..Machine check in kernel mode. > Caused by (from MCSR=8000): Machine Check Signal > Oops: Machine check, sig: 7 [#1] > MPC85xx CDS > NIP: c00131f8 LR: c0014060 CTR: c00230dc > REGS: c0289f50 TRAP: 0202 Not tainted (2.6.24-rc2-ge6a5c27f-dirty) > MSR: 00021000 CR: 2428 XER: 2000 > TASK = c102[1] 'swapper' THREAD: c1022000 > GPR00: 0002 c1023e30 c102 0686 0047 c1023e38 > > GPR08: 7e58da6f f1b0 003d0900 c0281ec8 4488 7fffa7e3 3ffefb00 > 0080 > GPR16: 007fff00 c022 c026 c026 > 3ffeb254 > GPR24: c026 c028 c0219f84 c029 2710 c026 > > NIP [c00131f8] fsl_rstcr_restart+0x20/0x24 > LR [c0014060] mpc85xx_cds_restart+0x78/0x8c > Call Trace: > [c1023e30] [c0014008] mpc85xx_cds_restart+0x20/0x8c (unreliable) > [c1023e50] [c000c894] machine_restart+0x34/0x48 > [c1023e60] [c0031f9c] emergency_restart+0x14/0x24 > [c1023e70] [c00234e8] panic+0x134/0x174 > [c1023f00] [c0242d5c] mount_block_root+0x108/0x24c > [c1023f50] [c02431c0] prepare_namespace+0xd0/0x210 > [c1023f70] [c0242938] kernel_init+0x170/0x290 > [c1023ff0] [c000d2dc] kernel_thread+0x44/0x60 > Instruction dump: > 80010014 38210010 7c0803a6 4e800020 7c000146 3d20c029 8129821c 2f89 > 419e0010 3802 7c0004ac 9009 <4800> 81230044 8009003c 70090008 > Kernel panic - not syncing: Attempted to kill init! > Rebooting in 10 seconds.. > > I believe Clemens recently confirmed the same issue. Any ideas? > Robert Not really. I just can confirm that the a $shutdown -r now doesn't reboot my board anymore whereas 2.6.21-rc4 did. IIRC, I've seen a patch which changed some instructions in some reboot() function some time ago. (Please note, I'm using the mpc8540_ads which might be slightly different from the *_cds.) Regards, Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
85xx software reset problems from paulus.git
Hi all, on my custom 85xx board I can't do a soft reset. I'm using u-boot 1.3rc3 that has the latest cpu/mpc85xx/cpu.c patch to fix some type of reset problem. When I press the software reset button on my board after my nfs kernel panic, I get this: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) Rebooting in 10 seconds..Machine check in kernel mode. Caused by (from MCSR=8000): Machine Check Signal Oops: Machine check, sig: 7 [#1] MPC85xx CDS NIP: c00131f8 LR: c0014060 CTR: c00230dc REGS: c0289f50 TRAP: 0202 Not tainted (2.6.24-rc2-ge6a5c27f-dirty) MSR: 00021000 CR: 2428 XER: 2000 TASK = c102[1] 'swapper' THREAD: c1022000 GPR00: 0002 c1023e30 c102 0686 0047 c1023e38 GPR08: 7e58da6f f1b0 003d0900 c0281ec8 4488 7fffa7e3 3ffefb00 0080 GPR16: 007fff00 c022 c026 c026 3ffeb254 GPR24: c026 c028 c0219f84 c029 2710 c026 NIP [c00131f8] fsl_rstcr_restart+0x20/0x24 LR [c0014060] mpc85xx_cds_restart+0x78/0x8c Call Trace: [c1023e30] [c0014008] mpc85xx_cds_restart+0x20/0x8c (unreliable) [c1023e50] [c000c894] machine_restart+0x34/0x48 [c1023e60] [c0031f9c] emergency_restart+0x14/0x24 [c1023e70] [c00234e8] panic+0x134/0x174 [c1023f00] [c0242d5c] mount_block_root+0x108/0x24c [c1023f50] [c02431c0] prepare_namespace+0xd0/0x210 [c1023f70] [c0242938] kernel_init+0x170/0x290 [c1023ff0] [c000d2dc] kernel_thread+0x44/0x60 Instruction dump: 80010014 38210010 7c0803a6 4e800020 7c000146 3d20c029 8129821c 2f89 419e0010 3802 7c0004ac 9009 <4800> 81230044 8009003c 70090008 Kernel panic - not syncing: Attempted to kill init! Rebooting in 10 seconds.. I believe Clemens recently confirmed the same issue. Any ideas? Robert ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Virtex TEMAC ping -s 10000 host, is it working?
alex_snippet wrote: > > Hi All! > > On Virtex 4FX board with TEMAC core, Linux ping working fine, but if s - > parameter set to big values it freezes for ever... > > Colleagues please share your experience with ping -s 1 host. > > Do you know what parameters in core or in Linux kernel must be changed to > improve it. > > My customer is too hypercritical, he likes to ping :( > > I tried to increase LX/TX buffers in core, it increased dead line but > there is no desirable result. > > > Hey, I can understand that customer, I like pinging as well. And it works for me. Our design is based on ML403. We use PLB_TEMAC (with minimum Fifos (4kB each)) and HardTEMAC > . > . > . > 10008 bytes from 192.168.0.206: icmp_seq=733 ttl=64 time=2.42 ms > 10008 bytes from 192.168.0.206: icmp_seq=734 ttl=64 time=2.50 ms > 10008 bytes from 192.168.0.206: icmp_seq=735 ttl=64 time=2.43 ms > 10008 bytes from 192.168.0.206: icmp_seq=736 ttl=64 time=2.43 ms > 10008 bytes from 192.168.0.206: icmp_seq=737 ttl=64 time=2.44 ms > 10008 bytes from 192.168.0.206: icmp_seq=738 ttl=64 time=2.42 ms > 10008 bytes from 192.168.0.206: icmp_seq=739 ttl=64 time=2.51 ms > 10008 bytes from 192.168.0.206: icmp_seq=740 ttl=64 time=2.42 ms > 10008 bytes from 192.168.0.206: icmp_seq=741 ttl=64 time=2.50 ms > 10008 bytes from 192.168.0.206: icmp_seq=742 ttl=64 time=2.43 ms > . > . > . > And so on... > --- 192.168.0.206 ping statistics --- > 850 packets transmitted, 850 received, 0% packet loss, time 849010ms > rtt min/avg/max/mdev = 2.399/11.623/1001.859/92.782 ms, pipe 3 > -- View this message in context: http://www.nabble.com/Virtex-TEMAC-ping--s-1-host%2C-is-it-working--tf4812989.html#a13790720 Sent from the linuxppc-embedded mailing list archive at Nabble.com. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: hangs after "Freeing unused kernel memory"
Original-Nachricht
> Datum: Thu, 15 Nov 2007 16:00:09 -0800
> Von: "Siva Prasad" <[EMAIL PROTECTED]>
> An: linuxppc-embedded@ozlabs.org, [EMAIL PROTECTED]
> Betreff: hangs after "Freeing unused kernel memory"
> Hi,
>
> This sounds like a familiar problem, but could not get answers in posts
> that came up in google search.
Yes, this is a familiar problem, at least for me. :-)
> My system hangs after printing the message "Freeing unused kernel
> memory". It should execute init after that, but not sure what exactly is
> happening. Appreciate if some one can throw few ideas to try out.
>
> Seems it is actually hanging when it makes the call "
> run_init_process(ramdisk_execute_command)" in init/main.c
On my machine it hangs after returning from kernel_execve()/do_execve(),
which is called by run_init_process("/sbin/init"). So the problem can be
almost anywhere. The problem appeared first on kernel 2.6.17. 2.6.16
worked fine on my machine.
I'm going to try out git-bisect on these two kernel revisions, now that I
figured out what people mean when they talk about bisecting. :-) I just
have to figure out how to merge my patches with every branch that is
checked out by git-bisect.
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für 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
