d performance?
>
> Thanks
> Liming
> >-Original Message-
> >From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com]
> >Sent: Saturday, June 30, 2018 2:47 PM
> >To: edk2-devel-01 ; Zhu, Yonghong
> >; Gao, Liming
> >Subject: [edk2] Ques
Out of curiosity I took a closer look at how the build system works
internall(especially the Makefile generation and parallel builds) and
I got some questions which I hope you can answer:
Why are we using make at all?
As far as I can see we're not using any special make functionality and
most depe
ElfConvert iterates over the section headers and handles the following
section types:
SHT_PROGBITS: Copy
SHT_NOBITS: memset to 0
the default case looks like this:
//
// Ignore for unkown section type.
//
VerboseMsg ("%s unknown section type %x. We directly copy this section
into Coff file", mInIm
yes I'll do that next time. Thanks for the hint.
Thanks
Michael
On Thu, Jun 7, 2018 at 9:10 AM Ard Biesheuvel wrote:
>
> On 7 June 2018 at 07:08, Michael Zimmermann wrote:
> > CC the arm maintainers
> > On Thu, Jun 7, 2018 at 7:07 AM Michael Zimmermann
> >
Hi Ard,
yes that fixes the problem too and looks much better, thx!
On Thu, Jun 7, 2018 at 9:05 AM Ard Biesheuvel wrote:
>
> On 7 June 2018 at 07:47, Michael Zimmermann wrote:
> > This was the warning(shown for __aeabi_memcpy, __aeabi_memcpy4 and
> > __aeabi_memcpy8):
ote: aliased declaration
here
void *__memcpy(void *dest, const void *src, size_t n)
The problem is the different return type(void vs void*).
This commit adds a wrapper '__aeabi___memcpy' with a void return value.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: M
CC the arm maintainers
On Thu, Jun 7, 2018 at 7:07 AM Michael Zimmermann
wrote:
>
> From: M1cha
>
> GCC8 reported it with the following warning:
> ArmPkg/Library/ArmDisassemblerLib/ArmDisassembler.c: In function
> 'DisassembleArmInstruction':
> Ar
checked later using 'I', which results in the following value:
0x0120: 00010 0 10 00 00
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Zimmermann
---
ArmPkg/Library/ArmDisassemblerLib/ArmDisassembler.c | 2 +-
1 file change
I looked at ARMs TimerDxe and saw that mTimerNotifyFunction is called with
TPL_HIGH_LEVEL but didn't realize that RestoreTPL would call all pending
events.
Thank you for your help.
On Sun, May 13, 2018 at 1:39 PM Ard Biesheuvel
wrote:
> On 13 May 2018 at 12:58, Michael Zimmerman
is not
> going to change.
> > On Sun, May 13, 2018 at 9:32 AM Ard Biesheuvel <
ard.biesheu...@linaro.org>
> > wrote:
> >
> >> On 12 May 2018 at 23:11, Michael Zimmermann
> > wrote:
> >> > For AArch32 the spec says in 2.3.5.3:
> >> >> Fl
018 at 9:32 AM Ard Biesheuvel
wrote:
> On 12 May 2018 at 23:11, Michael Zimmermann
wrote:
> > For AArch32 the spec says in 2.3.5.3:
> >> Floating point, SIMD, vector operations and other instruction set
> > extensions must not
> > be used.
> >
> > For AA
For AArch32 the spec says in 2.3.5.3:
> Floating point, SIMD, vector operations and other instruction set
extensions must not
be used.
For AArch64 the spec says in 2.3.6.4:
> Floating point and SIMD instructions may be used.
So is there a reason why AArch32 is not allowed to use Floating point
op
spec.
On Feb 28, 2018 9:19 AM, "Ard Biesheuvel" wrote:
> On 28 February 2018 at 08:15, Michael Zimmermann
> wrote:
> >> I agree. Did you run into any issues due to this?
> > Surprisingly no. I was just trying to understand the fastboot
> implementation
&g
ly doesn't do anything but
calling SetVirtualMemoryMap and ExitBootServices.
I can imagine that more complex loaders like the one used for Windows
wouldn't work this way.
On Wed, Feb 28, 2018 at 9:10 AM, Ard Biesheuvel
wrote:
> On 28 February 2018 at 07:56, Michael Zimmermann
> w
works that is bad luck, or
> good luck depending on your point of view.
>
> Sent from my iPhone
>
> > On Feb 27, 2018, at 11:33 PM, Michael Zimmermann <
> sigmaepsilo...@gmail.com> wrote:
> >
> > Are you sure?
> >
> > If you look at this fil
idBootImg -> StartEfiApplication ->
"gBS->StartImage"
Thanks
Michael
On Wed, Feb 28, 2018 at 8:29 AM, Ni, Ruiyu wrote:
> On 2/28/2018 2:06 PM, Michael Zimmermann wrote:
>
>> From looking at the code it seems to me that StartImage is called from
>> TPL_CALLBACK.
>>
>From looking at the code it seems to me that StartImage is called from
TPL_CALLBACK.
According to the Spec StartImage can only be called from https://lists.01.org/mailman/listinfo/edk2-devel
This currently isn't needed by anything in the edk2 tree but
it's useful for externally maintained platforms which have
to set this register e.g. to disable alignment aborts.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Zimmermann
---
ArmPkg/Inclu
We're currently building everything except for this file.
Since 'fdt_create_empty_tree' can be useful for some
platforms, compile this one too.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Zimmermann
---
EmbeddedPkg/Library/FdtLib/FdtLib.in
This currently isn't needed by anything in the edk2 tree but
it's useful for externally maintained platforms which have
to set this register e.g. to disable alignment aborts.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Zimmermann
---
ArmPkg/Inclu
ings when using them in functions which
> >should return a value but rely on LongJump to never return instead.
> >
> >Contributed-under: TianoCore Contribution Agreement 1.1
> >Signed-off-by: Michael Zimmermann
> >---
> >V3: fix VS compilation errors
> >
b.h(4933): error
> C2059: syntax error: 'type'
>
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 14.0\Vc\bin\cl.exe"' : return code '0x2'
>
> Stop.
>
>
>
> Thanks
>
> Liming
>
> *From:* Michae
ay, December 22, 2017 11:24 PM
> >To: M1cha
> >Cc: edk2-devel@lists.01.org; Kinney, Michael D
> >; Gao, Liming
> >Subject: Re: [edk2] [PATCH 1/3] MdePkg: add RETURNS_TWICE attribute
> >
> >On 22 December 2017 at 07:23, M1cha wrote:
> >> Contributed-under:
The reason for that is that I was lazy when doing copy&paste ;)
I'll send a v2.
On Fri, Dec 22, 2017 at 4:24 PM, Ard Biesheuvel
wrote:
> On 22 December 2017 at 07:23, M1cha wrote:
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-of
Is adding attributes to both header and source files an UEFI coding
convention?
Because for the compiler it's only necessary to do that in the header files
afaik.
Thanks
Michael
On Fri, Dec 22, 2017 at 6:55 PM, Kinney, Michael D <
michael.d.kin...@intel.com> wrote:
> I see the .h file updates he
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Zimmermann
---
EmbeddedPkg/Library/PrePiLib/FwVol.c | 63
1 file changed, 51 insertions(+), 12 deletions(-)
diff --git a/EmbeddedPkg/Library/PrePiLib/FwVol.c
b/EmbeddedPkg/Library/PrePiLib
gt; On 10 December 2017 at 22:18, Michael Zimmermann
> wrote:
>> Exactly. If I shift the pointer by 4 bytes from within PrePiLib the device
>> boots just fine.
>>
>> I'm not sure if the size is the root cause but right now it only happens
>> when adding a ~15
mber 2017 at 21:58, Michael Zimmermann
wrote:
> VolInfo doesn't seem to complain about FVMAIN_COMPACT.Fv:
> https://pastebin.com/ueUnepXF
>
> Does VolInfo support Fs's as well? because it fails on mine(even on a
> working one).
>
You mean to dissect the FFS that contain
VolInfo doesn't seem to complain about FVMAIN_COMPACT.Fv:
https://pastebin.com/ueUnepXF
Does VolInfo support Fs's as well? because it fails on mine(even on a
working one).
On Sun, Dec 10, 2017 at 10:49 PM, Ard Biesheuvel
wrote:
> On 10 December 2017 at 21:45, Michael Zimmermann
>
0:33 PM, Ard Biesheuvel
wrote:
> On 10 December 2017 at 21:22, Ard Biesheuvel
> wrote:
>> cc BaseTools maintainers
>>
>> On 10 December 2017 at 20:58, Michael Zimmermann
>> wrote:
>>> 'uefitool' shows me that there are 4 bytes of padding right b
'uefitool' shows me that there are 4 bytes of padding right before
FVMAIN when adding large(20MB) uncompressed FV's.
FwVol fails detecting that and complains about the signature not being correct.
Thanks
Michael
___
edk2-devel mailing list
edk2-devel@li
I've compiled EmulatorPkg using build.sh for x86_64 under Arch Linux
with GCC 7.2.0 and get this abort:
$ ./build.sh run
Initializing workspace
/edk2/BaseTools
Loading previous configuration from /edk2/Conf/BuildEnv.sh
WORKSPACE: /edk2
EDK_TOOLS_PATH: /edk2/BaseTools
CONF_PATH: /edk2/Conf
using pr
> I've been subscribed to edk2-devel (wherever it lived whenever) since
> approx. April 2012. So, I checked all my yearly archives, and the only
> year where the search expression "df7729 patch" returns at least one hit
> is 2013. Please don't judge the project's development process from a
> four y
ified) from glibc
which means that this part is GPL code.
Thanks
Michael Zimmermann
On Thu, Nov 2, 2017 at 8:37 PM, Blibbet wrote:
> On 11/02/2017 09:41 AM, Jayaprakash, N wrote:
>> Would you consider adding thread support in this port of Python for
> EDK2 shell?
>
> FYI, this li
I've never seen such tools for uefi but you could probably easily
implement them using CryptoPkg's openssl lib.
Thanks
Michael
On Tue, Oct 31, 2017 at 4:18 PM, Jeff Westfahl wrote:
> Hello all,
>
> I'm looking for tools that run in the UEFI shell and do typical hash
> functions on files. Basica
Do the axis-values returned by this protocol need to have any relation
to the device's screen so I can reliably calculate which pixel was
touched?(at least with the rule of three).
If not every application using the touchscreen would have to provide
it's own calibration tool and store the results
Good work making it way more usable on mobile devices.
Unfortunately the shadows, buttons and background make it look like a
website from 10 years ago ;)
If you fix the design issues it would actually be pretty good.
Thanks
Michael
On Jun 30, 2017 12:58 AM, "Jarlstrom, Laurie"
wrote:
> We are
if (EFI_ERROR(Status)) {
> //
> // Report Status code that some Architectural Protocols are not present.
> //
> REPORT_STATUS_CODE (
> EFI_ERROR_CODE | EFI_ERROR_MAJOR,
> (EFI_SOFTWARE_DXE_CORE | EFI_SW_DXE_CORE_EC_NO_ARCH)
> );
> }
> ASSERT_EFI_ERROR (Status);
>
>
&
> BlockIO is the DiskIo driver can know get connected. The DXE Core knows a
> protocol was added to the handle so it will keep trying to connect drivers to
> that handle as long as new protocols get added. So this is how the
> DriverBinding Support() is used to resolve the sequenc
I know that UEFI_DRIVERs don't need or support Depex sections, but
what if an UEFI_DRIVER depends on a protocol provided by another
UEFI_DRIVER?
Since they get loaded automatically because I put them in my
platform's fdf, it raises the question of the loading order.
Will they get loaded in the ord
Ok I've found it in "RelocatableVirtHelper.S".
Thanks
Michael
On Fri, Apr 14, 2017 at 8:04 AM, Michael Zimmermann
wrote:
> "contains some scratch memory at the start of the image to use as a
> stack very early on"
> When does this happen? I didn't see any
"contains some scratch memory at the start of the image to use as a
stack very early on"
When does this happen? I didn't see any edk2-code which sets SP to the
slack space.
Thanks
Michael
On Tue, Apr 4, 2017 at 5:02 PM, Ard Biesheuvel
wrote:
> On 4 April 2017 at 15:59, Laszlo Ersek wrote:
>> On
I'm doing the same in one of my projects where I link against a
prebuilt gcc lib.
Adding support for that is quite easy actually:
https://github.com/efidroid/edk2/commit/841473c1c86823521dfad5eb3d74461557302e42
On Thu, Apr 6, 2017 at 8:57 PM, Andrew Fish wrote:
>
>> On Apr 6, 2017, at 11:07 AM,
I just found out that ArmCpuLib seems to be unused even though it's
included in a few dsc files.
Is it deprecated and should we remove it or are there external users?
Thanks
Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org
elete cache Conf/tools_def.txt, and run edksetup again to apply new
> tools_def.txt.
>
> Thanks
> Liming
>>-Original Message-
>>From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com]
>>Sent: Thursday, March 30, 2017 5:04 AM
>>To: Gao, Liming
>>Cc:
How can I use this? If I change my compressed FV's GUID to
3D532050-5CDA-4FD0-879E-0F7F630D5AFB I get the following error:
GenFds.py...
: error F003: No tool found with GUID 3D532050-5CDA-4FD0-879E-0F7F630D5AFB
Thanks
Michael
On Mon, Mar 27, 2017 at 5:15 AM, Gao, Liming wrote:
> Reviewed-by: Li
right? How would that work when running from DRAM?(even if it wasn't
relocatable)
If that would work, why can't we make a relocatable version of Pei?
Thanks
Michael
On Mon, Mar 20, 2017 at 7:19 PM, Ard Biesheuvel
wrote:
> On 20 March 2017 at 16:06, Michael Zimmermann
> wrote:
&
Do I understand correctly, that a PcdSet on a 'PcdsPatchableInModule'
is only visible to the current module?(SEC, driver, application, ...)
Because I've tested this and a PcdSet on
gArmTokenSpaceGuid.PcdSystemMemoryBase inisde PrePi is not visible
inside a DXE_DRIVER - which means that for everyone
rch 2017 at 10:32, Michael Zimmermann
> wrote:
>> Hi,
>>
>> I didn't test ArmVirtQemuKernel but I'm trying to use some of the code
>> for another platform.
>> So does this call ever succeed with PcdDxeNxMemoryProtectionPolicy
>>
0 for unused memory and 0008 for used
memory.
This seems to confirm what Ard said about the GCD not being altered
for NX permissions.
Thanks
Michael
On Mon, Mar 20, 2017 at 12:06 PM, Laszlo Ersek wrote:
> On 03/20/17 11:32, Michael Zimmermann wrote:
>> Hi,
>>
>> I
Hi,
I didn't test ArmVirtQemuKernel but I'm trying to use some of the code
for another platform.
So does this call ever succeed with PcdDxeNxMemoryProtectionPolicy
being enabled?
https://github.com/tianocore/edk2/blob/76874be3d411bf8daac051718e20932e0bf97d70/ArmVirtPkg/HighMemDxe/HighMemDxe.c#L95
INPLATFORM
}
Thanks
Michael
On Thu, Mar 16, 2017 at 1:27 PM, Laszlo Ersek wrote:
> On 03/16/17 13:20, Michael Zimmermann wrote:
>> So if I understand this correctly there's no bug to fix because
>> nested, uncompressed FV's are already supported
>
> I'm not sure how
>>> On Mar 15, 2017, at 8:38 AM, Laszlo Ersek >> <mailto:ler...@redhat.com>> wrote:
>>>
>>> On 03/15/17 16:13, Andrew Fish wrote:
>>>>
>>>>> On Mar 15, 2017, at 8:07 AM, Laszlo Ersek >>>> <mailto:ler...@redhat.co
Andrew Fish wrote:
>
> On Mar 15, 2017, at 8:38 AM, Laszlo Ersek wrote:
>
> On 03/15/17 16:13, Andrew Fish wrote:
>
>
> On Mar 15, 2017, at 8:07 AM, Laszlo Ersek wrote:
>
> On 03/15/17 13:23, Michael Zimmermann wrote:
>
> I'm trying to add another FV secti
n't seem to take any section id or current
section pointer.
Thanks
Michael
On Wed, Mar 15, 2017 at 4:13 PM, Andrew Fish wrote:
>
>> On Mar 15, 2017, at 8:07 AM, Laszlo Ersek wrote:
>>
>> On 03/15/17 13:23, Michael Zimmermann wrote:
>>> I'm trying to add
I'm trying to add another FV section FVMAIN_COMPACT so I can keep
Platform specific drivers in a separate, included fdf.
I did this:
FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF
PROCESSING_REQUIRED = TRUE {
SECTION FV_IMAGE
I had to include because I was getting
this error:
EmbeddedPkg/Library/PrePiLib/PrePiLib.c: In function ‘AllocateCodePages’:
EmbeddedPkg/Library/PrePiLib/PrePiLib.c:59:3: error: implicit
declaration of function ‘FreePages’
[-Werror=implicit-function-declaration]
FreePages (Alloc, Pages);
Other th
> You are using PrePi, right?
yes. Isn't that supported yet? afaik ArmVirtXen uses PrePi too.
On Mon, Mar 13, 2017 at 9:50 AM, Ard Biesheuvel
wrote:
> On 13 March 2017 at 09:43, Michael Zimmermann
> wrote:
>> I fail to get this working on my target. I've enabled the f
I fail to get this working on my target. I've enabled the following
Pcd's like in ArmVirt:
gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy|0x3
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy|0xC0007FD1
gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
but apparentl
l:
> I agree this is a bug. Could you enter it into bugzillar?
>
> Thanks
> Liming
>> -Original Message-
>> From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com]
>> Sent: Sunday, March 12, 2017 12:44 AM
>> To: edk2-devel@lists.01.org
>> C
I forgot to CC the maintainers back then so I'm doing this now.
Thanks
Michael
On Thu, May 12, 2016 at 11:13 AM, Michael Zimmermann
wrote:
> Hi,
>
> when I override or set a variable using -DNAME=VAL from the build cmdline
> these are visible to the DSC file only, the FDF co
---
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>> Michael
>>> Zimmermann
>>> Sent: Thursday, March 2, 2017 4:06 AM
>>> To: Arka Sharma
>>> Cc: edk2-devel@lists.01.org
>>> Subject: Re: [edk2] "[edk
AFAIK the only way to do that is to use the platform specific TimerLib
like this:
UINT64
GetTimeMs (
VOID
)
{
return GetTimeInNanoSecond(GetPerformanceCounter()) / 100ULL;
}
Thanks
Michael
On Thu, Mar 2, 2017 at 12:53 PM, Arka Sharma wrote:
> gRT->GetTime() is accurate about seconds.Is
nothing of importance(and most likely not related to this commit
because it has been there before), but you misspelled staging as
'stagaing' :)
On Tue, Jan 31, 2017 at 7:45 PM, Michael Kinney
wrote:
> * Add Supreeth Venkatesh to list of branch owners
> * Clean up environment variable for Windows
mh after thinking about it, wouldn't it be better to swap the '<='
operands instead of changing the operator? this way the PCD memory
would be on the left side for both comparisons which seems more clear.
On Mon, Jan 16, 2017 at 7:43 PM, Michael Zimmermann
wrote:
> Th
cessful for the case we're checking for.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Zimmermann
---
ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
b/Arm
sry, but I forgot to CC the maintainers again so doing this with this
self-reply.
On Thu, Jan 12, 2017 at 4:46 PM, Michael Zimmermann <
sigmaepsilo...@gmail.com> wrote:
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Zimmermann
> ---
&g
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Zimmermann
---
ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
b/ArmPlatformPkg/MemoryInitPei
ke the KeyNotify functions called in
> TPL_CALLBACK to the new mantis.
>
>
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Michael Zimmermann
> Sent: Friday, December 9, 2016 8:09 PM
> To: edk2-de
es the first memory range. Could you submit it in
> bugzilla with the detail usage model? Then, we can continue to investgate how
> to resolve it.
>
> Thanks
> Liming
>> -----Original Message-
>> From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com]
>> Sent: Th
llocationHob(). It does work.
> Right?
>
> Thanks
> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Michael Zimmermann
>> Sent: Thursday, December 15, 2016 1:57 AM
>> To: Ard Biesheuvel
>
or the
resource descriptors.
If I use 0x8000,0x4000 and 0xc000,0x4000 everything
works just fine.
Thanks
Michael
On Wed, Dec 14, 2016 at 4:13 PM, Michael Zimmermann
wrote:
> As far as I know the proper way is to create resource descriptors
> using BuildResourceDescriptor
d big dram Hob's
(2GB and 6GB) too so why is this a problem?
Thanks
Michael
On Wed, Dec 14, 2016 at 11:21 AM, Ard Biesheuvel
wrote:
> On 14 December 2016 at 10:02, Michael Zimmermann
> wrote:
>> I tried both BuildResourceDescriptorHob and BuildMemoryAllocationHob
>> but appa
I tried both BuildResourceDescriptorHob and BuildMemoryAllocationHob
but apparently they don't have any effect.
When I look at the output of the shell's memmap command there aren't
any reserved/unavailable pages.
Furthermore, when using AllocatePages with one of the physical
addresses which I've r
these build command options are probably what you want:
-s, --silent Make use of silent mode of (n)make.
-q, --quiet Disable all messages except FATAL ERRORS.
-v, --verbose Turn on verbose output with informational messages
printed, includin
ust never apply optimizations
which could break such functions or is there no way of fixing this?
On Thu, Dec 8, 2016 at 3:32 PM, Ard Biesheuvel
wrote:
> On 8 December 2016 at 13:30, Michael Zimmermann
> wrote:
>> When compiling with any ARM toolchain and Os, registers can get
>> trashed w
I couldn't find any information in the spec about the TPL which notify
functions will/should be called with.
When I do File IO from within such an handler DxeCore tells me that
'RaiseTpl with OldTpl(0x10) > NewTpl(0x8)' which translated means
TPL_NOTIFY > TPL_CALLBACK.
That probably means that it'
When compiling with any ARM toolchain and Os, registers can get
trashed when returning for the second time from SetJump because GCC
only handles this correctly when using standard names like 'setjmp' or
'getcontext'. When different names are used you have to use the
attribute 'returns_twice' to tel
Laszlo,
can you explain the problems with putting GPL code in the fdf?
afaik every efi file is like a small self-contained application and
shouldn't the UEFI API's be excluded from derived work like the linux
kernel's system call table?
Thanks
Michael
On Wed, Nov 23, 2016 at 8:50 PM, Laszlo Erse
I wouldn't call this a stable implementation atm but I've ported all
filesystems supported by the linux kernel(ntfs, ext2/3/4, f2fs, ...)
including write support to UEFI using the LKL(Linux Kernel Library)
project.
https://github.com/efidroid/uefi_apps_LKL
Thanks
Michael
On Tue, Nov 22, 2016 at
Hi,
since the uefi logo guidlines are mainly targeted at "pure logo" usage I'm
not sure if the following would be legal:
https://raw.githubusercontent.com/efidroid/android_app_efidroidmanager/9d364dc4e8d59381d6c60404153c5dbf5aa4711a/app/src/main/res/mipmap-xxxhdpi/ic_launcher.png
I'm not working
COM ports may have had a naming scheme in past but in recent windows
versions you are allowed to assign any COM name to any device - even USB.
So he should really just obtain a handle to the correct protocol and try to
choose/configure the correct port if there is more than one.
Thanks
Michael
O
I actually sent a patch for Arm some time ago:
https://lists.01.org/pipermail/edk2-devel/2016-August/000489.html
Thanks
Michael
On Fri, Oct 21, 2016 at 9:37 PM, Ard Biesheuvel
wrote:
> I don't remember seeing any discussion regarding
> DISABLE_NEW_DEPRECATED_INTERFACES on the list, so I am a bi
Hi,
wouldn't it be better to make a generic gpt parsing library which is
independent of the shell so both the shell and PartitionDxe can use it?
It may also be useful for other applications which need additional
information like the gpt partition names.
Thanks
Michael
On Mon, Oct 17, 2016 at 8:4
> Is it possible to run RM (or any shell command) from my C application
code?
> Something like "System()" in Linux? Whether we can use LoadImage for this
> purpose?
If you application was started from the Shell you can do that
using ShellExecute from 'Library/ShellLib.h'. Example:
EFI_STATUS Statu
depending on his use case it can be unnecessary to do a low level FS format
though(he said that he just wants to delete all files).
It can also become problematic if you consider that the original filesystem
doesn't have to be FAT.
Thanks
Michael
On Wed, Oct 12, 2016 at 7:46 PM, Richardson, Bria
I'm using GMail and everything works just fine.
I don't remember if I got an verification mail, but to test if you're
really subscribed you just have to wait for mails which you were't CC'd in.
The list is quite active so you don't have to wait for long ;)
Thanks
Michael
On Thu, Sep 29, 2016 at 5
ently the cache cleaning
has no effect for the framebuffer of this device.
And it still confuses me that the UC/WC case - even with Blt stubbed - can
cause the system to just hang.
On Mon, Sep 26, 2016 at 7:00 PM, Ard Biesheuvel
wrote:
> On 26 September 2016 at 05:52, Michael Zimmermann
:47 PM, Ard Biesheuvel
wrote:
> On 26 September 2016 at 05:44, Michael Zimmermann
> wrote:
> > I'm thankful for the hint about _WC because it drastically improves the
> > speed on my other devices.
>
> Glad I could be of help.
>
> > Unfortunately, it doesn'
that even if I disable accesses to the framebuffer by
disabling all code in the Blt function, it hangs during boot.
I really can't explain this behavior.
On Mon, Sep 26, 2016 at 12:23 PM, Ard Biesheuvel
wrote:
> On 26 September 2016 at 00:44, Michael Zimmermann
> wrote:
> >
oh and in case it makes a difference: it's a 64bit ARM device running 32bit
code.
On Mon, Sep 26, 2016 at 9:13 AM, Michael Zimmermann <
sigmaepsilo...@gmail.com> wrote:
> Ard,
>
> I have to mark the framebuffer as uncached, because if writes to it are
> cached, they do
ld work with a
write-cache framebuffer - I actually copied the code from the ArmVirt LCD
drivers which do the same.
Thanks
Michael
On Mon, Sep 26, 2016 at 8:35 AM, Ard Biesheuvel
wrote:
> On 25 September 2016 at 20:01, Michael Zimmermann
> wrote:
> > Hi,
> >
> > which side
Hi,
which side effects can SetMemoryAttributes have?
I have a device where setting the framebuffer(which is part of DRAM)
to EFI_MEMORY_UC makes UEFI hang later on(when already outside the lcd
driver).
If I do the same on a memory range allocated with AllocateAnyPages instead
of AllocateAddress U
Hi,
if I add a timer with an interval of 1ms, how much will it affect the
system performance?
The callback only adds +1 to a global variable so I can keep track of the
total uptime without the need of a RTC.
Thanks
Michael
___
edk2-devel mailing list
ed
On Fri, Sep 9, 2016 at 3:08 PM, Ard Biesheuvel
wrote:
> On 7 September 2016 at 12:32, Ard Biesheuvel
> wrote:
> > On 7 September 2016 at 12:25, Michael Zimmermann
> > wrote:
> >>> However, looking at this
> >>> code, this is still not sufficient to find
this bug was introduced by:
d2fa09a ArmPlatformPkg/PrePi: switch to ASM_FUNC() asm macro
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: M1cha
---
ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ArmPlatformPkg
3 PM, Ard Biesheuvel
wrote:
> On 7 September 2016 at 10:48, Michael Zimmermann
> wrote:
> > nice, can we do this for ARM too? I usually need to add DEBUG((...))'s
> all
> > over the place for hours until I found the reason for a fault.
> >
>
> This is going to
nice, can we do this for ARM too? I usually need to add DEBUG((...))'s all
over the place for hours until I found the reason for a fault.
Thanks
Michael
On Wed, Sep 7, 2016 at 10:21 AM, Ard Biesheuvel
wrote:
> When dumping the CPU state after an unhandled fault, walk the stack
> frames and deco
euvel
wrote:
> On 4 September 2016 at 17:10, Michael Zimmermann
> wrote:
> >> Could we instead make the files under Conf/ symlinks to the templates?
> > Sounds like a good idea in general but what about windows? afaik only
> NTFS
> > has support for them.
> >
&g
> Could we instead make the files under Conf/ symlinks to the templates?
Sounds like a good idea in general but what about windows? afaik only NTFS
has support for them.
On Sun, Sep 4, 2016 at 5:55 PM, Ard Biesheuvel
wrote:
> On 4 September 2016 at 16:41, Leif Lindholm
> wrote:
> > Make edksetu
1 - 100 of 257 matches
Mail list logo
