grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: arm-uboot: misc.S:56: Error: r13 not allowed here -- `sub sp, fp, #4


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: arm-uboot: misc.S:56: Error: r13 not allowed here -- `sub sp, fp, #4'
Date: Thu, 14 Nov 2013 01:24:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9

On 13.11.2013 17:05, Leif Lindholm wrote:
> On Wed, Nov 13, 2013 at 04:45:00PM +0100, Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>>>>>   misc.S: Assembler messages:
>>>>>   misc.S:56: Error: r13 not allowed here -- `sub sp,fp,#4'
>>>>>   make[3]: *** [kern/arm/kernel_exec-misc.o] Error 1
>>>>>
>>>>> I don't think SP can be used that way in Thumb mode?
>>>>>
>>>> I think that our asm routines should be in full ARM. Attached patch
>>>> follows this strategy. One remaining problem is to make sure that thumb
>>>> flags in TARGET_CFLAGS and TARGET_CCASFLAGS match.
>>>
>>> There should be no need for this - the only thing is to ensure the
>>> -mthumb-interwork is set in CCASFLAGS_PLATFORM as well as
>>> CFLAGS_PLATFORM, and even that is just to prevent linker warnings..
>>>
>>> There is no special ARM_PROLOGUE needed, and (on armv5te onwards)
>>> pop {..., pc} is an interworking branch.
>>>
>>> If we want to force a file to build as ARM (which I'm not sure is
>>> necessary now that we have split up armv6 separate from later
>>> architectures), all that is required is a .arm directive up top.
>>>
>> Hm. I'm confused. According to
>> http://stuff.mit.edu/afs/sipb/project/egcs/src/egcs/gcc/config/arm/README-interworking:
>> "Note that specifying -mthumb-interwork does result in slightly larger,
>> slower code being produced.  This is why interworking support must be
>> specifically enabled by a switch."
> 
> That is fairly outdated documentation (1998).
> Yes, it was true before armv5te.
> 
Hm, the qemu board easiest to test uboot with is versatile pb with
arm926 with is armv5t. So no need to worry about this. So we require at
least armv5 and arm support. Any boards outside of those resuirement
which it makes any sense to support?

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]