Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
On 07/12/2010 07:16 PM, Fushen Chen wrote: The DWC OTG driver module provides the initialization and cleanup entry points for the DWC OTG USB driver. Signed-off-by: Fushen Chen fc...@apm.com Signed-off-by: Mark Miesfeld mmiesf...@apm.com --- This reply is to the patch series, not just this 1/9 patch section. Fushen, why did you pick and choose which fixes to incorporate from the Denx tree's version of the dwc_otg driver? I'm not taking the time here to go through this multipart patch and check that you incorporated every fix, but I *did* randomly pick one fix that I made to that driver, to see if you incorporated it, and it appears you did not. I would have expected that you would have incorporated the fixes that were made to this driver in the Denx tree. The one that I checked is in the data toggle error interrupt handling, in handle_hc_chhltd_intr_dma() (see your 5/9 email in this patch series). It looks like you left out the fix I made to this logic that averts an interrupt storm. I assume that since I checked one particular fix, and it was missing from your patch series, that there are likely more fixes you omitted. Can you explain why you would leave this out, after Stefan asked you to incorporate the code changes made in the Denx tree's version of the driver? Chuck ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continuing UCC UART woes
One thing I noticed is that the firmware patch seems quite old. I got the firmware package from http://opensource.freescale.com/firmware/ We were also told (by FreeScale) to look at https://www.freescale.com/webapp/Download?colCode=QERAMPKG Looking at these two packages, it's unclear that they match. Certainly the dates are very different: [gtho...@hermes 8358]$ ls -l fsl_qe_ucode QERAMPKG fsl_qe_ucode: total 16 -rw-rw-r-- 1 gthomas gthomas 5940 2007-12-10 14:39 fsl_qe_ucode_uart_8360_21.bin -rw-r--r-- 1 gthomas gthomas 7892 2007-11-30 10:14 license.txt QERAMPKG: total 972 -rw-rw-r-- 1 gthomas gthomas 132915 2009-04-07 14:04 SlowProtocols_8323rev11.c -rw-rw-r-- 1 gthomas gthomas 455446 2009-09-16 15:44 Soft_UART_Microcode_Rel_0_1_2.pdf -rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:49 Soft_UART_mpc8360_r2.0.h -rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14 Soft_UART_mpc8360_r2.1.h -rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14 Soft_UART_mpc8568_r1.1.h -rw-rw-r-- 1 gthomas gthomas 105457 2009-09-16 16:00 SWUART_8360rev20.c -rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:32 SWUART_8360rev20.srx -rw-rw-r-- 1 gthomas gthomas 105318 2009-09-16 15:59 SWUART_8360rev21.c -rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:14 SWUART_8360rev21.srx Any ideas what I'm doing wrong? Hi Gary, At http://opensource.freescale.com/firmware there is a script make_qe_firmware.py that Timur said would create a firmware binary out of the firmware header file. I have not used this script, since the existing binary worked for me. But I am using only one UCC UART, so you are going beyond what I have done with this firmware. You can try to use that script to create a newer firmware binary from the header in that zip file. Make sure you are using the right one for your silicon rev. You can use strategic printk debugging in the ucc_uart.c driver to determine on the Tx side what is going wrong. For example, after you tell the QE to output chars, wait a bit and printk out the BD. See if the QE is clearing the READY bit in that BD. That will tell you if the QE is even processing the BD or not. Also ensure that for all these other UCCs that you are using that the CD, CTS, RTS pins are set up as plain GPIO pins if you do not have them hooked up to actual CD, CTS, RTS signals. If you *are* using HW flow control, probe all the signals to be sure they are all correct. Chuck ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continuing UCC UART woes
You can use strategic printk debugging in the ucc_uart.c driver to determine on the Tx side what is going wrong. For example, after you tell the QE to output chars, wait a bit and printk out the BD. See if the QE is clearing the READY bit in that BD. That will tell you if the QE is even processing the BD or not. I've also done this - the descriptors are set up, never touched by the QE Odd that input always works, output works only very rarely. You could check alignment of the BD address to be sure that got setup correctly. Make sure you are not looking at a cached version of the BD, and make sure you waited long enough for the QE to have processed it. Also ensure that for all these other UCCs that you are using that the CD, CTS, RTS pins are set up as plain GPIO pins if you do not have them hooked up to actual CD, CTS, RTS signals. If you *are* using HW flow control, probe all the signals to be sure they are all correct. No change whether these pins are configured or not. I would definitely leave these configured as GPIOs if the correct signals are not present at the pins. You could look through the pdf that is in that zipfile and make sure you are following (that the driver is following) all the restrictions for soft UART mode. Perhaps printk debug in ucc_slow_init to make sure the UCC is getting set up correctly. I would probably also make sure that the Tx parameter ram is allocated and aligned OK. Make sure you specify unique port-number fields in your dts for each of these UCC UARTs. Beyond that, if printk-debugging does not show anything, then you may want to contact Freescale and try to find out what the Soft UART mode microcode patch capabilities are, in terms of exactly how many simultaneous UCC UARTs it has been proven to support. The QE has processing limits, and maybe the soft UART microcode patch can't support multiple UCC UARTs(?) It's worth it to find out from Freescale I suppose. Chuck Meade ch...@theptrgroup.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC UART
On 06/22/2010 10:55 AM, Gary Thomas wrote:
I'm still trying to get UCC UART to work on my MPC8358 with
the 2.6.33.3 kernel.
When I try to send data to the port, there is no output, not
even any interrupts on the device. What I see is that the UART
driver seems to initialize fine and pushes characters into
the output buffers descriptors. However, there are no
interrupts hence it just sits there...
My device tree entry for this device now looks like this:
/* ttyQE0 (UCC3) */
serial_qe0: ser...@4000 {
device_type = serial;
compatible = ucc_uart;
cell-index = 3;
reg = 0x2200 0x200;
interrupts = 34;
interrupt-parent = qeic;
port-number = 0;
rx-clock-name = brg1;
tx-clock-name = brg1;
};
* Are there any known issues with this driver?
* Is there any way to get a handle on why no data is moving?
* Is there some way to tell if the QE even sees the descriptors?
* The driver and documentation mention a soft UART mode for
chips with broken UART hardware. How do I know if my board
has functioning UART hardware?
Note: I have UCC1+UCC2 working great with ethernet.
Thanks for any pointers or ideas
Hi Gary,
According to the errata, it looks like the MPC8358 is subject to
erratum QE_UART6. You'll need to use soft UART mode and load the
microcode patch. Once that is done you will also need to use two
different BRG's, one for tx and one for rx, since the soft UART mode
microcode patch requires them to be set to different rates (I believe
Rx is 16*baud under soft UART mode, and Tx is 1*baud).
Also, I don't know if it matters or not, but you should change your
dts entry ser...@4000 to ser...@2200, just like you recently changed
your reg = to 0x2200.
Chuck Meade
ch...@theptrgroup.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC interactions
On 06/22/2010 10:51 AM, Timur Tabi wrote: On Mon, Jun 21, 2010 at 2:00 PM, Gary Thomas g...@mlbassoc.com wrote: I'm running 2.6.33.3 on MPC8358. I have UCC1+UCC2 working fine for ethernet, but when I add UCC3 as a UART, the network devices quit working. Since you're using QE UART, would you mind testing this patch: http://patchwork.ozlabs.org/patch/56181/ and letting us know if it works for you? Hi Timur, His UART is not working yet. I am fine with him testing my patch (I hope he does), just he still is working on getting his UART to work at all. I think since he is using MPC8358, he needs the soft UART mode microcode patch. The patch that you mention above is one I wrote that affects how the UART close operation handles being closed when buffered output is still present. I fixed the timeout so it closes in the correct amount of time. Gary is not quite ready for testing this yet. Thanks, Chuck ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC UART
Hi Gary, According to the errata, it looks like the MPC8358 is subject to erratum QE_UART6. You'll need to use soft UART mode and load the microcode patch. Once that is done you will also need to use two different BRG's, one for tx and one for rx, since the soft UART mode microcode patch requires them to be set to different rates (I believe Rx is 16*baud under soft UART mode, and Tx is 1*baud). As I feared! Can you tell me where/how to get the microcode patch? Also, I don't know if it matters or not, but you should change your dts entry ser...@4000 to ser...@2200, just like you recently changed your reg = to 0x2200. I did that as soon as I sent this and saw the glaring inconsistency :-) Thanks Sure. Go to opensource.freescale.com/firmware and download (for your MPC8358) the 8360 soft UART mode microcode patch. You will need to know if your CPU is a 2.0 or 2.1 silicon, since there is a different microcode patch for each. Then in the kernel config I believe I included CONFIG_FW_LOADER and CONFIG_HOTPLUG (one of those may have autoselected the other). Make sure in your ucc_uart.c driver that soft uart mode is enabled. At boot time, the driver will kick off a 10 second timer that will expect the microcode patch to be loaded before the end of that 10 secs. Very early in my boot sequence, I have a startup script send the microcode patch file to the driver through the firmware-loading sysfs entry. But you need to be aware that the UCC number in the sysfs path will be offset by one. Since you are using UCC3, you should use a '2' in the path as shown below. This sequence worked for me (I changed the number for you to '2' in my command sequence, since I use a different UCC): echo 1 /sys/class/firmware/fsl-ucc-uart2/loading cat /root/fsl_qe_ucode_uart_8360_21.bin /sys/class/firmware/fsl-ucc-uart2/data echo 0 /sys/class/firmware/fsl-ucc-uart2/loading Note that the above presupposes you are using the file for silicon 2.1. Also presupposes that you have put the microcode under your rootfs /root directory. Chuck Meade ch...@theptrgroup.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC UART
Sure. Go to opensource.freescale.com/firmware and download (for your MPC8358) the 8360 soft UART mode microcode patch. You will need to know if your CPU is a 2.0 or 2.1 silicon, since there is a different microcode patch for each. Then in the kernel config I believe I included CONFIG_FW_LOADER and CONFIG_HOTPLUG (one of those may have autoselected the other). Make sure in your ucc_uart.c driver that soft uart mode is enabled. At boot time, the driver will kick off a 10 second timer that will expect the microcode patch to be loaded before the end of that 10 secs. Very early in my boot sequence, I have a startup script send the microcode patch file to the driver through the firmware-loading sysfs entry. But you need to be aware that the UCC number in the sysfs path will be offset by one. Since you are using UCC3, you should use a '2' in the path as shown below. This sequence worked for me (I changed the number for you to '2' in my command sequence, since I use a different UCC): echo 1 /sys/class/firmware/fsl-ucc-uart2/loading cat /root/fsl_qe_ucode_uart_8360_21.bin /sys/class/firmware/fsl-ucc-uart2/data echo 0 /sys/class/firmware/fsl-ucc-uart2/loading Note that the above presupposes you are using the file for silicon 2.1. Also presupposes that you have put the microcode under your rootfs /root directory. Thanks, I'll give this a try. When I download the firmware this way, do I need to follow the directions in Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt I did not do that, and I have it running here. I will say though that I hardcoded the driver to run in soft UART mode. You will need to at least add the appropriate line to your dts to get the driver to operate in Soft UART mode. I hardcoded mine because I had to backport this UCC UART driver to an older Linux kernel, and that kernel was from before dts existed. Add whatever you need to your dts to make it run in soft UART mode and get the firmware loaded. Use two different BRGs for tx and rx. Make sure your BRG choice is valid for your UCC3. I believe that the UCC UART support has not had too much use so far, but I do have it working (in that older kernel after backporting). Chuck Meade ch...@theptrgroup.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC UART
I did not do that, and I have it running here. I will say though that I hardcoded the driver to run in soft UART mode. You will need to at least add the appropriate line to your dts to get the driver to operate in Soft UART mode. I hardcoded mine because I had to backport this UCC UART driver to an older Linux kernel, and that kernel was from before dts existed. Add whatever you need to your dts to make it run in soft UART mode and get the firmware loaded. Use two different BRGs for tx and rx. Make sure your BRG choice is valid for your UCC3. I believe that the UCC UART support has not had too much use so far, but I do have it working (in that older kernel after backporting). I've done all this but sadly the behaviour is the same :-( Any ideas what I might be missing? Check your setup of the UCC3 pins for UART mode. Make sure you either have the UCC3 CD, CTS, RTS pins at the correct levels, or deconfigure those pins (set them up as GPIOs). Just verify every pin is properly set up for UCC3. The UCC3 TxD and RxD signals must be set up properly. What BRGs did you choose for tx and rx? Get a scope on the UCC3 tx pin and try to output some chars. See if there is any digital activity on that pin at all. If you are looking at a terminal for output, there are too many things that could be wrong between that tx pin and your display (e.g. level translation issue, null modem issue, baud incompatibility, terminal program set for XON/XOFF or HW flow control and UART not set up compatibly). For now get the probe directly on the CPU's UCC3 Tx pin, output chars and see if there is any activity. Chuck Meade ch...@theptrgroup.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC UART
What BRGs did you choose for tx and rx? BRG1 BRG2 OK Get a scope on the UCC3 tx pin and try to output some chars. See if there is any digital activity on that pin at all. If you are looking at a terminal for output, there are too many things that could be wrong between that tx pin and your display (e.g. level translation issue, null modem issue, baud incompatibility, terminal program set for XON/XOFF or HW flow control and UART not set up compatibly). For now get the probe directly on the CPU's UCC3 Tx pin, output chars and see if there is any activity. We've done all this - nothing on the pins directly at the CPU. This is behaving very much like there is no clock to the device. Is there something special that needs to be done to get the BRGs to work? If I was doing this, at this point I would do some strategic printk debugging within ucc_uart.c. You said that you are using 2.6.33.3, so you already have all the fixes in ucc_slow.c that I had to backport to my older kernel. If you question the setup of the BRGs, go to your function that sets them up. I don't know about 2.6.33.3, but in the latest kernel it is qe_setbrg() in qe.c. At the very bottom there is an out_be32(). printk both the address, and the value that is being written to that address. You may need to cast the values to unsigned longs to printk them. I will look at your numbers if you send them to me. In my implemenation (which again was a backport, so this may not apply to you) the BRG writes were off by 4 bytes. But I think that this error was due to the backport -- a logic mismatch I needed to resolve during the port. Also in the current Linux kernel, there is a dependence on the correctness of the brg-frequency property from the dts. Look up above qe_setbrg() at the qe_get_brg_clk() function. Before the return (there are multiple return points) printk the brg_clk being returned. That must be correct for your hardware -- must be the actual brg freq. I assume that you are booting from U-Boot. I believe in modern implementations that U-Boot fills in the brg-frequency in the device tree at boot time. Let me know how it goes, Chuck Meade ch...@theptrgroup.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC UART
Also in the current Linux kernel, there is a dependence on the correctness of the brg-frequency property from the dts. Look up above qe_setbrg() at the qe_get_brg_clk() function. Before the return (there are multiple return points) printk the brg_clk being returned. That must be correct for your hardware -- must be the actual brg freq. I assume that you are booting from U-Boot. I believe in modern implementations that U-Boot fills in the brg-frequency in the device tree at boot time. The driver claims to work with either bus-frequency or brg-frequency set. I only had bus-frequency; when I set brg-frequency, it has started to work. Now to test it with a scope to see what else is wrong... BTW, I use RedBoot - being the original author, how could I not? Thanks for the help No problem -- I am glad it is working for you now. Chuck Meade ch...@theptrgroup.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] serial: Add missing call to init UCC UART port timeout
From: Chuck Meade ch...@theptrgroup.com
The UCC UART driver is missing a call to uart_update_timeout().
Without this call, attempting to close the port after outputting large
amounts of data (i.e. using tty and uart buffering) results in long
timeouts before the port will actually be shut down.
For example, cat a large file to a UCC UART port. With the current
driver, the port will stay open for 30 seconds after the last byte
of data is output. But with this patch, the port is closed as
expected, just after the data has been output (tx fifos empty).
Signed-off-by: Chuck Meade ch...@theptrgroup.com
---
drivers/serial/ucc_uart.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/ucc_uart.c b/drivers/serial/ucc_uart.c
index 907b06f..a136030 100644
--- a/drivers/serial/ucc_uart.c
+++ b/drivers/serial/ucc_uart.c
@@ -961,6 +961,9 @@ static void qe_uart_set_termios(struct uart_port *port,
/* Do we really need a spinlock here? */
spin_lock_irqsave(port-lock, flags);
+ /* Update the per-port timeout. */
+ uart_update_timeout(port, termios-c_cflag, baud);
+
out_be16(uccp-upsmr, upsmr);
if (soft_uart) {
out_be16(uccup-supsmr, supsmr);
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PPC405EX based irq flooding with USB-OTG and usbserial device
Hunter Cobbs wrote: On Sat, May 23, 2009 at 1:14 PM, Wolfgang Denk w...@denx.de mailto:w...@denx.de wrote: Dear Hunter, In message ad84a70a0905222048i4e7ae5ddp66418f96d531f...@mail.gmail.com mailto:ad84a70a0905222048i4e7ae5ddp66418f96d531f...@mail.gmail.com you wrote: This is my first post to the PPC dev list as my company has just started developing a new project based on Linux. The good news is, this post is not debug-related as much as it is an introduction and query while I download the latest DENX kernel(only place I know that has the DWC_OTG driver). there is a strong reason why we decided not to try to push this driver upstream: it is not in a state that would have a chance for being accepted for mainline. The problems you are experiencing are probably not the only one. Please consider this driver as unsupported. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de mailto:w...@denx.de Ada is PL/I trying to be Smalltalk. - Codoso diBlini Which leads me to another question. Since I should consider this unsupported, is there a better driver out there as my company is already well down the road with our design? Or would you recommend just creating our own driver for the USB-OTG? I'm developing with the Kilauea, and I guess I should ask how unstable is Linux support for this Processor. -- Hunter Cobbs Hi Hunter, First, thanks very much for the email, and for the patches to fix the DMA. I had assumed, both when I saw the DMA warnings and when I saw the defines in the Makefile, that DMA was absolutely not ready for primetime on PPC405EX USB. Needless to say I will be testing out your DMA patches here. If that works for me, that should mitigate some of this interrupt overhead. So thanks in advance -- I am hoping that this will make a real difference. To answer your recent question, I have had no other difficulties with the PPC405EX. I actually work with 3 different custom targets right now using the PPC405EX (one uses the PPC405EXr variant), and have had no problems outside of USB. I do not know of any other driver for the PPC405EX USB controller. My other remaining USB issue on this controller is a bandwidth issue. There is another USB host controller called ehci commonly found on PCs, and I see that they have a configurable scheduler tweak called CONFIG_USB_EHCI_TT_NEWSCHED. The description in the drivers/usb/host/Kconfig file for that config item under ehci (in the Kconfig file search for USB_EHCI_TT_NEWSCHED) is *exactly* the problem I am having now on the PPC405EX USB controller. Of course that scheduler tweak is for a totally different USB controller, so that doesn't help me directly, but it serves as an example. If anybody else out there has fixed this USB bandwidth issue on PPC405EX (the one described in the ehci solution for this under USB_EHCI_TT_NEWSCHED), please let me/us know. Thanks, Chuck ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC405EX based irq flooding with USB-OTG and usbserial device
Hunter Cobbs wrote: Hello everyone, This is my first post to the PPC dev list as my company has just started developing a new project based on Linux. The good news is, this post is not debug-related as much as it is an introduction and query while I download the latest DENX kernel(only place I know that has the DWC_OTG driver). I've been working with a Kilauea dev board and have had lots of trouble when I plug in a sierra-wireless modem dev kit on the USB. It goes fine untill I actually try to communicate(pppd or minicom) with the little bugger and then my IRQs go through the roof. And they only calm back down after I shut down my communicaiton channel. I've solved this issue with our board, and was wondering if it has since been fixed (I'm running 2.6.25-DENX). I don't want to waste the board's time with a patch that is no longer necesarry. -- Hunter Cobbs Hello Hunter, It would absolutely *not* be a waste of anyone's time. I for one would like to see how you solved this. I am dealing with the same problem, with the same setup. The underlying cause for this problem is the PPC405EX CPU's erratum USBO_9. The USB 2.0 PING protocol is supposed to handle a PING transaction in the hardware -- note that in USB 2.0, a PING is the method used by the sender to determine if it can send. If I remember correctly, erratum USBO_9 is caused when a NAK response from the PING transaction is handled not in hardware, but instead as an interrupt in software, and that NAK leads to a lot of processing. In the 2.6.25 Denx Linux tree that I used, that processing ends up trying to restart the channel, restart the send, which leads to yet another PING/NAK sequence, yet another interrupt... The end result is that you get over 100,000 interrupts (with significant interrupt handling logic) per second, and the target can't do anything else. I was able to get this interrupt count by looking at /proc/interrupts, then causing this problem for 20 seconds, then pulling out the USB modem physically (mine is on a Express card) to stop the interrupt storm, then checking /proc/interrupts again. Averaged over 100,000 ints/sec. In contact with AMCC, they told us they are not respinning the CPU (at least not at this time) to fix this erratum. I have tried to solve the problem as suggested by the erratum, by not allowing the NAK interrupt handling to *directly* cause a retry of the send, but rather to wait until the next SOF interrupt (start of microframe, which happens 8,000 times per sec) to restart it. Breaking the chain like this does allow the board to proceed, but I think it is suboptimal, or at least unfortunate. One painful side effect of this workaround is that you cannot disable the 8,000 SOF interrupts/second, or at least some of them, since they are being used now for another purpose -- recovery from the erratum. The 8000 SOF ints being handled per second do cause a measurable drain on the CPU. In some cursory testing we see a 10% slowdown of certain transactions in lmbench. So please send me your patch for the dwc_otg driver. I am very interested in what you did, and if it perhaps is a better solution for the problem we both are seeing than what I implemented. Thanks in advance, Chuck ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: link failure: file truncated
Jon Tollefson wrote: Just tried to build the latest version from Linus' tree and I am getting a link error. building with the pseries_defconfig ... LD drivers/built-in.o LD vmlinux.o MODPOST vmlinux.o WARNING: modpost: Found 6 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 ld: final link failed: File truncated make: *** [.tmp_vmlinux1] Error 1 ~/src/linus/linux-2.6cat /etc/SuSE-release SUSE LINUX Enterprise Server 9 (ppc) VERSION = 9 PATCHLEVEL = 3 ~/src/linus/linux-2.6ld --version GNU ld version 2.15.90.0.1.1 20040303 (SuSE Linux) Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. ~/src/linus/linux-2.6gcc --version gcc (GCC) 3.3.3 (SuSE Linux) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ~/src/linus/linux-2.6cat /etc/SuSE-release SUSE LINUX Enterprise Server 9 (ppc) VERSION = 9 PATCHLEVEL = 3 Jon As you may have seen from Segher's email from about 40 minutes ago, I can confirm that I am getting the same error at the same point in the build. I am going to reply to his message in a few minutes with more details he requested. Like you, I also have a 2.15-era ld version. I can tell you that if you revert the patch that Segher sent on July 22 for file arch/powerpc/kernel/vmlinux.lds.S, the link should succeed (mine does). Regards, Chuck ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix build bug with binutils 2.18 and GCC 4.2
Segher Boessenkool wrote: [putting linuxppc-dev on Cc:, hope you don't mind] On 24 jul 2008, at 08:32, Chuck Meade wrote: I wanted to reply to your original message regarding this, but sadly I had already deleted it. So I am sending directly to you. This patch broke my link. Sorry. I didn't test with anything _that_ ancient. Reverting it, I am again able to link the latest git fetch of the kernel, but with your patch, my ld breaks. I am using binutils 2.15, successfully until this patch was applied yesterday. What target / what config / what exact GCC version / what exact binutils version / why are you using such an ancient toolchain anyway? :-) I have been using gcc 3.4.4 and binutils 2.15 up to this point without problems. Yes they are not cutting-edge by any means, Updating to GCC 3.4.6 might be a good idea, it's the latest bug fix release in the 3.4 series. I agree PowerPC Linux should still be buildable with GCC 3.4; I don't think we really care about 3.3 or older anymore though. but the concern here is that this patch causes the linker to fail for the first time. Up until now the link has worked fine, and if I revert this patch, the link continues to work well. Yeah, I understand. I'm not saying you need to upgrade your toolchain (or, I'm not yet saying that anyway; will have to see what causes this problem first); I just said I neglected to test with anything that old. For one of my customers, we use a customized build system that can share cross toolsets for builds of multiple platforms. So the fact that these tools have worked for us cross several 83xx platforms for a long time is valuable. It would be highly desirable to have the linker continue to work. Sure, I'll try my best to find out what is wrong, and fix it for you if possible. I am very willing to work with you and test the alternative patch ideas you have for vmlinux.lds.S on my tools here. This patch was in the general interest of backwards-compatibility with pre-2.18 binutils anyway. Yes, exactly: 2.6.26 does not build with binutils 2.17. I can help you by testing on 2.15. Send me alternate vmlinux.lds.S files to try, and I will test and get back to you ASAP. No, I will not send you randomly changed source files and hope they will do something useful for you. Instead, why not provide me the information I asked for? What target (arch/powerpc it sounds like?) What _exact_ binutils version (FSF 2.15?) What _exact_ GCC version (FSF 3.4.4?) What Linux config (either the full .config, or the name of a defconfig)? No problem -- I thought it would be helpful to offer to test changes for you, so we could work together toward a solution. The gcc version is 3.4.4. This is from source tarball gcc-3.4.4.tar.bz2, downloaded from ftp.gnu.org, built myself using crosstool. Here is the version output: $ ./powerpc-8325-linux-gnu-gcc --version powerpc-8325-linux-gnu-gcc (GCC) 3.4.4 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The binutils are version 2.15, from source tarball binutils-2.15.tar.bz2. Downloaded from ftp.gnu.org. Built myself using crosstool. Here is the version output: $ ./powerpc-8325-linux-gnu-ld --version GNU ld version 2.15 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. The target arch/powerpc. The Linux defconfig was mpc836x_rdk_defconfig. The link error, in case you were wondering, was: Yes, I forgot to ask for that :-) powerpc-8325-linux-gnu-ld: final link failed: File truncated What was the command line here? Was it the linking of vmlinux? The command line was make ARCH=powerpc uImage. The step that failed was the linking of vmlinux. If you look at the email to the linuxppc-dev list from this evening at 7:07 pm (about 30 minutes ago), Jon Tollefson is encountering the same error now. At the risk of providing too much detail -- if you issue the same build command with V=1 appended, it shows the failing link command. Entering that failing link command at the command line, I can remove all of the files from the link, one by one, until only kernel/built-in.o is left, and still get the File truncated error. Of course once you remove enough files from the link line there are other errors -- undefined reference problems that show up -- but the File truncated error is related to kernel/built-in.o. Hope that helps a bit. Let me know if you have any questions. Thanks, Chuck Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix compile error with binutils 2.15
Segher Boessenkool wrote:
My previous patch to fix compilation with binutils-2.17 causes
a file truncated build error from ld with binutils 2.15 (and
possibly older), and a warning with 2.16 and 2.17.
This fixes it.
Signed-off-by: Segher Boessenkool [EMAIL PROTECTED]
Hi Segher,
That fixes it! Thanks very much for that.
Best regards,
Chuck
Acked-by: Chuck Meade [EMAIL PROTECTED]
---
arch/powerpc/kernel/vmlinux.lds.S |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index a914411..4a8ce62 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -85,7 +85,7 @@ SECTIONS
/* The dummy segment contents for the bug workaround mentioned above
near PHDRS. */
- .dummy : {
+ .dummy : AT(ADDR(.dummy) - LOAD_OFFSET) {
LONG(0xf177)
} :kernel :dummy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: removal of arch/ppc in 2.6.27?
This is intended as a reminder that we plan on getting rid of arch/ppc this summer. I'm guessing based on kernel release times that will be 2.6.27. That would mean 2.6.26 will be the last kernel to support arch/ppc. If people have boards that like ported over please let us know and work with us to port this over to arch/powerpc. Here is a list based on arch/ppc/platforms. Its not intended to be complete but a general idea of what's left in arch/ppc. It would be nice to see the mbx860 get forward-ported. I just have not had any time to get to it. Chuck ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
