Jordan,
It's hard to maintain such ApStartup.c that is translated by one ASM file.
For short term, I agree to keep ApStartup.c file with comments in the C code
like what it has already done.
For long term, I prefer to add ASM files in arch directory. We could reduce the
count of asm files due
On 2014-11-05 22:11:40, Fan, Jeff wrote:
> Chen,
>
> Thanks your updating. I attached one addition updating based on
> you're the latest patches. Please evaluate and sync it into your
> patches.
I think it is better to point out the changes and let Chen make
the changes. (Instead of sending a pat
Chen,
Thanks your updating. I attached one addition updating based on you're the
latest patches. Please evaluate and sync it into your patches.
BTW, please delete ApStartup.asm from CpuDxe, it seems to be one dummy file.
Thanks!
Jeff
-Original Message-
From: Chen Fan [mailto:chen.fan.f.
On 10/31/2014 3:23 PM, Bruce Cran wrote:
> On 10/31/2014 9:36 AM, Carsey, Jaben wrote:
>> Looks like a minor bug. Can you submit a patch?
>
> Thanks. I've attached a patch against svn/branches/UDK2014.SP1.
It sounds like the UDK2014 SP1 has been delayed, but would it be
possible for someone to r
Hi, all
Please send your comments before the end of this week. If no comments, I will
help commit this patch into EDKII BaseTools next week.
Thanks
Liming
-Original Message-
From: Gao, Liming [mailto:liming@intel.com]
Sent: Friday, October 31, 2014 4:32 PM
To: Jordan Justen
Cc: ed
On 2014-11-05 19:19:26, Andrew Fish wrote:
>
> > On Nov 5, 2014, at 6:47 PM, Gao, Liming wrote:
> >
> > Jordan:
> > This patch updates module INF with .nasm only, and remove the original
> > .asm and .S. Right?
> >
> > After apply this patch, all developers are required to install nasm
> >
On 2014-11-05 19:23:24, Yao, Jiewen wrote:
> Hi
> I have concern on removing original .asm and .S file, without a full
> validation for .nasm file.
>
> I am fine on adding .nasm. But can we still keep original .asm and
> .S file?
We should do a 'full validation' at this stage *before* making the
On 2014-11-05 18:47:53, Gao, Liming wrote:
> Jordan:
> This patch updates module INF with .nasm only, and remove the original .asm
> and .S. Right?
>
> After apply this patch, all developers are required to install nasm
> compiler.
Yes.
-Jordan
> -Original Message-
> From: Justen
Hi
I have concern on removing original .asm and .S file, without a full validation
for .nasm file.
I am fine on adding .nasm. But can we still keep original .asm and .S file?
Thank you
Yao Jiewen
-Original Message-
From: Gao, Liming
Sent: Thursday, November 06, 2014 10:48 AM
To: Juste
> On Nov 5, 2014, at 6:47 PM, Gao, Liming wrote:
>
> Jordan:
> This patch updates module INF with .nasm only, and remove the original .asm
> and .S. Right?
>
> After apply this patch, all developers are required to install nasm
> compiler.
>
We require the option of NOT using nasm with
Dear All,
This patch is going to put all -I or /I options followed by include search path
into a file (inc.lst) just as object files and static library files.
There are cases that too many /I options on the command line, and NMAKE fails
due to command-line length limitation.
Please let me know
Hi, experts:
I am studying IA32/X64 Programmer manual.
There is a sentence(Volume-3A, 10.11.5 Section):
On a hardware reset, the P6 and more recent processors clear the valid
flags in variable-range MTRRs and
clear the E flag in the IA32_MTRR_DEF_TYPE MSR to disable
all MTRRs. All other bits
Jordan:
This patch updates module INF with .nasm only, and remove the original .asm
and .S. Right?
After apply this patch, all developers are required to install nasm compiler.
Thanks
Liming
-Original Message-
From: Justen, Jordan L
Sent: Thursday, November 6, 2014 10:01 AM
To: ed
Nope. I don't plan to actually send out these 345 patches. :)
But, these patches are available in git:
git://github.com/jljusten/edk2 nasm-edk2-core
or
https://github.com/jljusten/edk2.git nasm-edk2-core
Or, view the branch in a web browser:
https://github.com/jljusten/edk2/tree/nasm-edk2-core
Of cause.
Best Regards & Thanks,
LONG, Qin
-Original Message-
From: Justen, Jordan L
Sent: Thursday, November 06, 2014 9:23 AM
To: Long, Qin
Cc: Ye, Ting; edk2-devel@lists.sourceforge.net
Subject: RE: [PATCH 0/5] Convert CryptoPkg GNU assembly to NASM
On 2014-11-05 16:58:33, Long, Qin
On 2014-11-05 16:58:33, Long, Qin wrote:
> Yes. I took over the ownership of CryptoPkg. Sorry I missed this patch.
>
> The patch looks good to me. (BTW: These assembly codes in
> "BaseCryptLib/SysCall/Ia32" have no direct links for current crypto
> primitives, and may be cleaned-up from this fold
Yes. I took over the ownership of CryptoPkg. Sorry I missed this patch.
The patch looks good to me. (BTW: These assembly codes in
"BaseCryptLib/SysCall/Ia32" have no direct links for current crypto primitives,
and may be cleaned-up from this folder. But these updates will be still useful
when
> On Nov 5, 2014, at 8:08 AM, jim_dai...@dell.com wrote:
>
> I'm building an EFI utility under Windows. I want to compress some data and
> append
> it to the utility. Later, when the utility is executed in the EFI shell, I
> want to
> have the utility decompress the data.
>
> I tried using Ba
See DuetPkg. It uses LzmaCompress
——
@echo Compressing DxeMain.efi ...
@%BASETOOLS_DIR%\LzmaCompress -e -o %BUILD_DIR%\FV\DxeMain.z
%BUILD_DIR%\%PROCESSOR%\DxeCore.efi
——
and UefiDecompressLib
——
UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
——
It is working….
Qin Long,
Sorry. It looks like Hot updated CryptoPkg in Maintainers.txt to list
you as the maintainer, but I looked at an older version and CC'd Ye
Ting instead when sending out these patches.
-Jordan
On 2014-11-01 13:06:02, Jordan Justen wrote:
> I converted the CryptoPkg IA32 GNU assembly to N
On Wed, Nov 05, 2014 at 08:54:23AM -0800, Jordan Justen wrote:
> I think we should convert each one in a separate commit. This allows
> 'git bisect' to work its magic. :)
Ok, I will fix that tomorrow.
> If you run: python BaseTools/Scripts/ConvertMasmToNasm.py --git OvmfPkg
> then the script shou
On 2014-11-04 11:41:50, Laszlo Ersek wrote:
> Jordan, if you drop the first two patches form this series, then the
> rest (patches v2 3/9 to 9/9) apply just as fine, and work as intended
> (on top of Eric's patch). If you're OK with the series in that form (as
> in, R-b), then I'll await Eric's com
I think we should convert each one in a separate commit. This allows
'git bisect' to work its magic. :)
If you run: python BaseTools/Scripts/ConvertMasmToNasm.py --git OvmfPkg
then the script should produce individual commits for each assembly
file.
-Jordan
On 2014-11-05 06:21:42, Anthony PERARD
> On Nov 5, 2014, at 2:00 AM, Laszlo Ersek wrote:
>
> On 11/05/14 00:02, Andrew Fish wrote:
>>
>>> On Nov 4, 2014, at 2:32 PM, Jordan Justen wrote:
>>>
>>> On Tue, Nov 4, 2014 at 9:28 AM, Andrew Fish wrote:
So my 1st question is why do you need to mix calling conventions, and
depe
I'm building an EFI utility under Windows. I want to compress some data and
append
it to the utility. Later, when the utility is executed in the EFI shell, I want
to
have the utility decompress the data.
I tried using BaseTools\Bin\Win32\LzmaCompress.exe to compress the data and
found
that it d
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
all *.asm to *.nasm.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
.../XenBusDxe/Ia32/InterlockedCompareExchange16.S | 15 ---
...nge16.asm => InterlockedCompareExchange
I am now able to load the Intel BDS, but I'm having some trouble with
receiving console
input with ArmPlatformPkg BDS or Intel BDS. I've got
gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-43
5F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi()"
gArmPlatformTokenSpaceGuid.Pc
Build:
. edksetup.sh
make -C "$EDK_TOOLS_PATH"
nice build -p OvmfPkg/OvmfPkgX64.dsc -b DEBUG -t GCC48 -a X64 \
-n $(getconf _NPROCESSORS_ONLN)
Run:
cp Build/OvmfX64/DEBUG_GCC48/FV/OVMF_VARS.fd vars.fd
qemu-system-x86_64 \
-nodefaults \
-nodefconfig \
-nographic \
\
On 11/05/14 11:00, Laszlo Ersek wrote:
> I wish I could write a small reproducer for this problem...
I wrote such a reproducer. I'll post it as a separate patch, just for
discussion. If we all agree that the code should work, then I could turn
it into a gcc bug report.
Thanks!
Laszlo
-
On 11/05/14 00:02, Andrew Fish wrote:
>
>> On Nov 4, 2014, at 2:32 PM, Jordan Justen wrote:
>>
>> On Tue, Nov 4, 2014 at 9:28 AM, Andrew Fish wrote:
>>> So my 1st question is why do you need to mix calling conventions, and depend
>>> on EFIAPI for interoperability. Why not just change the ABI on
30 matches
Mail list logo
