What Tim said.
From: [email protected] [mailto:[email protected]]
Sent: Friday, September 12, 2014 3:25 PM
To: [email protected]
Subject: Re: [edk2] Is there a way ...
Dell - Internal Use - Confidential
I second this motion. It would avoid the need to use other command whose
command lines and features may change over time adding more complexity.
</Lowell>
From: Tim Lewis [mailto:[email protected]]
Sent: Friday, September 12, 2014 12:02 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] Is there a way ...
Deric -
Sounds like a good idea. You should propose this to your USWG representative to
change the specification.
Tim
From: Deric Cole [mailto:[email protected]]
Sent: Friday, September 12, 2014 9:57 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] Is there a way ...
Why not update the shell to automatically create this ARCH variable?
Deric Cole
Sr. Customer Engineer
Phoenix Technologies Ltd.
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Sent: Friday, September 12, 2014 9:14 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] Is there a way ...
Another option would be to write a small EFI driver, built for one bit-ness,
load it, and check %lasterror%. If you are only interested in Ia32 vs X64, you
could follow this example:
load MyTest32BitDriver.efi
if %lasterror% == 0 then
<insert 32-bit specific code here>
else
if %lasterror% == 7 then
<insert 64-bit specific code here>
else
<other error handling here>
endif
endif
This assumes, of course, that the shell will return 7 (SHELL_DEVICE_ERROR) when
it is unable a driver because of incorrect bit-ness. And using one driver like
this isn't extensible to other architectures. If that is a concern, then you
could build test drivers for IA32, X64, IPF, EBC, etc., attempt to load all of
them until on returns success, and us that as an indication of the system
architecture.
Allen Wynn
From: Tim Lewis [mailto:[email protected]]
Sent: Thursday, September 11, 2014 11:42 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] Is there a way ...
Lowell -
You might use the redirect-to-environment variable that the UEFI shell supports.
I believe you can do:
ver -terse -_pa >v ARCH
Is that what you want?
By the way, I would point out that since _pa is not architectural per the spec,
it may not be supported on all shell implementations.
Tim
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Sent: Thursday, September 11, 2014 8:33 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] Is there a way ...
Dell - Internal Use - Confidential
Ok,
So in case anyone is interested, I found a way to extract this using nsh
scripts. It is kind of goofy but ...
startup.nsh:
ver -terse -_pa > ver.nsh
ver.nsh
UEFI.nsh:
@echo -off
exit /b 0
64.nsh:
@echo -off
set -v ARCH X64
exit /b 0
32.nsh:
@echo -off
set -v ARCH IA32
exit /b 0
The first line of startup.nsh generates ver.nsh.
The second line of startup.nsh then executes ver.nsh.
On a 64-bit system ver.nsh will contain
UEFI Interactive Shell V2.0
64
On a 32-bit system ver.nsh will contain
UEFI Interactive Shell V2.0
32
When ver.nsh is executed, it first runs UEFI.nsh (which does nothing).
It then runs either 64.nsh or 32.nsh which will sets ARCH appropriately.
</Lowell>
From: Dennis, Lowell
Sent: Wednesday, September 10, 2014 11:07 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] Is there a way ...
Dell - Internal Use - Confidential
Tested it on a 32-bit system and it worked (after updating my USB key with a
shell 2.0 version of BOOTIA32.efi that is).
Ok, now the question is how to take the output of the ver command and use it in
an nsh file to read the 64 or 32.
Any ideas? ... I find the shell command very limiting in this respect.
</Lowell>
From: Dennis, Lowell
Sent: Wednesday, September 10, 2014 9:07 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] Is there a way ...
Thanks Allen,
FS0:\> ver -s -_pa
2.0
64
Seems to work. I do not have any IA32 H/W at the moment. Could someone who
does have IA32 H/W please try it out and verify that it indicates 32-bit.
- Lowell
-----Original Message-----
From: Wynn, Allen
Sent: Wednesday, September 10, 2014 8:47 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] Is there a way ...
Have you tried following?
ver -_pa
See ShellPkg\Library\UefiShellLevel3CommandsLib\Ver.c (snippet below)
//
// implementation specific support for displaying processor architecture
//
if (ShellCommandLineGetFlag(Package, L"-_pa")) {
ShellPrintEx(-1, -1, L"%d\r\n", sizeof(UINTN)==sizeof(UINT64)?64:32);
}
Best Regards,
Allen
-----Original Message-----
From: Andrew Fish [mailto:[email protected]]
Sent: Tuesday, September 9, 2014 3:53 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] Is there a way ...
On Sep 9, 2014, at 1:44 PM, Laszlo Ersek wrote:
> On 09/09/14 21:52, [email protected]<mailto:[email protected]>
> wrote:
>> *Dell - Internal Use - Confidential *
>
> (not very confidential...)
But some lawyer is happy.
>
>> I would like to know if there is a way from the EFI shell to
>> determine if this is a 32-bit or 64-bit environment.
>>
>> For the most part, I am using BOOTX64.efi.
>>
>> However, it would be nice to be able to gracefully handle the
>> situation where BOOTIA32.efi was used.
>>
>> For example, let's say I have a home grown utility that has a 32-bit
>> and a 64-bit efi file. How do I determine which one to use from an nsh
>> script?
>
> When in doubt, use brute force, I guess. Start the 64-bit variant, and
> if it fails, start the 32-bit one. LoadImage() won't let you load a
> binary with incorrect bitness (or another architecture mismatch). IIRC
> the return value in this case is EFI_UNSUPPORTED.
>
>From C code, you can use #ifdef to figure out your image type.
#ifdef MDE_CPU_X64
#ifdef MDE_CPU_IA32
The DXE Core uses the EFI_IMAGE_MACHINE_TYPE_SUPPORTED() macro. It tells you if
the PE/COFF image type is supported.
The image types from the PE/COFF header are:
///
/// PE32+ Machine type for IA32 UEFI images.
///
#define EFI_IMAGE_MACHINE_IA32 0x014C
///
/// PE32+ Machine type for IA64 UEFI images.
///
#define EFI_IMAGE_MACHINE_IA64 0x0200
///
/// PE32+ Machine type for EBC UEFI images.
///
#define EFI_IMAGE_MACHINE_EBC 0x0EBC
///
/// PE32+ Machine type for X64 UEFI images.
///
#define EFI_IMAGE_MACHINE_X64 0x8664
///
/// PE32+ Machine type for ARM mixed ARM and Thumb/Thumb2 images.
///
#define EFI_IMAGE_MACHINE_ARMTHUMB_MIXED 0x01C2
///
/// PE32+ Machine type for AARCH64 A64 images.
///
#define EFI_IMAGE_MACHINE_AARCH64 0xAA64
Thanks,
Andrew Fish
> Granted, this might not allow you to tell apart genuine error exits of
> the application from "failed to load due to wrong bitness". For that
> case, write an empty application (one that returns with success from
> main() immediately), and use the brute force approach on those -- they
> can't really fail due to any other reason than wrong bitness. Then key
> off the real application's selection from this result.
>
> Just my 2 cents.
>
> Laszlo
>
>
> ----------------------------------------------------------------------
> --------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.
> clktrk _______________________________________________
> edk2-devel mailing list
> [email protected]<mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
