Re: Poky & armv5te

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 11-02-02 07:21 PM, Richard Purdie wrote:
> On Wed, 2011-02-02 at 15:17 -0700, Gary Thomas wrote:
>> On 02/02/2011 11:27 AM, Gary Thomas wrote:
>>> On 02/02/2011 11:00 AM, Richard Purdie wrote:
>>>> On Wed, 2011-02-02 at 09:42 -0800, Darren Hart wrote:
>>>>> On 02/02/2011 09:24 AM, Gary Thomas wrote:
>>>>>> I'd like to use Poky with my OMAP-L138 which is armv5te
>>>>>> Sadly today, this just isn't a go because of GCC issues.
>>>>>> I've tried all the combinations which are in the trees
>>>>>> (main&  contrib) with no luck:
>>>>>> * 4.3.3 - fails to build GCC
>>>>>> * 4.5.1 - everything builds but kernel crashes
>>>>>> * 4.5.2 - fails to build GCC
>>>>>>
>>>>>> Am I totally out of luck?
>>>>>
>>>>> What are you running into? I've recently backported some changes in
>>>>> support of the Beagleboard (armv7-a) which were necessary to build with
>>>>> 4.5.1 and our 2.21 binutils.
>>>>
>>>> Those wouldn't affect armv5. What puzzles me is that qemuarm is
>>>> effectively an armv5 like system and those do build and boot in qemu.
>>>>
>>>> When you managed images above for 4.5.1 did you try using a known good
>>>> kernel with our userspace? I'm wondering if we can narrow it to a kernel
>>>> issue?
>>>
>>> Not sure I got that far, but I'll check it out.
>>
>> A simple test indicates that the user-space tools built in Poky
>> do run fine on this hardware when built with GCC/4.5.1 and BINUTILS/2.21
>> It's only the kernel that crashes hard with this combo.
>
> Ok, thats positive in many ways :)
>
> When you say the kernel crashes hard can you be any more specific about
> where in the process its doing that? Any chance its using -Os anywhere
> in the kernel build and that is causing the problem?

For ARM .. it definitely is using Os. Unless gcc 4.5.1 has
some changes in this area, ARM builds require Os, as they
have for a while (see below).

Typically if you build an ARM kernel without Os you get
indeterminate errors (in the network stack, scheduler
optimizations, etc). At least in kernels 2.6.34 and older
this is true, I've shared in the marathon debug sessions
to prove it :) In fact, we explicitly force on the
CC_OPTIMIZE_FOR_SIZE in our configuration of th ARM kernels
to make sure this doesn't creep back in.

A quick check shows that out of ~170 ARM defconfigs 151
turn on CONFIG_CC_OPTIMIZE_FOR_SIZE, and the ones with it
off are typically older ones.

I just doubled checked qemuarm, and it also turns on
CC_OPTIMIZE_FOR_SIZE (which it was supposed to do). I started
a build for it and will do a boot to see what happens
shortly.

Maybe this has changed recently (I haven't had to have a
deeper look in 2.6.37 (yet)), so I am happy to be corrected :)

Cheers,

Bruce

>
> Cheers,
>
> Richard
>
>
>
>
>
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky