Problem in configuring interrupt in PPC 8272 processor using montavista linux 2.6 kernel
Hi All I am facing problem in configuring PPC 8272 processor for interrupt . The zeroth bit of SIUMCR register when set with 1 will be configured for IRQ3 else will be configured with BBD. Even though i am writing 1 to this bit while inserting the driver and its actually writing 1 to that location either , but the IRQ3 is not been configured for that and hence is configured for BBD (BBD and IRQ3 are multiplexed) the result is that the bus is toggling . As a consiguence of this my driver is getting infinite interrupt and it is going to deadlock . If you have an experience of such problem ,i wish you could suggest me . Hoping for a reply , for that i shall rema in thankful to you . regard Misbah -- View this message in context: http://www.nabble.com/Problem-in-configuring-interrupt-in-PPC-8272-processor-using-montavista-linux-2.6-kernel-tf3992552.html#a11337419 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: ARCH=ppc or ARCH=powerpc
On Wed, Jun 27, 2007 at 08:20:28PM -0500, Kumar Gala wrote: On Jun 27, 2007, at 4:41 PM, Bizhan Gholikhamseh ((bgholikh)) wrote: Here are my questions: 1- Should I use ARCH=ppc or ARCH=powerpc to build the kernel? Move to ARCH=powerpc. Would that advice be specific to the MPC8541E? Encountering a kernel build error with ARCH=ppc, after configuring as much as possible for MPC8248, I've just tried ARCH=powerpc on linux-2.6.21.5, with this slightly scary result: There is no help available for this kernel option. Symbol: EMBEDDED6xx [=n] Prompt: Embedded 6xx/7xx/7xxx-based board Defined at arch/powerpc/Kconfig:384 Depends on: choice PPC32 (BROKEN || BROKEN_ON_SMP) Location: - Platform support - Machine type (choice [=y]) (Note: MPC8248 fits in the 6xx group, architecturally, AFAICT.) At least I can apply a patch (missing from current kernels), to fix the immediate MPC8248 problem in ARCH=ppc. For my case then, ARCH=ppc seems to offer more promise. Erik (At this early stage, trying to figure which way is up. :-) ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ARCH=ppc or ARCH=powerpc
On Thu, Jun 28, 2007 at 05:44:30PM +1000, Erik Christiansen wrote: Encountering a kernel build error with ARCH=ppc, after configuring as much as possible for MPC8248, I've just tried ARCH=powerpc on linux-2.6.21.5, with this slightly scary result: Oh dear. Please excuse the noise. That was clearly acute lack of familiarity with menuconfig. blush Minus fingerfumbling, ARCH=powerpc starts to build, before coughing up a bunch of compiler errors: cpm2_common.c:63: error: 'CPM_MAP_ADDR' undeclared Is that due to this patch not being accepted?: http://patchwork.ozlabs.org/linuxppc/patch?id=8891 If the patch's State Superseded means something else fixes the build failure, then how could I lay my grubby paws on that little gem? Erik ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
uncompressing zImage
I am unable to complete gunzip called from arch/ppc/boot/simple/misc.c. The gunzip code is in arch/ppc/boot/common/misc-common.c it is trying to do zalloc(). Here i am getting avail_ram greater than end_avail. So its stops executing further. I have my RAM from 0x to 0x0200. In this I had copied zImage at 0x0080. Now i am unable to continue from misc.c file's decompress algorithm. Please provide me some tips or suggestions. Thanks Regards, Sarpa -- View this message in context: http://www.nabble.com/uncompressing-zImage-tf3994018.html#a11341785 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
cuImage question
Hi All, I am kind of new to the concept of cuImage and I am not able to find any info on the net(?). We are using older version of the uboot: 1.1.2. I have compiled the latest kernel from git tree for MPC8541E from freescale. I would appreciate any hints on how to use 'cuImage to load this image with our legacy uboot version? Many thanks in advance, Bizhan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
mpc8270 Intel 82551ER on 2.6.17.14
I am having trouble getting two 82551ER Ethernet controllers running in Linux. I am able to scan the PCI bus and see the devices and I was even able to program the EEPROM from U-boot. In the kernel I mapped the IRQ's through /arch/ppc/m82xx_pci.c. I've been using the e100 drive that comes with the 2.6.17.14 kernel and have also tried the driver directly from Intel. Both give the same results. The PCI scan shows the correct output for how the device should be configured. The situation is when I use the ethtool with the driver loaded and eth0 not configured with ifconfig I get this: SCB Status Word (Lower Word) 0x RU Status: Idle CU Status: Idle Interrupts Pending Flow Control Pause:no Early Receive: no Software Generated Interrupt: no MDI Done: no RU Not In Ready State: no CU Not in Active State:no RU Received Frame: no CU Completed Command: no SCB Command Word (Upper Word)0x0100 RU Command: No Command CU Command: No Command Software Generated Interrupt: no Interrupts Masked ALL Interrupts:yes Flow Control Pause:no Early Receive: no RU Not In Ready State: no CU Not in Active State:no RU Received Frame: no CU Completed Command: no MDI/MDI-X Status:MDI With eth0 configured using the command ifconfig eth0 192.168.1.7 netmask 255.255.255.0 up I get this: SCB Status Word (Lower Word) 0x6450 RU Status: Ready CU Status: Suspended Interrupts Pending Flow Control Pause:no Early Receive: no Software Generated Interrupt: yes MDI Done: no RU Not In Ready State: no CU Not in Active State:yes RU Received Frame: yes CU Completed Command: no SCB Command Word (Upper Word)0x RU Command: No Command CU Command: No Command Software Generated Interrupt: no Interrupts Masked ALL Interrupts:no Flow Control Pause:no Early Receive: no RU Not In Ready State: no CU Not in Active State:no RU Received Frame: no CU Completed Command: no MDI/MDI-X Status:MDI If I issue a PING out of the port and sniff the traffic on the destination PC I see the ARP requests and I send the reply, but the embedded machine sees nothing. If I use ethtool or even ifconfig to view the statistics on the port they both show that there are no packets in or out. I have no idea where to go with this. It seems like the PCI bus is working, but possibly not the Interrupt handler. Nicholas Hickman Applications Engineer DTech Labs, Inc. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: cuImage question
On Jun 28, 2007, at 4:54 PM, Bizhan Gholikhamseh ((bgholikh)) wrote: Hi All, I am kind of new to the concept of cuImage and I am not able to find any info on the net(?). We are using older version of the uboot: 1.1.2. I have compiled the latest kernel from git tree for MPC8541E from freescale. I would appreciate any hints on how to use 'cuImage to load this image with our legacy uboot version? Take a look at arch/powerpc/boot/ and the Kconfig DEVICE_TREE option. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ARCH=ppc or ARCH=powerpc
On Jun 28, 2007, at 3:36 AM, Erik Christiansen wrote: On Thu, Jun 28, 2007 at 05:44:30PM +1000, Erik Christiansen wrote: Encountering a kernel build error with ARCH=ppc, after configuring as much as possible for MPC8248, I've just tried ARCH=powerpc on linux-2.6.21.5, with this slightly scary result: Oh dear. Please excuse the noise. That was clearly acute lack of familiarity with menuconfig. blush Minus fingerfumbling, ARCH=powerpc starts to build, before coughing up a bunch of compiler errors: cpm2_common.c:63: error: 'CPM_MAP_ADDR' undeclared Is that due to this patch not being accepted?: http://patchwork.ozlabs.org/linuxppc/patch?id=8891 If the patch's State Superseded means something else fixes the build failure, then how could I lay my grubby paws on that little gem? It probably means there was a newer version of the patch w/changes made to it based on feedback. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
