[poky] BeagleBoard using GCC 4.6.0

Gary Thomas gary at mlbassoc.com
Wed Jun 8 10:43:22 PDT 2011


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



More information about the poky mailing list