From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
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 [thread overview]
Message-ID: <52841822.1080500@gmail.com> (raw)
In-Reply-To: <20131113160514.GX1557@rocoto.smurfnet.nu>
[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
next prev parent reply other threads:[~2013-11-14 0:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-13 14:49 arm-uboot: misc.S:56: Error: r13 not allowed here -- `sub sp,fp,#4' Colin Watson
2013-11-13 15:15 ` arm-uboot: misc.S:56: Error: r13 not allowed here -- `sub sp, fp, #4' Vladimir 'φ-coder/phcoder' Serbinenko
2013-11-13 15:36 ` Leif Lindholm
2013-11-13 15:45 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-11-13 16:05 ` Leif Lindholm
2013-11-14 0:24 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2013-11-14 10:45 ` Leif Lindholm
2013-11-13 15:22 ` arm-uboot: misc.S:56: Error: r13 not allowed here -- `sub sp,fp,#4' Leif Lindholm
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=52841822.1080500@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).