[poky] BeagleBoard using GCC 4.6.0
Darren Hart
dvhart at linux.intel.com
Wed Jun 8 17:08:44 PDT 2011
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 <ehci_hub_control+672>: cmp r3, #0 ; 0x0
>>> 0xc0229814 <ehci_hub_control+676>: beq 0xc0229df8 <ehci_hub_control+2184>
>>> 0xc0229818 <ehci_hub_control+680>: cmp r3, r0
>>> 0xc022981c <ehci_hub_control+684>: bgt 0xc0229df8 <ehci_hub_control+2184>
>>> 0xc0229820 <ehci_hub_control+688>: sub r8, r3, #1 ; 0x1
>>> 0xc0229824 <ehci_hub_control+692>: ldr r5, [r7, #4]
>>> 0xc0229828 <ehci_hub_control+696>: uxth r8, r8
>>> 0xc022982c <ehci_hub_control+700>: dmb sy
>>>
>>> With GCC 4.6.0:
>>> 0xc0221630 <ehci_hub_control+808>: cmp r3, #0 ; 0x0
>>> 0xc0221634 <ehci_hub_control+812>: beq 0xc0221d7c <ehci_hub_control+2676>
>>> 0xc0221638 <ehci_hub_control+816>: cmp r3, r0
>>> 0xc022163c <ehci_hub_control+820>: bgt 0xc0221d7c <ehci_hub_control+2676>
>>> 0xc0221640 <ehci_hub_control+824>: sub r7, r3, #1 ; 0x1
>>> 0xc0221644 <ehci_hub_control+828>: add r3, r11, #16 ; 0x10
>>> 0xc0221648 <ehci_hub_control+832>: add r3, r8, r3, lsl #2
>>> 0xc022164c <ehci_hub_control+836>: uxth r7, r7
>>> 0xc0221650 <ehci_hub_control+840>: ldrb r5, [r3, #5]
>>> 0xc0221654 <ehci_hub_control+844>: ldrb r2, [r3, #4]
>>> 0xc0221658 <ehci_hub_control+848>: orr r5, r2, r5, lsl #8
>>> 0xc022165c <ehci_hub_control+852>: ldrb r2, [r3, #6]
>>> 0xc0221660 <ehci_hub_control+856>: ldrb r3, [r3, #7]
>>> 0xc0221664 <ehci_hub_control+860>: orr r5, r5, r2, lsl #16
>>> 0xc0221668 <ehci_hub_control+864>: orr r5, r5, r3, lsl #24
>>> 0xc022166c <ehci_hub_control+868>: 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 at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/poky
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
More information about the poky
mailing list