* Re: BeagleBoard using GCC 4.6.0
2011-06-08 18:20 ` Saul Wold
@ 2011-06-08 19:56 ` Darren Hart
2011-06-09 0:08 ` Darren Hart
2011-06-08 20:38 ` Khem Raj
2011-06-09 0:42 ` Khem Raj
2 siblings, 1 reply; 17+ messages in thread
From: Darren Hart @ 2011-06-08 19:56 UTC (permalink / raw)
To: Saul Wold; +Cc: Poky Project
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. 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@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BeagleBoard using GCC 4.6.0
2011-06-08 19:56 ` Darren Hart
@ 2011-06-09 0:08 ` Darren Hart
0 siblings, 0 replies; 17+ messages in thread
From: Darren Hart @ 2011-06-09 0:08 UTC (permalink / raw)
To: Saul Wold; +Cc: Poky Project
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@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/poky
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BeagleBoard using GCC 4.6.0
2011-06-08 18:20 ` Saul Wold
2011-06-08 19:56 ` Darren Hart
@ 2011-06-08 20:38 ` Khem Raj
2011-06-09 0:42 ` Khem Raj
2 siblings, 0 replies; 17+ messages in thread
From: Khem Raj @ 2011-06-08 20:38 UTC (permalink / raw)
To: Saul Wold; +Cc: Poky Project
On Wed, Jun 8, 2011 at 11:20 AM, Saul Wold <sgw@linux.intel.com> 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 <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).
ok seems like unaligned loads are kicking in may be its missing
some qualifier. Can you do me a favour ? Please send me preprocessed
output of the source file and let me see what I find
-Khem
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BeagleBoard using GCC 4.6.0
2011-06-08 18:20 ` Saul Wold
2011-06-08 19:56 ` Darren Hart
2011-06-08 20:38 ` Khem Raj
@ 2011-06-09 0:42 ` Khem Raj
2011-06-09 2:24 ` Gary Thomas
2 siblings, 1 reply; 17+ messages in thread
From: Khem Raj @ 2011-06-09 0:42 UTC (permalink / raw)
To: Saul Wold; +Cc: Poky Project
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 <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
>>
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 ?
-Khem
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BeagleBoard using GCC 4.6.0
2011-06-09 0:42 ` Khem Raj
@ 2011-06-09 2:24 ` Gary Thomas
2011-06-09 5:14 ` Khem Raj
2011-06-09 6:48 ` Khem Raj
0 siblings, 2 replies; 17+ messages in thread
From: Gary Thomas @ 2011-06-09 2:24 UTC (permalink / raw)
To: Khem Raj; +Cc: Poky Project
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 <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
>>>
>
> 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.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BeagleBoard using GCC 4.6.0
2011-06-09 2:24 ` Gary Thomas
@ 2011-06-09 5:14 ` Khem Raj
2011-06-09 6:48 ` Khem Raj
1 sibling, 0 replies; 17+ messages in thread
From: Khem Raj @ 2011-06-09 5:14 UTC (permalink / raw)
To: Gary Thomas; +Cc: Poky Project
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 <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
>>>>
>>
>> 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.
>
No. Its not a simple u32
its a pointer and points to address of a member of structure type
ehci_hcd which can have bitfields. There has been bug reports in this
area in GCC which
have been fixed and some are not. I was merely trying to reduce the
problem. So you tried compiling kernel with this option and you found
that it does not work ? Did I understand it correct
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BeagleBoard using GCC 4.6.0
2011-06-09 2:24 ` Gary Thomas
2011-06-09 5:14 ` Khem Raj
@ 2011-06-09 6:48 ` Khem Raj
2011-06-09 11:20 ` Gary Thomas
1 sibling, 1 reply; 17+ messages in thread
From: Khem Raj @ 2011-06-09 6:48 UTC (permalink / raw)
To: Gary Thomas; +Cc: Poky Project
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 <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
>>>>
>>
>> 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 <linux/init.h>
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
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: BeagleBoard using GCC 4.6.0
2011-06-09 6:48 ` Khem Raj
@ 2011-06-09 11:20 ` Gary Thomas
2011-06-09 11:32 ` Gary Thomas
0 siblings, 1 reply; 17+ messages in thread
From: Gary Thomas @ 2011-06-09 11:20 UTC (permalink / raw)
To: Khem Raj; +Cc: Poky Project
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 <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
>>>>>
>>>
>>> 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 <linux/init.h>
>
>
> 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.
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: BeagleBoard using GCC 4.6.0
2011-06-09 11:20 ` Gary Thomas
@ 2011-06-09 11:32 ` Gary Thomas
2011-06-09 22:33 ` Darren Hart
0 siblings, 1 reply; 17+ messages in thread
From: Gary Thomas @ 2011-06-09 11:32 UTC (permalink / raw)
To: Khem Raj; +Cc: Poky Project
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 <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
>>>>>>
>>>>
>>>> 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 <linux/init.h>
>>
>>
>> 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.
Thanks again
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: BeagleBoard using GCC 4.6.0
2011-06-09 11:32 ` Gary Thomas
@ 2011-06-09 22:33 ` Darren Hart
2011-06-09 22:37 ` Gary Thomas
2011-06-09 23:27 ` Darren Hart
0 siblings, 2 replies; 17+ messages in thread
From: Darren Hart @ 2011-06-09 22:33 UTC (permalink / raw)
To: Gary Thomas; +Cc: Poky Project
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 <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
>>>>>>>
>>>>>
>>>>> 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 <linux/init.h>
>>>
>>>
>>> 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.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: BeagleBoard using GCC 4.6.0
2011-06-09 22:33 ` Darren Hart
@ 2011-06-09 22:37 ` Gary Thomas
2011-06-09 23:27 ` Darren Hart
1 sibling, 0 replies; 17+ messages in thread
From: Gary Thomas @ 2011-06-09 22:37 UTC (permalink / raw)
To: Darren Hart; +Cc: Poky Project
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<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
>>>>>>>>
>>>>>>
>>>>>> 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<linux/init.h>
>>>>
>>>>
>>>> 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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: BeagleBoard using GCC 4.6.0
2011-06-09 22:33 ` Darren Hart
2011-06-09 22:37 ` Gary Thomas
@ 2011-06-09 23:27 ` Darren Hart
2011-06-10 1:05 ` Khem Raj
1 sibling, 1 reply; 17+ messages in thread
From: Darren Hart @ 2011-06-09 23:27 UTC (permalink / raw)
To: Gary Thomas; +Cc: Poky Project
On 06/09/2011 03:33 PM, Darren Hart wrote:
>
>
> On 06/09/2011 04:32 AM, Gary Thomas wrote:
>>>>>>>> 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
Hi Gary, what exactly are you using to generate this output? objdump -d
gives me something similar, but not exactly the same. With 4.6.0 with
Khem's suggested patch:
> 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 <linux/init.h>
I see the following. Granted, this is a sligthly different kernel
(includes linux-omap and the patches from the meta-ti linux-omap recipe):
$
/build/poky/master/beagleboard/tmp/work/armv7a-poky-linux-gnueabi/binutils-cross-2.21-r0/binutils-2.21/build.x86_64-linux.arm-poky-linux-gnueabi/binutils/objdump
-S -d drivers/usb/host/ehci-hcd.o
<snip>
case GetPortStatus:
if (!wIndex || wIndex > ports)
1420: e3560000 cmp r6, #0
1424: 0a0001af beq 1ae8 <ehci_hub_control+0xa40>
1428: e1560003 cmp r6, r3
142c: ca0001ad bgt 1ae8 <ehci_hub_control+0xa40>
1430: e2893010 add r3, r9, #16
goto error;
wIndex--;
1434: e2466001 sub r6, r6, #1
1438: e0873103 add r3, r7, r3, lsl #2
143c: e6ff6076 uxth r6, r6
1440: e5d3b005 ldrb fp, [r3, #5]
1444: e5d32004 ldrb r2, [r3, #4]
1448: e182b40b orr fp, r2, fp, lsl #8
144c: e5d32006 ldrb r2, [r3, #6]
1450: e5d33007 ldrb r3, [r3, #7]
1454: e18bb802 orr fp, fp, r2, lsl #16
1458: e18bbc03 orr fp, fp, r3, lsl #24
#ifdef CONFIG_USB_EHCI_BIG_ENDIAN_MMIO
return ehci_big_endian_mmio(ehci) ?
readl_be(regs) :
readl(regs);
#else
return readl(regs);
145c: f57ff05f dmb sy
</snip>
This seems to demonstrate the same pile of extra ldrb and orr
instructions that you first saw with 4.6.0. Some quick googling suggests
Khem's idea of misaligned loads seems sound, but for whatever reason,
the fix didn't work for me.
Khem, any other thoughts on something to try?
Note: CONFIG_USB_EHCI_BIG_ENDIAN_MMIO does not appear to be set in my
config.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: BeagleBoard using GCC 4.6.0
2011-06-09 23:27 ` Darren Hart
@ 2011-06-10 1:05 ` Khem Raj
0 siblings, 0 replies; 17+ messages in thread
From: Khem Raj @ 2011-06-10 1:05 UTC (permalink / raw)
To: Darren Hart; +Cc: Poky Project
On 06/09/2011 04:27 PM, Darren Hart wrote:
> This seems to demonstrate the same pile of extra ldrb and orr
> instructions that you first saw with 4.6.0. Some quick googling suggests
> Khem's idea of misaligned loads seems sound, but for whatever reason,
> the fix didn't work for me.
>
> Khem, any other thoughts on something to try?
>
> Note: CONFIG_USB_EHCI_BIG_ENDIAN_MMIO does not appear to be set in my
> config.
If you can narrow the down the problem a bit may be I will get some
direction otherwise I don't know what problem it might be. You config
must be different to Gary's and there could be same or different problem
in other part of code.
Give me more information on the error and ideally like what Gary did
makes it easy
^ permalink raw reply [flat|nested] 17+ messages in thread