[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