BeagleBoard using GCC 4.6.0

BeagleBoard using GCC 4.6.0

[Gary Thomas]

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.

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

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: BeagleBoard using GCC 4.6.0

[Saul Wold]

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
>

Re: BeagleBoard using GCC 4.6.0

[Darren Hart]

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?

--
Darren

> 
> 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 <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
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: BeagleBoard using GCC 4.6.0

[Gary Thomas]

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<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
>>
>

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: BeagleBoard using GCC 4.6.0

[Darren Hart]

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

Re: BeagleBoard using GCC 4.6.0

[Khem Raj]

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

Re: BeagleBoard using GCC 4.6.0

[Darren Hart]

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

Re: BeagleBoard using GCC 4.6.0

[Khem Raj]

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

Re: BeagleBoard using GCC 4.6.0

[Gary Thomas]

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
------------------------------------------------------------

Re: BeagleBoard using GCC 4.6.0

[Khem Raj]

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

Re: BeagleBoard using GCC 4.6.0

[Khem Raj]

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

Re: BeagleBoard using GCC 4.6.0

[Gary Thomas]

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
------------------------------------------------------------

Re: BeagleBoard using GCC 4.6.0

[Gary Thomas]

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
------------------------------------------------------------

Re: BeagleBoard using GCC 4.6.0

[Darren Hart]

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

Re: BeagleBoard using GCC 4.6.0

[Gary Thomas]

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
------------------------------------------------------------

Re: BeagleBoard using GCC 4.6.0

[Darren Hart]

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

Re: BeagleBoard using GCC 4.6.0

[Khem Raj]

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