All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gary Thomas <gary@mlbassoc.com>
To: Darren Hart <dvhart@linux.intel.com>
Cc: Poky Project <poky@yoctoproject.org>
Subject: Re: BeagleBoard using GCC 4.6.0
Date: Wed, 08 Jun 2011 13:02:11 -0600	[thread overview]
Message-ID: <4DEFC733.9030100@mlbassoc.com> (raw)
In-Reply-To: <4DEFBDB9.2020405@linux.intel.com>

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


      reply	other threads:[~2011-06-08 19:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-08 17:43 BeagleBoard using GCC 4.6.0 Gary Thomas
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
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
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
2011-06-10  1:05                 ` Khem Raj
2011-06-08 18:21 ` Darren Hart
2011-06-08 19:02   ` Gary Thomas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DEFC733.9030100@mlbassoc.com \
    --to=gary@mlbassoc.com \
    --cc=dvhart@linux.intel.com \
    --cc=poky@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.