The PCDs I'm using for BBB show listed under 'Discarded input sections' in
ArmPlatformPrePiUniCore.map, wheareas when building OvmfPkgX64, PCDs
are not discarded.
So I am thinking,
* Does this mean they are not being referenced properly? I'll checkout how
OvmfPkg
is using them.
* Is 'GLOBAL_REMOVE
I have just looked at the BeagleBoard and the result seems correct:
$ build -a ARM -p BeagleBoardPkg/BeagleBoardPkg.dsc -t GCC48
$
/work/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-objdump
-S -D
Build/BeagleBoard/DEBUG_GCC48/ARM/ArmPlatformPkg/PrePi/PeiUniCor
On 07/23/14 02:23, Laszlo Ersek wrote:
> Recent BaseTools changes trigger this gcc warning.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek
> ---
> OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.c | 16
> 1 file changed, 8 insertions(+), 8 del
On Tue, Jul 29, 2014 at 3:34 PM, Olivier Martin
wrote:
> $
/work/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-objdump
-S -D
Build/BeagleBoard/DEBUG_GCC48/ARM/ArmPlatformPkg/PrePi/PeiUniCore/DEBUG/ArmPlatformPrePiUniCore.dll
>
>
>
> FdTop = (EFI_PHYSICAL_ADDRESS)PcdGet
Thanks for the pointer, Liming.
I had to add some rules to the binary FDF I created, and I think I messed
one of them up.
Are the Offset.raw files affected by the rules too? If some of these
files were missing (as they are in my binary build), would it likely affect
the integrity of the BIOS
Hi,
I can recall two or three cases where I would have opted for an
associative data structure, instead of open-coded, possibly nested,
linear searches (lists / arrays), had such structure(s) been there in
edk2. (Alternatively, if they already exist: had I known about them.)
So, do we have such s
Jim,
I noticed some issues with using GenFds as a standalone tool with respect to
the generated files related to the PCD Database.
Right now, I recommend using build.exe, even when you are only working with
binaries. Build.exe will generate the PCD database files and will internally
invoke Gen
On Jul 29, 2014, at 5:32 AM, Varad Gautam wrote:
> On Tue, Jul 29, 2014 at 3:34 PM, Olivier Martin
> wrote:
> > $
> > /work/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-objdump
> > -S -D
> > Build/BeagleBoard/DEBUG_GCC48/ARM/ArmPlatformPkg/PrePi/PeiUniCore/DEBUG/
Mike,
Are you saying that PCDs have something to do with the xxxOffset.raw files, or
do you have some other concern?
Regards,
Jim
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Tuesday, July 29, 2014 10:28 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Building fr
On Tue, Jul 29, 2014 at 4:53 AM, Laszlo Ersek wrote:
> On 07/23/14 02:23, Laszlo Ersek wrote:
>> Recent BaseTools changes trigger this gcc warning.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek
>> ---
>> OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.c |
Hi,
Am facing some issue with Event & Timer. I tried using Event (Type - EVT_TIMER
| EVT_NOTIFY_SIGNAL) and Timer for TriggerTime of 1 sec, but with this am
seeing some stack corruption and finally after some time system crashes.
Does anyone else also faced this issue with Event and Timer, if so
UEFI Shell 2.0 source is here -
https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellPkg/
Binary Package for x64 is here -
https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi
Thanks ... br
---
Brian Richardson -- brian.richard...@intel.com -- Twitter: intel_brian
On Jul 29, 2014, at 10:14 AM, ankit_sin...@dell.com wrote:
> Hi,
>
> Am facing some issue with Event & Timer. I tried using Event (Type -
> EVT_TIMER | EVT_NOTIFY_SIGNAL) and Timer for TriggerTime of 1 sec, but with
> this am seeing some stack corruption and finally after some time system
>
Every copy of EFI Shell V2.0 that I have found seems to have a file processing
bug.
It looks like appending to a file does not work as expected. The following
shell snippet does not work:
del test.dat
echo 1234 >> test.dat# This works
lowell_den...@dell.com [mailto:lowell_den...@dell.com] wrote:
]All,
]
]I have tried downloading from EDK2 site and tried using what local
]people are sending me, but when I issue the ver s command they
]all say they are EFI Shell Version 1.0.
]
]The only one I have (and I dont know where I got
Mike,
Build requires many unnecessary files be copied to the binary build tree--all
the DEC files, for example. So, if PCDs aren't causing/related to my missing
Offset.raw files, I'm going to keep working toward the minimum binary
build setup/process.
Now if anyone can clue me in to what cau
The UEFI Shell is getting more attention with the updates to the Shell 2.1
specification at uefi.org. The UEFK 2.4 SCT is also being built to run without
dependencies on the EDK Shell ("Shell 1.0"). But the issues in ShellPkg do need
a bit more focus from developers. This mailing list is a good
Hi everyone.
I have a question about the GOP protocol.
I did an application to print all graphic modes that my system can work,
and got the following list:
Graphic Modes: 17
Mode: 0, Horizontal Resolution: 320, Vertical Resolution: 200
Mode: 1, Horizontal Resolution: 320, Vertical Resolution: 240
Jim,
If you have any DynamicEx PCDs in any of your INF files listed in your FDF
file, then you will need to use build.exe instead of just GenFds to build a
complete PCD Database and have it integrated into final image. Not having a
complete PCD Database will cause execution issues if DynamicEx
On 07/29/2014 08:50 AM, Laszlo Ersek wrote:
> Hi,
>
> I can recall two or three cases where I would have opted for an
> associative data structure, instead of open-coded, possibly nested,
> linear searches (lists / arrays), had such structure(s) been there in
> edk2. (Alternatively, if they already
On Jul 29, 2014, at 12:45 PM, Brian J. Johnson wrote:
> On 07/29/2014 08:50 AM, Laszlo Ersek wrote:
>> Hi,
>>
>> I can recall two or three cases where I would have opted for an
>> associative data structure, instead of open-coded, possibly nested,
>> linear searches (lists / arrays), had such s
Hi,
It is not a hardware issue. It is a problem of driver that provided GOP.
The driver should be able to set any graphics mode that supported both by
monitor and by VideoCard.
If not supported then the driver have not to report existence of such modes.
Best,
Sergey.
On 29 июля 2014 г., at 23:3
On 07/29/14 20:18, lowell_den...@dell.com wrote:
> Every copy of EFI Shell V2.0 that I have found seems to have a file
> processing bug.
>
>
>
> It looks like appending to a file does not work as expected. The
> following shell snippet does not work:
>
>
>
> del test.dat
>
The >> operator redirects stdout to a file, using append mode and unicode
encoding. Write the BOM when redirection happens to a new file (which
starts out empty).
This makes the >> operator behave similarly to the > operator, when the
redirection target doesn't exist originally:
OutUnicode && O
The >> operator should act similarly to the > operator when the
redirection target doesn't exist: it should write the UCS-2 BOM (byte
order mark).
Currently this doesn't happen. Therefore files created with the >>
operator are not recognized later as UCS-2 files, by the other shell
functions / red
Drop TagBuffer in the process.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
.../Application/Shell/ShellParametersProtocol.c| 48 +++---
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/ShellPkg/Application/Shell/ShellP
Reviewed-by: Jaben Carsey
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, July 29, 2014 3:27 PM
To: edk2-devel@lists.sourceforge.net; lowell_den...@dell.com
Subject: [edk2] [PATCH 1/2] ShellPkg: UpdateStdInStdOutStdErr(): extract
WriteFileTag()
Drop TagB
If you write to the file and the original size was zero, don't you need to
update the file size before moving to that location?
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, July 29, 2014 3:27 PM
To: edk2-devel@lists.sourceforge.net; lowell_den...@dell.c
Regarding appending from Uefi Shell 2.0, it is behaving as written:
echo 1234 > test.dat # Writes 14 bytes to file "test.dat": L"1234\r\n"
prefixed with the Unicode Byte Ordering Mark (0xFFFE).
del test.dat
echo 1234 >> test.dat# Writes 12 bytes to file "test.dat": L"1234\r\n" with
N
On 07/30/14 00:51, Carsey, Jaben wrote:
> If you write to the file and the original size was zero, don't you need to
> update the file size before moving to that location?
The FileSize variable is not updated in the WriteFileTag() branch
because FileSize is not used at any later point.
In additi
I think that the question is:
Should appending to a non-existent UNICODE file automatically write the FFFE?
From: Mcdaniel, Daryl [mailto:daryl.mcdan...@intel.com]
Sent: Tuesday, July 29, 2014 4:08 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Bug in EFI Shell V2.0
Regarding append
Good point. I missed the ?: operation in the patch.
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, July 29, 2014 4:13 PM
To: Carsey, Jaben; edk2-devel@lists.sourceforge.net; lowell_den...@dell.com
Subject: Re: [edk2] [PATCH 2/2] ShellPkg: UpdateStdInStdOu
Hi,
I'm writing a filesystem driver and having some trouble with the filenames
I pass on UEFI shell.
I don't know whether it's related to the filenames I store for new file
handles on my Open() function, or UEFI shell is mangling them wrongly.
Follow the steps to reproduce such issue on shell:
Dell - Internal Use - Confidential
I think that the bigger question has to do with the programming interface ...
recall that I said that opening the file for append in Python was not working
... exactly how does one open a file in Python or C in 'ascii' mode as opposed
to 'unicode' mode anyway?
Dell - Internal Use - Confidential
Actually the log file was created running Python 2.7 in Windows before
rebooting into the EFI shell and running another Python program that tries to
append it. This is where I am seeing the problem.
From: Mcdaniel, Daryl [mailto:daryl.mcdan...@intel.com]
Sent
35 matches
Mail list logo
