public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Pete Batard <pete@akeo.ie>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: [PATCH 0/1] MdeModulePkg/EbcDxe: add ARM support
Date: Thu, 22 Sep 2016 12:40:08 +0100	[thread overview]
Message-ID: <CAKv+Gu9daKS3KgrqE_3_+uvxapp4=pUbxTsYdEVB9m7Aw1xNJw@mail.gmail.com> (raw)
In-Reply-To: <620161a6-dab1-2e12-3a3e-39aab4d265b5@akeo.ie>

On 22 September 2016 at 12:26, Pete Batard <pete@akeo.ie> wrote:
> On 2016.09.22 12:14, Ard Biesheuvel wrote:
>>
>> For X64 and AARCH64, the issue does not exist because the EBC spec
>> mandates that all function arguments are widened to the native word
>> size. So when executing on a 64-bit architecture, the EBC stack looks
>> differently from what you describe above, and maps seamlessly onto the
>> register assignment mandated by the respective calling conventions.
>
>
> Ah, I see that you're right, and that I was trying to solve an issue that
> shouldn't exist:
>
> From UEFI 2.6, paragraph 21.9.3:
>
> "32-bit integers are pushed as natural size (since they
> should be passed as 64-bit parameter values on 64-bit machines)."
>
> I must admit I was a bit curious as to why this problem wouldn't have been
> picked before.
>
>
> So that leaves only the issue you mentioned. But then I'm not too hopeful
> with the timeframe for Arm/EBC integration when you say "we need language
> spec and compiler updates before we can fully support this"...
>
> Do you know if work has been started on this? Or are we just going to
> consider that this is too troublesome a problem to fix?
>

We are debating this internally. Even on AArch64, there are numerous
issues with EBC drivers, even if the code itself executes fine (this
is mainly related to PCI drivers that don't bother to enable support
for 64-bit DMA since this is never needed on Intel platforms)

So while EBC is of high importance to many Linaro members, I am not
sure if that includes 32-bit ARM support.

-- 
Ard.


  reply	other threads:[~2016-09-22 11:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-22  9:43 [PATCH 0/1] MdeModulePkg/EbcDxe: add ARM support Pete Batard
2016-09-22 10:06 ` Ard Biesheuvel
2016-09-22 10:13   ` Ard Biesheuvel
2016-09-22 11:05   ` Pete Batard
2016-09-22 11:14     ` Ard Biesheuvel
2016-09-22 11:26       ` Pete Batard
2016-09-22 11:40         ` Ard Biesheuvel [this message]
2016-09-22 20:27     ` Andrew Fish
2016-09-22 21:21       ` Ard Biesheuvel
2016-09-22 21:40       ` Pete Batard
2016-09-22 21:24     ` Andrew Fish
2016-09-22 21:29       ` Ard Biesheuvel

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-list 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='CAKv+Gu9daKS3KgrqE_3_+uvxapp4=pUbxTsYdEVB9m7Aw1xNJw@mail.gmail.com' \
    --to=devel@edk2.groups.io \
    /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