From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.pokylinux.org (Postfix) with ESMTP id 4BC774C800BA for ; Wed, 8 Jun 2011 19:08:50 -0500 (CDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 08 Jun 2011 17:08:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.65,340,1304319600"; d="scan'208";a="10969950" Received: from unknown (HELO [10.255.13.104]) ([10.255.13.104]) by orsmga002.jf.intel.com with ESMTP; 08 Jun 2011 17:08:49 -0700 Message-ID: <4DF00F0C.30102@linux.intel.com> Date: Wed, 08 Jun 2011 17:08:44 -0700 From: Darren Hart User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Saul Wold References: <4DEFB4BA.7050902@mlbassoc.com> <4DEFBD77.7000400@linux.intel.com> <4DEFD3E0.1020208@linux.intel.com> In-Reply-To: <4DEFD3E0.1020208@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 00:08:50 -0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/08/2011 12:56 PM, Darren Hart 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. > > By switching GCCVERSION to 4.5.1, a kernel that previously failed to > bring up the USB hub on the beagleboard xM (and the ethernet port) with > 4.6.0, now successfully does so. Unfortunatley, the framebuffer device > fails now. Turns out this was user error. In my development kernel I now have usb,ethernet,audio, and the sato desktop all running when building the kernel with gcc 4.5.1. I'll send a more detailed beagleboard status to the list as several folks seem to be interested. -- Darren > Any hints from the compiler crowd on things to try? Or output > we can collect to help resolve this? > > -- > Darren > >> >> 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 >>> >> _______________________________________________ >> poky mailing list >> poky@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/poky > -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel