svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa

[Warner Losh]

On Jan 11, 2014, at 1:53 PM, John-Mark Gurney wrote:

> Andrew Turner wrote this message on Sat, Jan 11, 2014 at 13:51 +0000:
>> On Fri, 10 Jan 2014 15:02:41 -0800
>> John-Mark Gurney <jmg at funkthat.com> wrote:
>> 
>>> John-Mark Gurney wrote this message on Wed, Jan 08, 2014 at 09:39
>>> -0800:
>>>> So, I've tested that HEAD (absolutely no tree changes) w/
>>>> WITHOUT_ARM_EABI boots fine...  and just to make sure my test is
>>>> correct, I've disabled it too to verify that the kernel just hangs
>>>> (absolutely no output)..  and reenabled it and verified it works
>>>> (that my setting is changing something)...
>>>> worky -> no worky -> worky...
>>>> 
>>>> Now I just realized another interesting thing about setting
>>>> WITHOUT_ARM_EABI, it also fixes the console issue I was having w/
>>>> your call to cpu_setup("") previously (w/ EABI) killing console
>>>> output and not even seeing the mtx panic message...
>>>> 
>>>> So, it is clearly changing something very early on in boot...
>>> 
>>> Apparently gcc ARMEB w/ EABI miscompiles code...  The code to store
>>> lo_flags in the lock_object is correct:
>>>                        lock->lo_flags = i << LO_CLASSSHIFT;
>>> c03ce2d0:       e1a01c06        lsl     r1, r6, #24
>>> c03ce2d4:       e5881004        str     r1, [r8, #4]
>>> 
>>> But when I add a printf to fetch the data, I get:
>>> printf("lo_classindex: %#x\n", LO_CLASSINDEX(lock));
>>> c03ce2e0:       e5d81007        ldrb    r1, [r8, #7]
>>> c03ce2e4:       e59f0098        ldr     r0, [pc, #152]  ; c03ce384
>>> <_end+0xffcf9
>>> 19c>
>>> c03ce2e8:       e201100f        and     r1, r1, #15     ; 0xf
>>> c03ce2ec:       eb0012ea        bl      c03d2e9c <printf>
>>> 
>>> 
>>> We are doing a ldrb (LoaD Relative Byte) which would be fine to
>>> substitute for the right shift of 24, but only if it loaded the
>>> correct byte.. It should be loading #4 instead of #7 since we are on
>>> big endian...
>>> 
>>> Anyone who know gcc arm well to figure this out?
>>> 
>> 
>> I have an untested fix at [1]. As I don't have any big-endian boards I
>> am unable to test the kernel with this.
>> 
>> Andrew
>> 
>> [1] http://people.freebsd.org/~andrew/armeb_gcc.diff
> 
> I have verified that this patch allows me to boot a kernel till it
> mounts root...  As I haven't put together a root fs yet, I can't say
> if it goes to single/multiuser yet...

Sounds like a sufficient test to commit it. We can make other fixes if there are other issues...

This is assuming that Andrew has tested on LE systems :0

Warner