On Sat, 2013-02-02 at 01:23 +0100, Laszlo Ersek wrote:
> On 02/02/13 00:17, David Woodhouse wrote:
>
> > My own commits no longer exist in the form
> > that I made and tested them; they get committed on top of whatever
> > *other* work happened in the SVN tree before I finally got them merged.
>
Well, I'll offer my two cents then: I mostly avoid projects that use git.
That's the problem with anecdotal data...
Cameron Esfahani
di...@apple.com
On Feb 1, 2013, at 11:35, David Woodhouse wrote:
> FWIW as a purely anecdotal data point, I *often* avoid projects that are
> in Subversion. I'l
Currently, StdLib is only for building applications which run under the Shell.
StdLib also constructs an environment, as specified by ISO/IEC 9899:199409 (the
C Language Specification), to support the signal(), abort(), exit handlers, and
environment variables (NOT EFI variables). Currently, t
On 02/02/13 00:17, David Woodhouse wrote:
> My own commits no longer exist in the form
> that I made and tested them; they get committed on top of whatever
> *other* work happened in the SVN tree before I finally got them merged.
I don't think you can avoid that with series sent to the list for
r
Well, barring terminology issues, yes. You can use the EFI Boot Services
LoadImage() and StartImage(). If the x.efi installs a protocol before
StartImage() is called, then y.efi should be able to find the protocol produces
by x.efi and use it.
The Shell (ShellPkg) does this: it is an applicatio
Folks,
Would like to know whether it is possible to load one efi executable from
other. Say I have two applications x.efi and y.efi and whether I can read y.efi
into a buffer in x.efi through file read and execute y.efi from x.efi (as a
separate process) and utilizes the services provides by y.
Currently the StdLib is tied to the Shell in several other ways, including the
conin/conout/stderr redirection, environment variables, etc.
There is another version in the works that (Daryl, correct me if I'm wrong)
allows UEFI non-shell applications and UEFI drivers to use the StdLib for those
Okay, I found some of the examples in AppPkg and got my hello to work by
setting the ENTRY_POINT to ShellCEntryLib and the other stuff below. But
then looking at what ShellCEntryLib does is use a protocol
gEfiShellParametersProtocolGuid which is setup by the Shell when it
executes the application.
On Fri, 2013-02-01 at 12:15 -0800, Andrew Fish wrote:
>
> So I'd say my vote is:
> 1) Move to git if we can preserve the metadata in svn.
Yes, git can preserve all the data that SVN has. It's fairly much a
no-brainer to move from running the git tree as an automated mirror of
the SVN tree, to ju
On 02/01/2013 01:33 PM, Olivier Martin wrote:
> ARM and Linaro (Ryan, correct me if I am wrong) already use GIT as their
> primary interface for Tianocore. And EDK2 project moving to GIT will make
> our life easier.
>...
> -Original Message-
> From: Jordan Justen [mailto:jljus...@gmail.com]
On Feb 1, 2013, at 11:52 AM, Jordan Justen wrote:
> On Fri, Feb 1, 2013 at 11:33 AM, Olivier Martin
> wrote:
>> Linaro maintains their own git-svn service:
>> http://git.linaro.org/gitweb?p=mirror/edk2/edk2.git;a=summary
>
> Andrew,
>
> While I agree with you that git-svn is a great thing f
On Fri, Feb 1, 2013 at 11:33 AM, Olivier Martin wrote:
> Linaro maintains their own git-svn service:
> http://git.linaro.org/gitweb?p=mirror/edk2/edk2.git;a=summary
Andrew,
While I agree with you that git-svn is a great thing for working with
svn, here is another example of how git-svn is so clo
On Fri, 2013-02-01 at 11:23 -0800, Jordan Justen wrote:
>
> The data we will never have is how many people avoid getting involved
> in the project because it uses svn rather than git. I think if it were
> possible to measure this, it would favor git compared to svn.
FWIW as a purely anecdotal dat
ARM and Linaro (Ryan, correct me if I am wrong) already use GIT as their
primary interface for Tianocore. And EDK2 project moving to GIT will make
our life easier.
Linaro maintains their own git-svn service:
http://git.linaro.org/gitweb?p=mirror/edk2/edk2.git;a=summary
I am using the Sourceforge m
I guess we should have changed the subject on this thread a while back. :)
I hope some people might look back over the
"[PATCH] Fix broken IA32 Microsoft assembler code in QemuFwCfgLib."
thread if they are interested in this discussion.
On Tue, Jan 29, 2013 at 10:37 AM, Andrew Fish wrote:
> I do
On Feb 1, 2013, at 10:46 AM, "David F." wrote:
> Is that an optional thing some packages may include, some type of .inc file?
> Anyway, did that and that leads to:
>
Yes that .inc is just connivence, and not common.
> c:\edk2\testpkg\testpkg.dsc(...): error 4000: Instance of library class
On Feb 1, 2013, at 7:44 AM, David Woodhouse wrote:
> On Fri, 2013-02-01 at 03:57 -0800, Andrew Fish wrote:
>>
>> Kevin,
>>
>> This was all a long time ago, and my memory is fuzzy on things
>> 16-bits
>>
>> It looks like generic CSM code locks the 0xC - 0xF region
>> prior to boot
You want MdeModulePkg/Library/UefiHiiLib
From: David F. [mailto:df7...@gmail.com]
Sent: Friday, February 01, 2013 10:47 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Adding printf via StdLib
Is that an optional thing some packages may include, some type of .inc file?
Anyway, did
Is that an optional thing some packages may include, some type of .inc
file? Anyway, did that and that leads to:
c:\edk2\testpkg\testpkg.dsc(...): error 4000: Instance of library class
[HiiLib] is not found
in [c:\edk2\ShellPkg\Library\UefiShellLib\UefiShellLib.inf] [X64]
consumed
David -
The easiest way is just to put
!include StdLib\StdLib.inc
At the end of your testpkg.dsc
From: David F. [mailto:df7...@gmail.com]
Sent: Friday, February 01, 2013 10:11 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Adding printf via StdLib
Hi,
Still learning the build system
Hi,
Still learning the build system - I used the driver wizard to create a new
package and driver, modified to be application, and used the SystemTable to
print out some text. That all worked fine, so my next step is to use
printf instead. So I added Stdio|StdLib/LibC/Stdio/Stdio.inf to the .dsc
On Feb 1, 2013, at 5:01 AM, Alexei Fedorov wrote:
> Andrew thanks for your explanation.
> What's about the 2nd item?
> 2. SerialPortWrite() function returns 0, which makes SerialWrite() finction
> in SerialIo.c return EFI_TIMEOUT error causing UEFI image to hang. This might
> be fixed by chang
On Fri, 2013-02-01 at 03:57 -0800, Andrew Fish wrote:
>
> Kevin,
>
> This was all a long time ago, and my memory is fuzzy on things
> 16-bits
>
> It looks like generic CSM code locks the 0xC - 0xF region
> prior to boot, and I seem to remember that this was the common
> practice at
Andrew thanks for your explanation.
What's about the 2nd item?
2. SerialPortWrite() function returns 0, which makes SerialWrite() finction in
SerialIo.c return EFI_TIMEOUT error causing UEFI image to hang. This might be
fixed by changing return value to NumberOfBytes.
Alexei.
-- IMPORTANT NOTICE
Fwiw I have prodded OpenBSD folks about their bug that we are effectively
working around, and given them an OVMF+CSM image to reproduce.
--
dwmw2
(Apologies for HTML and top-posting; Android mailer is broken.)
Original message
From: Laszlo Ersek
Date:
To: edk2-devel@list
On Feb 1, 2013, at 1:59 AM, Laszlo Ersek wrote:
> On 01/29/13 19:37, Andrew Fish wrote:
>>
>> On Jan 29, 2013, at 10:28 AM, David Woodhouse wrote:
>>
>>> If we're taking the 'proposal' seriously, then I'll do it all. The
>>> constant pain of dealing with Subversion (or even a SVN-based workfl
On Jan 29, 2013, at 1:45 PM, Kevin OConnor wrote:
> I'm a bit surprised that OVMF would mark all of the 0xc-0xf
> area as read-only. There are lots of old programs that want to use
> parts of that area as memory.
Kevin,
This was all a long time ago, and my memory is fuzzy on things 16
Anyone feeling like reviewing this? :) It replaces:
- package with 1 dword (= prefix + data) elements
with
- package with 4 byte (= prefix + data) elements
Thanks
Laszlo
On 01/24/13 13:32, Laszlo Ersek wrote:
> Such packages should be more compatible with AML parsers in practice:
>
> /*
>
On 01/29/13 19:37, Andrew Fish wrote:
>
> On Jan 29, 2013, at 10:28 AM, David Woodhouse wrote:
>
>> If we're taking the 'proposal' seriously, then I'll do it all. The
>> constant pain of dealing with Subversion (or even a SVN-based workflow)
>> more than exceeds the one-off cost of updating docs
29 matches
Mail list logo
