arch/powerpc 440GX external IRQ
Hi, Does anyone have these working and/or is able to talk me through the DTS structure for them please ? I have a 440GX board that works fine under arch/ppc with external IRQ4,5,6 however I cannot get it correct in the DTS, I think I am not correctly specifying the cascade of the UIC ? I started off using the Taishan DTS as a template as that seems to be the only 440GX in powerpc/platforms and can get the board to boot, mount NFS etc. Thanks. Neil -- Neil Wilson Principal Engineer, Embedded Software Airspan Communications Ltd Cambridge House, Oxford Road Uxbridge, Middlesex, UB8 1UN, UK. +44(0)1895-467265 [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
83xx immap_qe.h - SIR type def error?
All Freescale,
Not sure if this is the place to post this, but I have run across what I
consider to be a possible type error in the immap_qe.h file, for the
asm/powerpc branch.
In the file immap_qe.h
/* SI Routing Tables */
struct sir {
u8 tx[0x400];
u8 rx[0x400];
u8 res0[0x800];
}
Shouldn't these types be defined as __be16 ?
According to the Freescale manual this is a 16 bit field, not an 8-bit
field.
Spent an hour trying to figure out why I couldn't fill this field out with
upper 8 bits last night.
Thoughts?
Russell McGuire
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
AW: External Interrupt
Marco, ASFAIK there where some changes and you have to get the irq with irq_create_mapping() or irq_of_parse_and_map() Kindly regards Hans Mit freundlichen Grüßen Hans Lehmann Dipl.-Ing. Elektrotechnik RITTER Elektronik GmbH Leverkuser Strasse 65 D-42897 Remscheid Tel.+49 (0) 2191 - 67 32 40 Fax +49 (0) 2191 - 67 14 29 Email [EMAIL PROTECTED] Homepage www.ritter-elektronik.de Geschäftsführer: Manfred A. Wagner, Dr. Uwe Baader Sitz der Gesellschaft: Oberhausen HRB 17168 DuisburgUSt-ID DE 814009849 -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Marco Stornelli Gesendet: Freitag, 1. Februar 2008 09:11 An: Linuxppc Embedded Mailing List Betreff: External Interrupt Hi, I used the linux kernel 2.6.10 with a processor MPC8548E. I wrote a driver for a device connected with the local bus. This device has an external interrupt. In the local bus driver I have used the macro MPC85xx_IRQ_EXTX to get the interrupt number and pass it to the driver and after that register the ISR. Now with a kernel 2.6.21 this macro isn't available because in the header file irq.h there is the option CONFIG_PPC_MERGE that disable those options. I think this problem is related to the migration of ppc code towards powerpc. I know that now there is the new device tree source file where I can add a device and its interrupt number but I think in this file I should describe only the platform device, and this device is not a platform device. Then, how can I get now this value? Is there some function to call? How can I perform this operation? Thanks in advance. Marco ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: External Interrupt
Marco Stornelli wrote: Hi, I used the linux kernel 2.6.10 with a processor MPC8548E. I wrote a driver for a device connected with the local bus. This device has an external interrupt. In the local bus driver I have used the macro MPC85xx_IRQ_EXTX to get the interrupt number and pass it to the driver and after that register the ISR. Now with a kernel 2.6.21 this macro isn't available because in the header file irq.h there is the option CONFIG_PPC_MERGE that disable those options. I think this problem is related to the migration of ppc code towards powerpc. I know that now there is the new device tree source file where I can add a device and its interrupt number but I think in this file I should describe only the platform device, and this device is not a platform device. How comes that it's not platform device if it hangs off the local bus? Then, how can I get now this value? Is there some function to call? How can I perform this operation? Probably irq_alloc_virt()... ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: External Interrupt
Hello. Marco Stornelli wrote: I used the linux kernel 2.6.10 with a processor MPC8548E. I wrote a driver for a device connected with the local bus. This device has an external interrupt. In the local bus driver I have used the macro MPC85xx_IRQ_EXTX to get the interrupt number and pass it to the driver and after that register the ISR. Now with a kernel 2.6.21 this macro isn't available because in the header file irq.h there is the option CONFIG_PPC_MERGE that disable those options. I think this problem is related to the migration of ppc code towards powerpc. I know that now there is the new device tree source file where I can add a device and its interrupt number but I think in this file I should describe only the platform device, and this device is not a platform device. How comes that it's not platform device if it hangs off the local bus? Then, how can I get now this value? Is there some function to call? How can I perform this operation? Probably irq_alloc_virt()... WBR, Sergei ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: External Interrupt
Sergei Shtylyov ha scritto: Marco Stornelli wrote: Hi, I used the linux kernel 2.6.10 with a processor MPC8548E. I wrote a driver for a device connected with the local bus. This device has an external interrupt. In the local bus driver I have used the macro MPC85xx_IRQ_EXTX to get the interrupt number and pass it to the driver and after that register the ISR. Now with a kernel 2.6.21 this macro isn't available because in the header file irq.h there is the option CONFIG_PPC_MERGE that disable those options. I think this problem is related to the migration of ppc code towards powerpc. I know that now there is the new device tree source file where I can add a device and its interrupt number but I think in this file I should describe only the platform device, and this device is not a platform device. How comes that it's not platform device if it hangs off the local bus? In SoC system generally the platform device are (more or less) the microprocessor controller like i2c, pci, local bus itself and so on. I think is like if you consider a PCI board a platform device only because it hangs off the PCI link. Then, how can I get now this value? Is there some function to call? How can I perform this operation? Probably irq_alloc_virt()... ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reminder: removal of arch/ppc
On Thu, 31 Jan 2008 15:54:46 -0700 Mark A. Greer [EMAIL PROTECTED] wrote: On Fri, Jan 25, 2008 at 10:55:25AM -0600, Kumar Gala wrote: Just a reminder that the plan is to remove arch/ppc this summer (June 2008). The following boards still existing over in arch/ppc. Some of them have been ported over to arch/powerpc. If you care about one of these boards and its not ported speak up (it helps if you have access to the board). Also, if you know a given board is free to die of bitrot let us know so we know not to worry about it: I guess I'm just not a nice guy but I say let them die. No need to worry. The code really isn't going anywhere -- git-checkout v2.6.pick your favorite version and its back. You're a nice guy. You just aren't as much of a masochist as the rest of us I guess. ;) josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 83xx immap_qe.h - SIR type def error?
On Feb 1, 2008, at 5:47 AM, Russell McGuire wrote:
All Freescale,
Not sure if this is the place to post this, but I have run across
what I
consider to be a possible type error in the immap_qe.h file, for the
asm/powerpc branch.
In the file immap_qe.h
/* SI Routing Tables */
struct sir {
u8 tx[0x400];
u8 rx[0x400];
u8 res0[0x800];
}
Shouldn't these types be defined as __be16 ?
According to the Freescale manual this is a 16 bit field, not an 8-bit
field.
Spent an hour trying to figure out why I couldn't fill this field
out with
upper 8 bits last night.
Thoughts?
I'm guessing it was done this way since they are just looked as base
offsets. Where in the UM do you see anything about them being 16-bit
quantities? (I'm really know little about this).
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: External Interrupt
Marco Stornelli wrote: I used the linux kernel 2.6.10 with a processor MPC8548E. I wrote a driver for a device connected with the local bus. This device has an external interrupt. In the local bus driver I have used the macro MPC85xx_IRQ_EXTX to get the interrupt number and pass it to the driver and after that register the ISR. Now with a kernel 2.6.21 this macro isn't available because in the header file irq.h there is the option CONFIG_PPC_MERGE that disable those options. I think this problem is related to the migration of ppc code towards powerpc. I know that now there is the new device tree source file where I can add a device and its interrupt number but I think in this file I should describe only the platform device, and this device is not a platform device. How comes that it's not platform device if it hangs off the local bus? In SoC system generally the platform device are (more or less) the microprocessor controller like i2c, pci, local bus itself and so on. That's SoC devices but the notion of the platform device is not limited to SoC device only, rather to all the on-board devices. I think is like if you consider a PCI board a platform device only because it hangs off the PCI link. No. PCI devices are detectable/configurable by kernel -- even if they are on-board chips, they can be found by PCI bus scan (and finally presented as the device nodes as well), while local bus devices (most probably) not. An example (that comes to mind) of a device hanging off the local bus and yet described by the device tree are the flash chips. WBR, Sergei ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: External Interrupt
Sergei Shtylyov ha scritto: Marco Stornelli wrote: I used the linux kernel 2.6.10 with a processor MPC8548E. I wrote a driver for a device connected with the local bus. This device has an external interrupt. In the local bus driver I have used the macro MPC85xx_IRQ_EXTX to get the interrupt number and pass it to the driver and after that register the ISR. Now with a kernel 2.6.21 this macro isn't available because in the header file irq.h there is the option CONFIG_PPC_MERGE that disable those options. I think this problem is related to the migration of ppc code towards powerpc. I know that now there is the new device tree source file where I can add a device and its interrupt number but I think in this file I should describe only the platform device, and this device is not a platform device. How comes that it's not platform device if it hangs off the local bus? In SoC system generally the platform device are (more or less) the microprocessor controller like i2c, pci, local bus itself and so on. That's SoC devices but the notion of the platform device is not limited to SoC device only, rather to all the on-board devices. I think is like if you consider a PCI board a platform device only because it hangs off the PCI link. No. PCI devices are detectable/configurable by kernel -- even if they are on-board chips, they can be found by PCI bus scan (and finally presented as the device nodes as well), while local bus devices (most probably) not. An example (that comes to mind) of a device hanging off the local bus and yet described by the device tree are the flash chips. Yes you are right. The local bus is like i2c, but I've never seen a device connected with i2c and described with a sub-node of i2c node in the dts file, however I think it's only philosophy, the most important thing is that there is a way to get the irq number :) Thanks for your response. Regards. Marco WBR, Sergei ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reminder: removal of arch/ppc
On Thu, Jan 31, 2008 at 09:33:09PM -0600, Kumar Gala wrote: On Jan 31, 2008, at 4:54 PM, Mark A. Greer wrote: On Fri, Jan 25, 2008 at 10:55:25AM -0600, Kumar Gala wrote: Just a reminder that the plan is to remove arch/ppc this summer (June 2008). The following boards still existing over in arch/ppc. Some of them have been ported over to arch/powerpc. If you care about one of these boards and its not ported speak up (it helps if you have access to the board). Also, if you know a given board is free to die of bitrot let us know so we know not to worry about it: I guess I'm just not a nice guy but I say let them die. No need to worry. The code really isn't going anywhere -- git-checkout v2.6.pick your favorite version and its back. /me's $0.02. this is where I poke you about the sandpoint port ;) Heh, I know, I know. jdl was asking me about it a few days ago too. I haven't forgotten, it just never makes it to the top of my stack. RSN tho... :) ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
8360 custom board, ucc_geth TX errors on longer(?) packets
Hi All: For our custom 8360-based board that is based fairly closely on the MPC8360-MDS board, I'm working on moving from a 2.6.16 kernel (Timesys distro) to 2.6.24. I didn't use the device tree in my old kernel, so I've had the learning experience of tweaking the dts file for my custom board. I've got it 99% working (I think!). But I'm running into a really odd ethernet problem that I don't understand. I have two boards: our custom 8360 board, and a MPC8360E-MDS dev board.I can build a kernel for the MDS board and ethernet works perfectly.When I build that kernel using the same config, but changing the platform to my custom board (and not changing any other options), everything works right except for ethernet:it won't get an IP address using DHCP (udhcpc)...I check the ifconfig output, and I see that the TX error count is increasing, and there are very few TX packets being sent. I verified that this isn't a timeout-- it's being caused by the UCCE[TXE] bit being set (I don't see any other error indications in dmesg). As another test, I configured the address manually. When I do that, I can ping the board with a normal ping; but if I use the -s option to increase the packet size, then the pings will fail when I use a size of about 250 or greater, and with a size of about 300 or greater I get no successful ping packets. The one main difference in this board is how eth0 is wired. We have a Broadcom GbE switch part, and UCC1 eth is wired directly to that switch (no PHY). (This where I needed to use the fixed-link option that I had asked about a couple of days ago!). In my 2.6.16-based kernel, I had created a dummy null PHY to force the link speed to 1000, and that worked well.I am using the same Broadcom network switch software with both kernels, so the switch side of the config should be the same. I created my custom board config from the MPC8360E-MDS board configs (starting with that defconfig, dts, and platform .c file), and matched my GPIO pin configs in the dtb file to what I had used in the 2.6.16 kernel.. I'm not sure where to look for this problem, as I've never seen UCCE[TXE] set before.Based on my experience in this move so far, I'd guess that I've got something configured wrong somewhere, but I just don't know where to look. Does anyone have any ideas/suggestions? Any help would be MUCH appreciated!! Thanks, Steve -- Steve Hein ([EMAIL PROTECTED]) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: External Interrupt
Marco Stornelli wrote: Yes you are right. The local bus is like i2c, but I've never seen a device connected with i2c and described with a sub-node of i2c node in the dts file, Grep the dts directory for [EMAIL PROTECTED]. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 8360 custom board, ucc_geth TX errors on longer(?) packets
On Fri, 01 Feb 2008 12:52:25 -0600 Steven Hein [EMAIL PROTECTED] wrote: The one main difference in this board is how eth0 is wired. We have a Broadcom GbE switch part, and UCC1 eth is wired directly to that switch (no PHY). (This where I needed to sounds like you ran into some h/w errata. if on rgmii, you might want to find a way to program the switch for rgmii with internal delay (8360 rev.2 rgmii-id rx tx; 8360rev2.1 rgmii-rxid (i.e. for rx only)). If not, I'd contact fsl tech support directly. Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: 83xx immap_qe.h - SIR type def error?
Kumar,
Yes in the main memeory map they are just listed as 1K RAM blocks.
However, in the UM Section 36.6.1 pg 36-12 or pg 1728 in the PDF.
It gives the breakout for the RAM, which clearly indicates 16 bit fields.
Here is a short clip from Figure 36-8
Access: Read/Write
0 1 2 3 4 5 6 7 10 11 13 14 15
MCC SWTR SSEL 1 SSEL 2 SSEL 3 SSEL 4 SGS CSEL CNT BYT LST
Figure 36-8. SI RAM Entry for UCC
Honest, mistake as if I were writing the header file I'd not have time to
ready all 2000+ pages of the UM. We find these only as somebody goes in an
tries to use them.
And I am guessing not a lot of customers use the SI block.
-Russ
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Friday, February 01, 2008 6:56 AM
To: [EMAIL PROTECTED]
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 83xx immap_qe.h - SIR type def error?
On Feb 1, 2008, at 5:47 AM, Russell McGuire wrote:
All Freescale,
Not sure if this is the place to post this, but I have run across
what I
consider to be a possible type error in the immap_qe.h file, for the
asm/powerpc branch.
In the file immap_qe.h
/* SI Routing Tables */
struct sir {
u8 tx[0x400];
u8 rx[0x400];
u8 res0[0x800];
}
Shouldn't these types be defined as __be16 ?
According to the Freescale manual this is a 16 bit field, not an 8-bit
field.
Spent an hour trying to figure out why I couldn't fill this field
out with
upper 8 bits last night.
Thoughts?
I'm guessing it was done this way since they are just looked as base
offsets. Where in the UM do you see anything about them being 16-bit
quantities? (I'm really know little about this).
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: 83xx immap_qe.h - SIR type def error?
I should state, I am looking at the MPC8360ERM.pdf Rev 2.0
-Russ
-Original Message-
From: Russell McGuire [mailto:[EMAIL PROTECTED]
Sent: Friday, February 01, 2008 1:03 PM
To: 'Kumar Gala'
Cc: 'linuxppc-embedded@ozlabs.org'
Subject: RE: 83xx immap_qe.h - SIR type def error?
Kumar,
Yes in the main memeory map they are just listed as 1K RAM blocks.
However, in the UM Section 36.6.1 pg 36-12 or pg 1728 in the PDF.
It gives the breakout for the RAM, which clearly indicates 16 bit fields.
Here is a short clip from Figure 36-8
Access: Read/Write
0 1 2 3 4 5 6 7 10 11 13 14 15
MCC SWTR SSEL 1 SSEL 2 SSEL 3 SSEL 4 SGS CSEL CNT BYT LST
Figure 36-8. SI RAM Entry for UCC
Honest, mistake as if I were writing the header file I'd not have time to
ready all 2000+ pages of the UM. We find these only as somebody goes in an
tries to use them.
And I am guessing not a lot of customers use the SI block.
-Russ
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Friday, February 01, 2008 6:56 AM
To: [EMAIL PROTECTED]
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 83xx immap_qe.h - SIR type def error?
On Feb 1, 2008, at 5:47 AM, Russell McGuire wrote:
All Freescale,
Not sure if this is the place to post this, but I have run across
what I
consider to be a possible type error in the immap_qe.h file, for the
asm/powerpc branch.
In the file immap_qe.h
/* SI Routing Tables */
struct sir {
u8 tx[0x400];
u8 rx[0x400];
u8 res0[0x800];
}
Shouldn't these types be defined as __be16 ?
According to the Freescale manual this is a 16 bit field, not an 8-bit
field.
Spent an hour trying to figure out why I couldn't fill this field
out with
upper 8 bits last night.
Thoughts?
I'm guessing it was done this way since they are just looked as base
offsets. Where in the UM do you see anything about them being 16-bit
quantities? (I'm really know little about this).
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Enabling MSR debugging mode on MPC8541cds
Hi All, I am working on powerpc git tree version Linux-2.6.22-rc4-geff2ebd2-dirty. Our custom board is based on mpc8541cds. I am trying to use Jtag to debug the kernel issues. I have done the following changes to the source tree: On the top directory Makefile: CC= $(CROSS_COMPILE)gcc -g2 -gdwarf-2 AFLAG_KERNEL = -Wa,gdwarf2 include/asm-powerpc/reg_booke.h: /* Default MSR for kernel mode. */ #if defined (CONFIG_40x) #define MSR_KERNEL (MSR_ME|MSR_RI|MSR_IR|MSR_DR|MSR_CE|MSR_DE) #elif defined(CONFIG_BOOKE) #define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE|MSR_DE) However, I can see through Jtag that the MSR_DE (the debug bit) is not set on the, so I am not able to set break points. Any help greatly appreciated. Regards, Bizhan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 8360 custom board, ucc_geth TX errors on longer(?) packets
Steven Hein wrote: Kim Phillips wrote: On Fri, 01 Feb 2008 12:52:25 -0600 Steven Hein [EMAIL PROTECTED] wrote: The one main difference in this board is how eth0 is wired. We have a Broadcom GbE switch part, and UCC1 eth is wired directly to that switch (no PHY). (This where I needed to sounds like you ran into some h/w errata. if on rgmii, you might want to find a way to program the switch for rgmii with internal delay (8360 rev.2 rgmii-id rx tx; 8360rev2.1 rgmii-rxid (i.e. for rx only)). If not, I'd contact fsl tech support directly. Kim I would suspect HW.but this WORKS with the 2.6.16 kernel I was using!That's why I suspect that I still don't have something configured right in my device tree, or something else I missed in the new kernel.But I can't figure out what it is :-(I've poured over the code in the old versus new (both the ucc_geth driver and the platform initialization in the old, and the device tree in the new) and can't figure out what I missed! And like I said, a kernel with the same config (other than changing the platform) works on my MPC8360E-MDS board. Granted, that doesn't have this direct switch connection.. I did look at the code related to the HW errata (QE_ENET18). But we're using GMII to the switchand that workaround code wasn't in active in my old kernel (it was there, but commented out). Any other thoughts?Has anyone seen this symptom before? Steve OkayI found it!Started poking at the UCCE registers and found that the FIFO sizes weren't right. This led me to find a bug in my ucc_geth interface to the fixed-link PHY driver: the code to reconfigure the MURAM FIFO's for Gigabit operation wasn't being executed for no-phy configs! All is well once I changed this. Sorry for the noise. (glad I found this before submitting my patch! ;-) Steve -- Steve Hein ([EMAIL PROTECTED]) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 8360 custom board, ucc_geth TX errors on longer(?) packets
On Fri, 01 Feb 2008 16:06:15 -0600 Steven Hein [EMAIL PROTECTED] wrote: Steven Hein wrote: But we're using GMII to the switchand that workaround code wasn't in active in my old kernel (it was there, but commented out). Any other thoughts?Has anyone seen this symptom before? Steve OkayI found it!Started poking at the UCCE registers and found that the FIFO sizes weren't right. This led me to find a bug in my ucc_geth interface to the fixed-link PHY driver: the code to reconfigure the MURAM FIFO's for Gigabit operation wasn't being executed for no-phy configs! All is well once I changed this. Sorry for the noise. (glad I found this before submitting my patch! ;-) yeah ucc_geth should be made aware of fixed-links on startup; UCCs aren't like TSECs that know what MII type they're on. setting phy-connection-type to certain strings containing a 'g' in the device tree should do the trick, too..:) Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
build is broken
Hi I just downloaded the latest source tree from : git://www.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git I am using gnu cross compiler version 3.4.3. I get the an awk and assmbeler error. Please help me out. Thanks $ mailto:[EMAIL PROTECTED] make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- uImage awk: cmd. line:1: (FILENAME=- FNR=2) fatal: attempt to access field -1 CHK include/linux/version.h CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh CHK include/linux/compile.h CALLarch/powerpc/kernel/systbl_chk.sh LD vmlinux.o MODPOST vmlinux.o WARNING: vmlinux.o(.meminit.text+0x9f8): Section mismatch in reference from the function free_area_init_node() to the function .init.text:__alloc_bootmem_node() The function __meminit free_area_init_node() references a function __init __alloc_bootmem_node(). If free_area_init_node is only used by __alloc_bootmem_node then annotate free_area_init_node with a matching annotation. AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map BOOTCC arch/powerpc/boot/treeboot-walnut.o Assembler messages: Error: Internal assembler error for instruction icbt Internal error, aborting at /usr/src/RPM/BUILD/crosstool/source/binutils-2.15/gas/config/tc-ppc.c line 1300 in ppc_setup_opcodes Please report this bug. make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2 make: *** [uImage] Error 2 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: build is broken
On Fri, 1 Feb 2008 15:23:21 -0800 Bizhan Gholikhamseh (bgholikh) [EMAIL PROTECTED] wrote: Hi I just downloaded the latest source tree from : git://www.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git I am using gnu cross compiler version 3.4.3. I get the an awk and assmbeler error. Please help me out. Thanks $ mailto:[EMAIL PROTECTED] make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- uImage awk: cmd. line:1: (FILENAME=- FNR=2) fatal: attempt to access field -1 CHK include/linux/version.h CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh CHK include/linux/compile.h CALLarch/powerpc/kernel/systbl_chk.sh LD vmlinux.o MODPOST vmlinux.o WARNING: vmlinux.o(.meminit.text+0x9f8): Section mismatch in reference from the function free_area_init_node() to the function .init.text:__alloc_bootmem_node() The function __meminit free_area_init_node() references a function __init __alloc_bootmem_node(). If free_area_init_node is only used by __alloc_bootmem_node then annotate free_area_init_node with a matching annotation. AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map BOOTCC arch/powerpc/boot/treeboot-walnut.o Assembler messages: Error: Internal assembler error for instruction icbt Internal error, aborting at /usr/src/RPM/BUILD/crosstool/source/binutils-2.15/gas/config/tc-ppc.c line 1300 in ppc_setup_opcodes Please report this bug. make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2 make: *** [uImage] Error 2 I have no idea why you would get that if you have a properly built toolchain. Can you do a fresh compile with V=1 set? josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: build is broken
-Original Message- From: Josh Boyer [mailto:[EMAIL PROTECTED] Sent: Friday, February 01, 2008 7:24 PM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded@ozlabs.org Subject: Re: build is broken On Fri, 1 Feb 2008 15:23:21 -0800 Bizhan Gholikhamseh (bgholikh) [EMAIL PROTECTED] wrote: Hi I just downloaded the latest source tree from : git://www.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git I am using gnu cross compiler version 3.4.3. I get the an awk and assmbeler error. Please help me out. Thanks $ mailto:[EMAIL PROTECTED] make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- uImage awk: cmd. line:1: (FILENAME=- FNR=2) fatal: attempt to access field -1 CHK include/linux/version.h CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh CHK include/linux/compile.h CALLarch/powerpc/kernel/systbl_chk.sh LD vmlinux.o MODPOST vmlinux.o WARNING: vmlinux.o(.meminit.text+0x9f8): Section mismatch in reference from the function free_area_init_node() to the function .init.text:__alloc_bootmem_node() The function __meminit free_area_init_node() references a function __init __alloc_bootmem_node(). If free_area_init_node is only used by __alloc_bootmem_node then annotate free_area_init_node with a matching annotation. AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map BOOTCC arch/powerpc/boot/treeboot-walnut.o Assembler messages: Error: Internal assembler error for instruction icbt Internal error, aborting at /usr/src/RPM/BUILD/crosstool/source/binutils-2.15/gas/config/tc-ppc.c line 1300 in ppc_setup_opcodes Please report this bug. make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2 make: *** [uImage] Error 2 I have no idea why you would get that if you have a properly built toolchain. Can you do a fresh compile with V=1 set? josh I did the fresh build with V=1. I still get the same awk error and the compile's last line output: powerpc-linux-gnuspe-gcc -m32 -Wp,-MD,arch/powerpc/boot/.treeboot-walnut.o.d -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -msoft-float -pipe -fomit-frame-pointer -fno-builtin -fPIC -nostdinc -isystem /opt/Embedix/usr/local/powerpc-linux-gnuspe/gcc-3.4.3-e500-glibc-2.3.3-s pe/lib/gcc/powerpc-linux-gnuspe/3.4.3/include -Iarch/powerpc/boot -I/home/bizhan/PPC/arch/powerpc/boot -I/home/bizhan/PPC/arch/powerpc/boot/libfdt -mcpu=405 -c -o arch/powerpc/boot/treeboot-walnut.o arch/powerpc/boot/treeboot-walnut.c Assembler messages: Error: Internal assembler error for instruction icbt Internal error, aborting at /usr/src/RPM/BUILD/crosstool/source/binutils-2.15/gas/config/tc-ppc.c line 1300 in ppc_setup_opcodes Please report this bug. make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2 make: *** [uImage] Error 2 Any help greatly apprieciated. Thanks, Bizhan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
