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 210A34C800B6 for ; Thu, 9 Jun 2011 17:38:18 -0500 (CDT) Received: by mail.chez-thomas.org (Postfix, from userid 999) id 9038D16601BA; Thu, 9 Jun 2011 16:38:17 -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 53BE316601D1; Thu, 9 Jun 2011 16:37:49 -0600 (MDT) Message-ID: <4DF14B3D.4050008@mlbassoc.com> Date: Thu, 09 Jun 2011 16:37:49 -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> <4DEFBD77.7000400@linux.intel.com> <4DF016F0.4080106@gmail.com> <4DF02EDF.5040502@mlbassoc.com> <4DF06CB0.1040501@gmail.com> <4DF0AC87.2060901@mlbassoc.com> <4DF0AF61.1020108@mlbassoc.com> <4DF14A49.6000104@linux.intel.com> In-Reply-To: <4DF14A49.6000104@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: Thu, 09 Jun 2011 22:38:18 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/09/2011 04:33 PM, Darren Hart wrote: > > > On 06/09/2011 04:32 AM, Gary Thomas wrote: >> On 06/09/2011 05:20 AM, Gary Thomas wrote: >>> On 06/09/2011 12:48 AM, Khem Raj wrote: >>>> On 06/08/2011 07:24 PM, Gary Thomas wrote: >>>>> On 06/08/2011 06:42 PM, Khem Raj wrote: >>>>>> On 06/08/2011 11:20 AM, Saul Wold 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). >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>> >>>>>>> Gary, >>>>>>> >>>>>>> I am not sure if Khem Raj is on this list, so I am forwarding it to him, >>>>>>> he might have some insight. >>>>>>> >>>>>>> Sau! >>>>>>> >>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>> >>>>>> OK. thanks for sending the sample code. >>>>>> Can you add -fstrict-volatile-bitfields option to CFLAGS while >>>>>> compiling this file or even the kernel for test sake ? >>>>>> and see if the problem goes away ? >>>>> >>>>> Sorry, this doesn't seem to make any difference in the generated code. >>>>> Hardly surprising as the register in question is a simple u32, not a >>>>> bitfield. >>>>> >>>> >>>> I reduced the testcase a bit further and it seems the bug is similar to http://gcc.gnu.org/bugzilla/PR45819 >>>> >>>> but a bit different that in this case -fstrict-volatile-bitfields does not help >>>> >>>> a fix for this particular problem is >>>> >>>> diff --git a/include/linux/usb/ehci_def.h b/include/linux/usb/ehci_def.h >>>> index 6563802..b8c1833 100644 >>>> --- a/include/linux/usb/ehci_def.h >>>> +++ b/include/linux/usb/ehci_def.h >>>> @@ -194,7 +194,7 @@ struct ehci_dbg_port { >>>> u32 data47; >>>> u32 address; >>>> #define DBGP_EPADDR(dev, ep) (((dev)<<8)|(ep)) >>>> -} __attribute__ ((packed)); >>>> +} __attribute__ ((packed,aligned(__alignof__(int)))); >>>> >>>> #ifdef CONFIG_EARLY_PRINTK_DBGP >>>> #include >>>> >>>> >>>> since this particular structure all elements are integers but there might be more packed structures which have say char or short ints >>>> and are not necessarily ordered in the descending order of alignment >>>> >>>> Try it out and see if it helps >>> >>> Yes, this does fix the problem :-) The EHCI USB port on the OMAP >>> is working again. >> >> Note: it also works properly if the __attribute__ ((packed)) is simply removed. >> Looking at the layout of this structure, I don't see what that attribute is >> trying to accomplish - every item within the structure is u32[], so IMO there >> is nothing to pack. Perhaps this observation can help the GCC folks figure >> out why things are getting confused. > > I tried each of these and neither worked. I confirmed the kernel was > indeed different after each build and that gcc 4.6.0 was being used (by > adding CC --version to the kernel do_compile and checking it in the log). > > Gary, are you certain that you were building with 4.6.0 ? I've found it > to be a bit tricky to switch back and forth between compilers. Absolutely - this is a clean, from scratch, build 100% GCC 4.6.0 -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------