From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.chez-thomas.org (hermes.mlbassoc.com [64.234.241.98]) by mx1.pokylinux.org (Postfix) with ESMTP id 3C9184C8005F for ; Wed, 8 Jun 2011 14:02:14 -0500 (CDT) Received: by mail.chez-thomas.org (Postfix, from userid 999) id 98DE11660303; Wed, 8 Jun 2011 13:02:13 -0600 (MDT) X-Spam-Checker-Version: SpamAssassin 3.3.2-r929478 (2010-03-31) on hermes.chez-thomas.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable version=3.3.2-r929478 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by mail.chez-thomas.org (Postfix) with ESMTP id 1ADDE16602B9; Wed, 8 Jun 2011 13:02:12 -0600 (MDT) Message-ID: <4DEFC733.9030100@mlbassoc.com> Date: Wed, 08 Jun 2011 13:02:11 -0600 From: Gary Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10 MIME-Version: 1.0 To: Darren Hart References: <4DEFB4BA.7050902@mlbassoc.com> <4DEFBDB9.2020405@linux.intel.com> In-Reply-To: <4DEFBDB9.2020405@linux.intel.com> Cc: Poky Project Subject: Re: BeagleBoard using GCC 4.6.0 X-BeenThere: poky@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Poky build system developer discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 19:02:14 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/08/2011 12:21 PM, Darren Hart wrote: > On 06/08/2011 10:43 AM, Gary Thomas wrote: >> Now that Poky is using GCC 4.6.0, has anyone actually checked the >> operation on the BeagleBoard? I suspect that you'll find that the >> EHCI USB does not work. I can't really check here as I don't trust >> the EHCI on my BeagleBoard rev C3 (not xM). > > Gary, > > Thank you for digging into this. Excellent timing as I was looking at > the same thing - I hadn't looked at the compiler yet as I was in the > middle of some kernel work and had assumed the problem lay there. I'll > see if I can try with the older kernel to get this resolved as well. > Have you tried with various optimization options yet? Not yet, I've only tried the basic options, etc, to try and see where things might be going South. >> >> That said, I've tried this new compiler (previously reported) on >> my own OMAP/3530 board which uses the same 2.6.37 kernel (just not >> the linux-yocto version). When I build my kernel with GCC 4.5.2, >> it works perfectly, but fails with GCC 4.6.0 (I trust the hardware). >> >> I've isolated it down to at least the function 'ehci_hub_control' >> (but I suspect the problem is more fundamental). Comparing the code >> generated by the two compilers with the same source tree, this function >> is dramatically different. I can see why it's failing, I just don't >> know why the compiler is doing what it's doing. >> >> The lines at drivers/usb/host/ehci-hub.c:841 >> case GetPortStatus: >> if (!wIndex || wIndex> ports) >> goto error; >> wIndex--; >> status = 0; >> temp = ehci_readl(ehci, status_reg); >> >> are being compiled very differently. >> >> With GCC 4.5.2: >> 0xc0229810: cmp r3, #0 ; 0x0 >> 0xc0229814: beq 0xc0229df8 >> 0xc0229818: cmp r3, r0 >> 0xc022981c: bgt 0xc0229df8 >> 0xc0229820: sub r8, r3, #1 ; 0x1 >> 0xc0229824: ldr r5, [r7, #4] >> 0xc0229828: uxth r8, r8 >> 0xc022982c: dmb sy >> >> With GCC 4.6.0: >> 0xc0221630: cmp r3, #0 ; 0x0 >> 0xc0221634: beq 0xc0221d7c >> 0xc0221638: cmp r3, r0 >> 0xc022163c: bgt 0xc0221d7c >> 0xc0221640: sub r7, r3, #1 ; 0x1 >> 0xc0221644: add r3, r11, #16 ; 0x10 >> 0xc0221648: add r3, r8, r3, lsl #2 >> 0xc022164c: uxth r7, r7 >> 0xc0221650: ldrb r5, [r3, #5] >> 0xc0221654: ldrb r2, [r3, #4] >> 0xc0221658: orr r5, r2, r5, lsl #8 >> 0xc022165c: ldrb r2, [r3, #6] >> 0xc0221660: ldrb r3, [r3, #7] >> 0xc0221664: orr r5, r5, r2, lsl #16 >> 0xc0221668: orr r5, r5, r3, lsl #24 >> 0xc022166c: dmb sy >> >> As you can see, the old compiler accesses the ehci status register >> in a single access, the new compiler dances around and makes multiple >> accesses, which in the end get very incorrect data (I think that this >> register is like many which clear bits on reads). >> >> Any ideas where I can go with this? I'm really trying to keep up with >> Poky/Yocto, but this move to GCC 4.6.0 has broken my ARM targets :-( >> I do have PowerPC targets as well - they seem fine (from limited testing) >> with the new compiler. >> >> Note: if you want to see the whole function disassembly, look at >> http://www.mlbassoc.com/poky/ehci_hub_control-disassembly-gcc-4.5.2 >> http://www.mlbassoc.com/poky/ehci_hub_control-disassembly-gcc-4.6.0 >> >> Thanks >> > -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------