From: Fabian van der Werf <fvanderwerf@gmail.com>
To: "Eric Bénard" <eric@eukrea.com>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: [PATCH] usb: fix unaligned access
Date: Tue, 25 Oct 2011 20:36:44 +0200 [thread overview]
Message-ID: <CAJeSw6AbKXD9BgSF8FOcxtfFEnwgx4436KAmtQ8dW4GPeJyFeQ@mail.gmail.com> (raw)
In-Reply-To: <4EA5BFB3.6030801@eukrea.com>
On Mon, Oct 24, 2011 at 9:42 PM, Eric Bénard <eric@eukrea.com> wrote:
> Le 24/10/2011 21:30, Sascha Hauer a écrit :
>>
>> On Mon, Oct 24, 2011 at 09:02:53PM +0200, Eric Bénard wrote:
>>>
>>> Hi,
>>>
>>> Le 24/10/2011 20:37, Fabian van der Werf a écrit :
>>>>
>>>> Okay, I think it may be a compiler problem. The latest code sourcery
>>>> compiler builds a barebox that breaks on usb. 2009q1-203 builds fine,
>>>> however.
>>>>
>>>> In the usb code the compiler should be able to figure out that the
>>>> access is unaligned from the packed structure. So I guess it should
>>>> split up the access in multiple loads/stores. I will look into the
>>>> binaries to confirm this. The latest compiler may be broken or maybe
>>>> the default behaviour has changed because armv7 actually supports
>>>> unaligned access.
>>>>
>>> can't this be the same problem described here with gcc 4.6 :
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791552
>>>
>>> solved by this patch :
>>>
>>> https://launchpadlibrarian.net/73908303/0001-USB-ehci-remove-structure-packing-from-ehci_def.patch
>>>
>>> with the following explanation :
>>> The kernel source marks ehci_regs as packed. gcc 4.6 treats all
>>> accesses to packed structures as unaligned and ends up reading the
>>> status register multiple times.
>>
>> If Fabians compiler would treat every access to packed structure members
>> as unaligned everything would be fine. The problem seems to be that it
>> doesn't treat it as unaligned. Let's wait for Fabians binary analysis.
>>
> maybe the complete explanation will explain better the problem as barebox
> seems to have the same readl as linux :
> http://gcc.gnu.org/ml/gcc/2011-02/msg00035.html
I have looked at the disassembly and the compiler does indeed emit an
unaligned access.
Considering the following code from ehci_init()
/* Port Indicators */
if (HCS_INDICATOR(reg))
descriptor.hub.wHubCharacteristics |= 0x80; /* wHubCharacteristics is
unaligned */
/* Port Power Control */
if (HCS_PPC(reg))
descriptor.hub.wHubCharacteristics |= 0x01;
My older (gcc 4.3.3) compiler correctly uses byte loads/stores:
0x8f0171e4 <+148>: tst r1, #65536 ; 0x10000
0x8f0171e8 <+152>: and r3, r1, #15
0x8f0171ec <+156>: strb r3, [r0, #2]
0x8f0171f0 <+160>: beq 0x8f017210 <ehci_init+192>
0x8f0171f4 <+164>: ldrb r2, [r0, #4]
0x8f0171f8 <+168>: ldrb r3, [r0, #3]
0x8f0171fc <+172>: orr r3, r3, r2, lsl #8
0x8f017200 <+176>: orr r3, r3, #128 ; 0x80
0x8f017204 <+180>: strb r3, [r0, #3]
0x8f017208 <+184>: lsr r3, r3, #8
0x8f01720c <+188>: strb r3, [r0, #4]
0x8f017210 <+192>: tst r1, #16
0x8f017214 <+196>: beq 0x8f017238 <ehci_init+232>
0x8f017218 <+200>: ldr r3, [pc, #92] ; 0x8f01727c
0x8f01721c <+204>: ldrb r1, [r3, #4]
0x8f017220 <+208>: ldrb r2, [r3, #3]
0x8f017224 <+212>: orr r2, r2, r1, lsl #8
0x8f017228 <+216>: orr r2, r2, #1
0x8f01722c <+220>: strb r2, [r3, #3]
0x8f017230 <+224>: lsr r2, r2, #8
0x8f017234 <+228>: strb r2, [r3, #4]
My newer compiler (gcc 4.5.2) uses unaligned halfword loads/stores:
0x8f0159d8 <+148>: tst r2, #65536 ; 0x10000
0x8f0159dc <+152>: and r1, r2, #15
0x8f0159e0 <+156>: strb r1, [r3, #2]
0x8f0159e4 <+160>: ldrhne r1, [r3, #3]
0x8f0159e8 <+164>: orrne r1, r1, #128 ; 0x80
0x8f0159ec <+168>: strhne r1, [r3, #3]
0x8f0159f0 <+172>: tst r2, #16
0x8f0159f4 <+176>: ldrhne r2, [r3, #3]
0x8f0159f8 <+180>: orrne r2, r2, #1
0x8f0159fc <+184>: strhne r2, [r3, #3]
I found this post:
http://communities.mentor.com/community/cs/archives/arm-gnu/msg04203.html.
That mentions that unaligned access is the default for armv6 and
armv7. There are two possible fixes:
- disable alignment fault checking for armv6 and armv7
- build with the -mno-unaligned-access option
Besides that, I think we should look whether the structure really
needs to be packed. As far as I understand the code, the structure is
not used for i/o access, so packing is not necessary.
Regards,
Fabian
>
> Eric
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
prev parent reply other threads:[~2011-10-25 18:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-22 13:19 Fabian van der Werf
2011-10-22 20:20 ` Sascha Hauer
2011-10-23 9:29 ` Fabian van der Werf
2011-10-24 15:14 ` Antony Pavlov
2011-10-24 17:07 ` Sascha Hauer
2011-10-24 18:37 ` Fabian van der Werf
2011-10-24 19:02 ` Eric Bénard
2011-10-24 19:30 ` Sascha Hauer
2011-10-24 19:42 ` Eric Bénard
2011-10-25 18:36 ` Fabian van der Werf [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=CAJeSw6AbKXD9BgSF8FOcxtfFEnwgx4436KAmtQ8dW4GPeJyFeQ@mail.gmail.com \
--to=fvanderwerf@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=eric@eukrea.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox