Re: [edk2] [edk2-announce] March Community Meeting

[Rafael Machado]

Awesome, thanks!

Em sáb, 2 de mar de 2019 19:02, stephano 
escreveu:

> Sure, no problem. I added "BRT" timezone to the North America / Europe
> meeting. The Asia/Pacific meeting is at midnight in São Paulo, so I
> didn't bother to add it there. :)
>
> Cheers,
> Stephano
>
> On 3/1/2019 9:32 AM, Rafael Machado wrote:
> > Hi Stephano
> >
> > Could you please add at the https://www.tianocore.org/monthly-meeting
> page
> > the
> > South America TZ (São Paulo if possible ) ,   in case these calendar
> items
> > are still being used?
> >
> > Thanks and Regards
> > Rafael
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-announce] March Community Meeting

[Rafael Machado]

Hi Stephano

Could you please add at the https://www.tianocore.org/monthly-meeting page
the
South America TZ (São Paulo if possible ) ,   in case these calendar items
are still being used?

Thanks and Regards
Rafael

Em qui, 28 de fev de 2019 às 17:08, stephano <
stephano.cet...@linux.intel.com> escreveu:

>
> On 2/28/2019 11:48 AM, stephano wrote:
> > We will be holding our February Community Meeting next Thursday.
>
> %s/February/March  :)
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] BlockIo2 Protocol test tool

[Rafael Machado]

Hi Sajeesh

I don't now of any tool with this purpose.

Rafael

Em sáb, 26 de jan de 2019 13:57, Sajeesh Kk  Hello Rafeal,
>
> I believe The UEFI Sct test suite cannot be used for performance testing.
> Are there any tools which can be used from UEFI shell to measure disk IO
> perfomance using BlockIO2 Protocol ?
> Please let me know.
>
> Thanks,
> Sajeesh.
>
> On Sat, Jan 26, 2019 at 9:39 PM Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
>
>> Hi Sajeesh
>>
>> Probably you can use UEFI Sct for this test.
>> http://uefi.org/testtools
>>
>> Thanks and Regards
>> Rafael Machado
>>
>> Em sáb, 26 de jan de 2019 00:24, Sajeesh Kk >
>>> Hello all,
>>>
>>> I have a prototype BlockIO2 protocol implementation. Are there any
>>> independent tools available to test this out ?. Please let me know.
>>>
>>> Thanks,
>>> Sajeesh.
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] BlockIo2 Protocol test tool

[Rafael Machado]

Hi Sajeesh

Probably you can use UEFI Sct for this test.
http://uefi.org/testtools

Thanks and Regards
Rafael Machado

Em sáb, 26 de jan de 2019 00:24, Sajeesh Kk  Hello all,
>
> I have a prototype BlockIO2 protocol implementation. Are there any
> independent tools available to test this out ?. Please let me know.
>
> Thanks,
> Sajeesh.
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] UEFI Shell + startup.nsh

[Rafael Machado]

Thanks a lot for the help Laszlo!
Will take a look. (Also agree about having a signed UEFI Shell not being a
good idea.)

Best Regards
Rafael

Em qui, 24 de jan de 2019 às 10:47, Laszlo Ersek 
escreveu:

> On 01/24/19 13:22, Rafael Machado wrote:
> > Hi everyone.
> >
> > I have a question.
> > Considering I have a PXE server that my client downloads a shell.efi app.
> > Considering also that  I need to execute a .nsh script, but I their is no
> > media at the system.  (no usb or storage device attached)
> >
> > Is there any way to embed a startup.nsh at the shell.efi application?
> > As far as I know with PXE just one file is downloaded and executed. (I am
> > also checking how to use the EfiRamDisk protocol to create a temporary
> > place for the .nsh generated files.)
> >
> > PS.: I don't know to much about HttpBoot. Does HttpBoot has this
> limitation
> > of downloading a single file at startup?
>
> With HttpBoot, you can solve this. The Wiki article (and the relevant
> section) are at:
>
>
> https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot#ram-disk-boot-from-http
>
> Here's how:
>
> (1) First, create a FAT image such that the UEFI shell is in the default
> boot loader location, according to the architecture. (e.g.
> EFI/BOOT/BOOTAA64.EFI). Second, place "startup.nsh" in the FAT image
> such that the shell find it, according to the UEFI shell spec.
>
> For this, you can use "mkdosfs" (for formatting the image) and mmd and
> mcopy (from the mtools package) for copying stuff into the image.
> Alternatively, you can use "guestfish",  or even just loop-mount the FAT
> image on Linux. (If you create the image in the first place, then it's
> trustworthy; no need to worry about filesystem driver attacks.)
>
> (2) Once you have the FAT image, let's call it "fat.img", use
> "genisoimage" to generate an ISO image that has "fat.img" as its
> ElTorito boot image.
>
>   genisoimage -input-charset ASCII -efi-boot fat.img -no-emul-boot \
> -o stuff.iso -- fat.img
>
> (3) Serve "stuff.iso" over HTTP.
>
>
> I really hope you are doing this on a trusted, local network!
>
> Secure Boot wouldn't be of much help here; the UEFI shell binary is not
> signed. (And, signing it would be dumb, given that the shell does not
> check signatures on shell scripts, so the scripts can cause the shell to
> do basically anything at all.) HTTPS would likely count as an improvement.
>
> HTH
> Laszlo
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] UEFI Shell + startup.nsh

[Rafael Machado]

Hi everyone.

I have a question.
Considering I have a PXE server that my client downloads a shell.efi app.
Considering also that  I need to execute a .nsh script, but I their is no
media at the system.  (no usb or storage device attached)

Is there any way to embed a startup.nsh at the shell.efi application?
As far as I know with PXE just one file is downloaded and executed. (I am
also checking how to use the EfiRamDisk protocol to create a temporary
place for the .nsh generated files.)

PS.: I don't know to much about HttpBoot. Does HttpBoot has this limitation
of downloading a single file at startup?

Any help will be appreciated.
Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Question about possibility of program (Accessibility at pre-OS)

[Rafael Machado]

Hi everyone

Long time ago we received this e-mail at our edk2 mail list (later moved
from sourceforge).
The question was about adding accessibility at pre-OS environment.

Since I was looking for some new challenge I accepted this as one, and
started my mastering degree studies with focus on creating the foundations
of accessibility at pre-OS, by creating a simple HdaLib.

As soon as I conclude my Msc, on wednesday, I'll translate my thesis to
English and ad it to my github account (currently it's in Portuguese if
someone would like to have access before the translation).

The result of this work can be found here:
https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
And here: https://www.youtube.com/channel/UCStjmPCMfi4Vqw-v3j8s8Fg

The initial steps for accessibility at pre-OS are there for the community.
There is a lot of work to be done yet, but doing it together we can make it
work.

Hope you like it.
Any question please let me know.

Thanks and Regards
Rafael R. Machado

Em sex, 11 de abr de 2014 às 23:09, Andrew Fish  escreveu:

> Matthew,
> Is the screen reader pure software? If so that would difficult in UEFI as
> there are no multimedia abstractions for sound devices. There are also size
> constraints with the size of the ROM. If it is support for some kind of
> hardware device that might be easier to implement. There are already serial
> friendly text in and text out abstractions in UEFI, and it is easy to
> support multiple console devices at the same time.
>
> This is the open source site, and it has nothing to do with the UEFI
> standard that is owned by Unified Extensible Firmware Interface Forum. The
> UEFI Forum sponsors industry interoperability events so if there was a
> driver and device to test these events would be the place to do it. The
> UEFI Forum would also be the place to discuss accessibility APIs, or
> changes to the UEFI specification to enhance accessibility. The UEFI forum
> website is http://www.uefi.org.
>
> Thanks,
>
> Andrew Fish
>
>
> On Apr 11, 2014, at 5:55 PM, Matthew Bradley  wrote:
>
> Hello,
> I am a blind computer user. I was told I could try and contact you all to
> see if something I was looking for was possible. I need to see if there is
> any way to get a screen reader to work inside the UEFI menus. I know it
> would probably mean writing a screen reader for the UEFI environment. I
> just want to see if this is even possible. I was a power user prior to
> losing my vision. I have found that I am able to get most things done now,
> even with the loss of my site. I have not, however, found any accessible
> UEFI firmware. I would like to see if there is any way for us to make this
> part of the computer accessible also. I know that screen readers are
> complex, but if I could get it to read it, even one letter at a time, it
> would allow me to make changes if needed. Any response you could give would
> be appreciated, even if it is just to say it is not possible.
>
> --
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
>
> http://p.sf.net/sfu/13600_Cloudbees___
> edk2-devel mailing list
> edk2-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
> --
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> ___
> edk2-devel mailing list
> edk2-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] UEFI Driver/Application

[Rafael Machado]

Hi Ivan

You need to add the declaration of ShellLib at the Nt32Pkg dsc file.
Other .dsc files maybe usefull to check how to do that. Maybe you will need
to add other packages after adding the ShellLib. So other errors may arise
until you add all the required packages.

Rafael Machado

Em seg, 17 de dez de 2018 04:19, Ivan Novgorodtsev via edk2-devel <
edk2-devel@lists.01.org> escreveu:

> Hi,
>
>
> I want to develop a small security check
> for UEFI partition. I want it to be run each time when system starts. My
> idea was to
> create UEFI driver or application (I'm not quite sure what will fit
> better), because
> if I'm not wrong, they run at UEFI Services
> level, according to the documentation:https://imgur.com/a/yep2IwB   It
> will execute,
> and the pass control to Boot Manager which launches OS, right? I'm open to
> suggestions, if there's more suitable solution. The scripts I want to run
> in Shell
> via
> application:
>
> vol > base.txt
> vol > output.txt
> comp base.txt output.txt
>
> Right now I have also problem with compilation of project. I want to use
> similar
> piece of code like this:
>
> #include 
>
> ...
>
> EFI_STATUS
> EFIAPI UefiMain(IN EFI_HANDLE
> ImageHandle,IN EFI_SYSTEM_TABLE *SystemTable)
> {
> EFI_STATUS Status;
> ShellExecute(,L"echo Hello World!",FALSE,NULL,);
> returnStatus;
> }
>
> ...
> My .INF file:
> ## @file
> #  TODO: Brief Description of UEFI Driver BootCheck
> #
> #  TODO: Detailed Description of UEFI Driver BootCheck
> #
> #  TODO: Copyright for UEFI Driver BootCheck
> #
> #  TODO: License for UEFI Driver BootCheck
> #
> ##
>
> [Defines]
>  INF_VERSION   = 0x00010005
>  BASE_NAME = BootCheck
>  FILE_GUID = 7a81cdc0-fde7-11e8-b163-3c970edcfd41
>  MODULE_TYPE   = UEFI_DRIVER
>  VERSION_STRING= 1.0
>  ENTRY_POINT   = BootCheckDriverEntryPoint
>
> [Packages]
>  MdePkg/MdePkg.dec
>  ShellPkg/ShellPkg.dec
>
> [Sources]
>  BootCheck.h
>  BootCheck.c
>  ComponentName.c
>  ComponentName.h
>
> [LibraryClasses]
>  UefiDriverEntryPoint
>  UefiBootServicesTableLib
>  MemoryAllocationLib
>  BaseMemoryLib
>  BaseLib
>  UefiLib
>  DevicePathLib
>  DebugLib
>  ShellLib
>
> [Protocols]
>  gEfiDriverBindingProtocolGuid
>  gEfiPciIoProtocolGuid
>  gEfiComponentName2ProtocolGuid
>  gEfiComponentNameProtocolGuid
>  gEfiShellProtocolGuid
>
> [Guids]
>
> I get the following output erros:
>
> Active Platform  = c:\myworkspace\Nt32Pkg\Nt32Pkg.dsc
> 1>Flash Image Definition   = c:\myworkspace\Nt32Pkg\Nt32Pkg.fdf
> 1>
> 1>
> 1>
> 1>build.py...
> 1>c:\myworkspace\Nt32Pkg\Nt32Pkg.dsc(...) : error 4000: Instance of
> library class [ShellLib] is not found
> 1>in [c:\myworkspace\source\BootCheck.inf] [IA32]
> 1>consumed by module [c:\myworkspace\source\BootCheck.inf]
>
> I really appreciate your time and your help with this.
> Kind regards, Ivan
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Where to find the fix for security issue id 686

[Rafael Machado]

Thanks a lot Liming!

Em seg, 15 de out de 2018 às 23:10, Gao, Liming 
escreveu:

> Rafael:
>   https://bugzilla.tianocore.org/show_bug.cgi?id=686 public now. You can
> view it. I also send the patches to fix it. Please check.
>
> Thanks
> Liming
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >Rafael Machado
> >Sent: Tuesday, October 16, 2018 8:41 AM
> >To: Zimmer, Vincent 
> >Cc: edk2-devel@lists.01.org
> >Subject: Re: [edk2] Where to find the fix for security issue id 686
> >
> >I understood this issue's fix was already released at some branch.
> >With your message things make sense again.
> >
> >In this case I can wait for this fix to be publicly available.
> >Thanks for the clarification!
> >
> >Best Regards
> >Rafael
> >
> >Em seg, 15 de out de 2018 às 16:42, Zimmer, Vincent <
> >vincent.zim...@intel.com> escreveu:
> >
> >> Ah ok
> >>
> >>
> >>
> >> From
> >>
> https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-
> >Issues
> >> you will see that issues are only visible to the report and infosec
> group
> >> of Bugzilla, namely “Issues in the *Tianocore Security Issue* product
> are
> >> only visible to the *Reporter* of the issue and the members of the
> >> *infosec* group. ”
> >>
> >>
> >>
> >> Since you were not the reporter of 686 and are not part of infosec, you
> >> cannot see it.
> >>
> >>
> >>
> >> If you or anyone in the community would like to help work these issues
> >> while in triage and embargo, let me know and we can add you to the
> infosec
> >> group.
> >>
> >>
> >>
> >> Vincent
> >>
> >>
> >>
> >> *From:* Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com]
> >> *Sent:* Monday, October 15, 2018 12:17 PM
> >> *To:* Zimmer, Vincent 
> >> *Cc:* edk2-devel@lists.01.org
> >> *Subject:* Re: [edk2] Where to find the fix for security issue id 686
> >>
> >>
> >>
> >> Hi Vincent
> >>
> >>
> >>
> >> Thanks for the answer.
> >>
> >> The problem is that when I try to access this link I have this message:
> "You
> >> are not authorized to access bug #686."
> >>
> >>
> >>
> >> Any idea?
> >>
> >>
> >>
> >> Em seg, 15 de out de 2018 às 14:28, Zimmer, Vincent <
> >> vincent.zim...@intel.com> escreveu:
> >>
> >> You can find reference to patches via the advisory entry
> >>
> >> "31. EDK II TIANOCOMPRESS BOUNDS CHECKING ISSUES" advisory entry
> >> https://edk2-docs.gitbooks.io/security-advisory/content/edk-ii-
> >tianocompress-bounds-checking-issues.html
> >> has an embedded link to
> >> https://bugzilla.tianocore.org/attachment.cgi?id=150
> >>
> >> Vincent
> >>
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Rafael Machado
> >> Sent: Monday, October 15, 2018 5:39 AM
> >> To: edk2-devel@lists.01.org
> >> Subject: [edk2] Where to find the fix for security issue id 686
> >>
> >> Hi everyone
> >>
> >> I was tying to find the patch to fix the reported security issue id 686
> (
> >> https://bugzilla.tianocore.org/show_bug.cgi?id=686),
> >> but was not able to access it.
> >>
> >> Could someone please tell if this patch, or series of patches, was
> already
> >> merged to some branch that is public available?
> >>
> >> Thanks and Regards
> >> Rafael R. Machado
> >> ___
> >> edk2-devel mailing list
> >> edk2-devel@lists.01.org
> >> https://lists.01.org/mailman/listinfo/edk2-devel
> >>
> >>
> >___
> >edk2-devel mailing list
> >edk2-devel@lists.01.org
> >https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Where to find the fix for security issue id 686

[Rafael Machado]

I understood this issue's fix was already released at some branch.
With your message things make sense again.

In this case I can wait for this fix to be publicly available.
Thanks for the clarification!

Best Regards
Rafael

Em seg, 15 de out de 2018 às 16:42, Zimmer, Vincent <
vincent.zim...@intel.com> escreveu:

> Ah ok
>
>
>
> From
> https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues
> you will see that issues are only visible to the report and infosec group
> of Bugzilla, namely “Issues in the *Tianocore Security Issue* product are
> only visible to the *Reporter* of the issue and the members of the
> *infosec* group. ”
>
>
>
> Since you were not the reporter of 686 and are not part of infosec, you
> cannot see it.
>
>
>
> If you or anyone in the community would like to help work these issues
> while in triage and embargo, let me know and we can add you to the infosec
> group.
>
>
>
> Vincent
>
>
>
> *From:* Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com]
> *Sent:* Monday, October 15, 2018 12:17 PM
> *To:* Zimmer, Vincent 
> *Cc:* edk2-devel@lists.01.org
> *Subject:* Re: [edk2] Where to find the fix for security issue id 686
>
>
>
> Hi Vincent
>
>
>
> Thanks for the answer.
>
> The problem is that when I try to access this link I have this message: "You
> are not authorized to access bug #686."
>
>
>
> Any idea?
>
>
>
> Em seg, 15 de out de 2018 às 14:28, Zimmer, Vincent <
> vincent.zim...@intel.com> escreveu:
>
> You can find reference to patches via the advisory entry
>
> "31. EDK II TIANOCOMPRESS BOUNDS CHECKING ISSUES" advisory entry
> https://edk2-docs.gitbooks.io/security-advisory/content/edk-ii-tianocompress-bounds-checking-issues.html
> has an embedded link to
> https://bugzilla.tianocore.org/attachment.cgi?id=150
>
> Vincent
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Rafael Machado
> Sent: Monday, October 15, 2018 5:39 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Where to find the fix for security issue id 686
>
> Hi everyone
>
> I was tying to find the patch to fix the reported security issue id 686 (
> https://bugzilla.tianocore.org/show_bug.cgi?id=686),
> but was not able to access it.
>
> Could someone please tell if this patch, or series of patches, was already
> merged to some branch that is public available?
>
> Thanks and Regards
> Rafael R. Machado
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Where to find the fix for security issue id 686

[Rafael Machado]

Hi Vincent

Thanks for the answer.
The problem is that when I try to access this link I have this message: "You
are not authorized to access bug #686."

Any idea?

Em seg, 15 de out de 2018 às 14:28, Zimmer, Vincent <
vincent.zim...@intel.com> escreveu:

> You can find reference to patches via the advisory entry
>
> "31. EDK II TIANOCOMPRESS BOUNDS CHECKING ISSUES" advisory entry
> https://edk2-docs.gitbooks.io/security-advisory/content/edk-ii-tianocompress-bounds-checking-issues.html
> has an embedded link to
> https://bugzilla.tianocore.org/attachment.cgi?id=150
>
> Vincent
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Rafael Machado
> Sent: Monday, October 15, 2018 5:39 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Where to find the fix for security issue id 686
>
> Hi everyone
>
> I was tying to find the patch to fix the reported security issue id 686 (
> https://bugzilla.tianocore.org/show_bug.cgi?id=686),
> but was not able to access it.
>
> Could someone please tell if this patch, or series of patches, was already
> merged to some branch that is public available?
>
> Thanks and Regards
> Rafael R. Machado
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Where to find the fix for security issue id 686

[Rafael Machado]

Hi everyone

I was tying to find the patch to fix the reported security issue id 686 (
https://bugzilla.tianocore.org/show_bug.cgi?id=686),
but was not able to access it.

Could someone please tell if this patch, or series of patches, was already
merged to some branch that is public available?

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Question about memory map entries

[Rafael Machado]

Hi Andrew.

Thanks for the clarification!

Rafael

Em qua, 8 de ago de 2018 às 16:14, Andrew Fish  escreveu:

>
> On Aug 8, 2018, at 10:31 AM, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
>
> Hi everyone
>
> One question that was not answered and that could help us, is about
> skipping the MemoryTypeInfo variable usage.
> Is there any way to do this skip at a UEFI App ?
> Simple erasing the MemoryTypeInfo  var seems a little to violent from our
> perspective. What do you think?
>
> Seems the system we're having this problem has some inconsistency when
> filling the MemoryTypeInfo  var before exiting the previous boot, and
> seems to consider the BootServices memory type also to be stored at the
> var. Does anyone remember of this kind of issue on some system in the past?
>
>
> No we do that all the time to remove fragmentation from the memory map and
> it does not
>
> Thanks,
>
> Andrew Fish
>
> Thanks and Regards
> Rafael
>
> Em qua, 8 de ago de 2018 às 08:55, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> escreveu:
>
>> Hi Jiewen
>>
>> Thanks for highlighting this.
>> Just checked and we just add the Reserved/Acpi/Runtime types.
>>
>> Seems the guess that this would be related to the MemoryTypeInfo var is
>> not the correct way to follow.
>>
>> We'll keep working on it, maybe asking more questions to the community in
>> future.
>> Thank you all for the help and guidance!
>> In case someone has any comment or idea, please feel free to share.
>>
>> Rafael
>>
>>
>>
>> Em ter, 7 de ago de 2018 às 19:42, Yao, Jiewen 
>> escreveu:
>>
>>> Hi
>>>
>>> It is unclear to me that which type you have put to MemoryTypeInfo table.
>>>
>>>
>>>
>>> By design, we only need put Reserved/Acpi/Runtime, which should be quite
>>> small.
>>>
>>>
>>>
>>> Do you put any other type into MemoryTypeInfo table?
>>>
>>>
>>>
>>> Thank you
>>>
>>> Yao Jiewen
>>>
>>>
>>>
>>> *From:* Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com]
>>> *Sent:* Wednesday, August 8, 2018 3:12 AM
>>> *To:* Laszlo Ersek 
>>> *Cc:* Andrew Fish ; Ni, Ruiyu ;
>>> edk2-devel@lists.01.org; Yao, Jiewen 
>>>
>>>
>>> *Subject:* Re: [edk2] Question about memory map entries
>>>
>>>
>>>
>>> Hi everyone
>>>
>>>
>>>
>>> Based on the information shared by the members, the understanding is
>>> that the current state of the system may impact fuutre boots.
>>>
>>> The problem is that in my case, due to specific requirements, before
>>> booting we need to stress the system's memory, allocating a big amount of
>>> memory and doing some memory validation algorithms.
>>>
>>> So the high number of allocations and frees is by choice and not by
>>> mistakes.
>>>
>>>
>>>
>>> Considering this. Is there any way to bypass the MemoryTypeInformation
>>> var store actions?
>>>
>>>
>>>
>>> Thanks and Regards
>>>
>>> Rafael
>>>
>>>
>>>
>>> Em qui, 2 de ago de 2018 às 17:39, Laszlo Ersek 
>>> escreveu:
>>>
>>> On 08/02/18 21:18, Rafael Machado wrote:
>>> > Just found something interesting.
>>> > Based on the logs from the serial port.
>>> >
>>> > This system works fine:
>>> >
>>> > "PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B
>>> > Temp Stack : BaseAddress=0x40 Length=0x8
>>> > Temp Heap  : BaseAddress=0x48 Length=0x8
>>> > Total temporary memory:1048576 bytes.
>>> >   temporary memory stack ever used: 524288 bytes.
>>> >   temporary memory heap used:   63304 bytes.
>>> > Old Stack size 524288, New stack size 524288
>>> > Stack Hob: BaseAddress=0x93D5 Length=0x8
>>> > Heap Offset = 0x9395 Stack Offset = 0x9395
>>> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
>>> > ...
>>> > "CoreInitializeMemoryServices:
>>> >   BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
>>> > 0x5AC"
>>> >
>>> > This one is bricked:
>>> >
>>> > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9

Re: [edk2] Question about memory map entries

[Rafael Machado]

Hi everyone

One question that was not answered and that could help us, is about
skipping the MemoryTypeInfo variable usage.
Is there any way to do this skip at a UEFI App ?
Simple erasing the MemoryTypeInfo  var seems a little to violent from our
perspective. What do you think?

Seems the system we're having this problem has some inconsistency when
filling the MemoryTypeInfo  var before exiting the previous boot, and seems
to consider the BootServices memory type also to be stored at the var. Does
anyone remember of this kind of issue on some system in the past?

Thanks and Regards
Rafael

Em qua, 8 de ago de 2018 às 08:55, Rafael Machado <
rafaelrodrigues.mach...@gmail.com> escreveu:

> Hi Jiewen
>
> Thanks for highlighting this.
> Just checked and we just add the Reserved/Acpi/Runtime types.
>
> Seems the guess that this would be related to the MemoryTypeInfo var is
> not the correct way to follow.
>
> We'll keep working on it, maybe asking more questions to the community in
> future.
> Thank you all for the help and guidance!
> In case someone has any comment or idea, please feel free to share.
>
> Rafael
>
>
>
> Em ter, 7 de ago de 2018 às 19:42, Yao, Jiewen 
> escreveu:
>
>> Hi
>>
>> It is unclear to me that which type you have put to MemoryTypeInfo table.
>>
>>
>>
>> By design, we only need put Reserved/Acpi/Runtime, which should be quite
>> small.
>>
>>
>>
>> Do you put any other type into MemoryTypeInfo table?
>>
>>
>>
>> Thank you
>>
>> Yao Jiewen
>>
>>
>>
>> *From:* Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com]
>> *Sent:* Wednesday, August 8, 2018 3:12 AM
>> *To:* Laszlo Ersek 
>> *Cc:* Andrew Fish ; Ni, Ruiyu ;
>> edk2-devel@lists.01.org; Yao, Jiewen 
>>
>>
>> *Subject:* Re: [edk2] Question about memory map entries
>>
>>
>>
>> Hi everyone
>>
>>
>>
>> Based on the information shared by the members, the understanding is that
>> the current state of the system may impact fuutre boots.
>>
>> The problem is that in my case, due to specific requirements, before
>> booting we need to stress the system's memory, allocating a big amount of
>> memory and doing some memory validation algorithms.
>>
>> So the high number of allocations and frees is by choice and not by
>> mistakes.
>>
>>
>>
>> Considering this. Is there any way to bypass the MemoryTypeInformation
>> var store actions?
>>
>>
>>
>> Thanks and Regards
>>
>> Rafael
>>
>>
>>
>> Em qui, 2 de ago de 2018 às 17:39, Laszlo Ersek 
>> escreveu:
>>
>> On 08/02/18 21:18, Rafael Machado wrote:
>> > Just found something interesting.
>> > Based on the logs from the serial port.
>> >
>> > This system works fine:
>> >
>> > "PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B
>> > Temp Stack : BaseAddress=0x40 Length=0x8
>> > Temp Heap  : BaseAddress=0x48 Length=0x8
>> > Total temporary memory:1048576 bytes.
>> >   temporary memory stack ever used: 524288 bytes.
>> >   temporary memory heap used:   63304 bytes.
>> > Old Stack size 524288, New stack size 524288
>> > Stack Hob: BaseAddress=0x93D5 Length=0x8
>> > Heap Offset = 0x9395 Stack Offset = 0x9395
>> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
>> > ...
>> > "CoreInitializeMemoryServices:
>> >   BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
>> > 0x5AC"
>> >
>> > This one is bricked:
>> >
>> > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
>> > Temp Stack : BaseAddress=0x40 Length=0x8
>> > Temp Heap  : BaseAddress=0x48 Length=0x8
>> > Total temporary memory:1048576 bytes.
>> >   temporary memory stack ever used: 524288 bytes.
>> >   temporary memory heap used:   63304 bytes.
>> > Old Stack size 524288, New stack size 524288
>> > Stack Hob: BaseAddress=0x9C9000 Length=0x8
>> > Heap Offset = 0x5C9000 Stack Offset = 0x5C9000
>> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
>> > ...
>> > "CoreInitializeMemoryServices:
>> >   BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000
>> > "
>> > ...
>> > "ASSERT_EFI_ERROR (Status = Out of Resources)
>> > ASSERT [DxeCore] ...\MdeMod

Re: [edk2] Question about memory map entries

[Rafael Machado]

Hi Jiewen

Thanks for highlighting this.
Just checked and we just add the Reserved/Acpi/Runtime types.

Seems the guess that this would be related to the MemoryTypeInfo var is not
the correct way to follow.

We'll keep working on it, maybe asking more questions to the community in
future.
Thank you all for the help and guidance!
In case someone has any comment or idea, please feel free to share.

Rafael



Em ter, 7 de ago de 2018 às 19:42, Yao, Jiewen 
escreveu:

> Hi
>
> It is unclear to me that which type you have put to MemoryTypeInfo table.
>
>
>
> By design, we only need put Reserved/Acpi/Runtime, which should be quite
> small.
>
>
>
> Do you put any other type into MemoryTypeInfo table?
>
>
>
> Thank you
>
> Yao Jiewen
>
>
>
> *From:* Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com]
> *Sent:* Wednesday, August 8, 2018 3:12 AM
> *To:* Laszlo Ersek 
> *Cc:* Andrew Fish ; Ni, Ruiyu ;
> edk2-devel@lists.01.org; Yao, Jiewen 
>
>
> *Subject:* Re: [edk2] Question about memory map entries
>
>
>
> Hi everyone
>
>
>
> Based on the information shared by the members, the understanding is that
> the current state of the system may impact fuutre boots.
>
> The problem is that in my case, due to specific requirements, before
> booting we need to stress the system's memory, allocating a big amount of
> memory and doing some memory validation algorithms.
>
> So the high number of allocations and frees is by choice and not by
> mistakes.
>
>
>
> Considering this. Is there any way to bypass the MemoryTypeInformation
> var store actions?
>
>
>
> Thanks and Regards
>
> Rafael
>
>
>
> Em qui, 2 de ago de 2018 às 17:39, Laszlo Ersek 
> escreveu:
>
> On 08/02/18 21:18, Rafael Machado wrote:
> > Just found something interesting.
> > Based on the logs from the serial port.
> >
> > This system works fine:
> >
> > "PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B
> > Temp Stack : BaseAddress=0x40 Length=0x8
> > Temp Heap  : BaseAddress=0x48 Length=0x8
> > Total temporary memory:1048576 bytes.
> >   temporary memory stack ever used: 524288 bytes.
> >   temporary memory heap used:   63304 bytes.
> > Old Stack size 524288, New stack size 524288
> > Stack Hob: BaseAddress=0x93D5 Length=0x8
> > Heap Offset = 0x9395 Stack Offset = 0x9395
> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
> > ...
> > "CoreInitializeMemoryServices:
> >   BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
> > 0x5AC"
> >
> > This one is bricked:
> >
> > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
> > Temp Stack : BaseAddress=0x40 Length=0x8
> > Temp Heap  : BaseAddress=0x48 Length=0x8
> > Total temporary memory:1048576 bytes.
> >   temporary memory stack ever used: 524288 bytes.
> >   temporary memory heap used:   63304 bytes.
> > Old Stack size 524288, New stack size 524288
> > Stack Hob: BaseAddress=0x9C9000 Length=0x8
> > Heap Offset = 0x5C9000 Stack Offset = 0x5C9000
> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
> > ...
> > "CoreInitializeMemoryServices:
> >   BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000
> > "
> > ...
> > "ASSERT_EFI_ERROR (Status = Out of Resources)
> > ASSERT [DxeCore] ...\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c(299):
> > !EFI_ERROR (Status)
> > AllocatePoolPages: failed to allocate 1 pages
> > AllocatePool: failed to allocate 120 bytes"
>
> The location and the size of the permanent PEI RAM are extremely
> different between the two cases.
>
> - Functional system:
>
>   PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B
>
>   Base address is ~2365 MB, size is ~162 MB
>
> - Unbootable system:
>
>   PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
>
>   Base address is ~9 MB, size is ~2518 MB
>
> The numbers in the second (unbootable) case look very unusual to me. The
> permanent PEI RAM is usually tens or (maybe) hundreds of megabytes in
> size, and tends to start much higher (usually as high as possible under
> 4GB, on x86 anyway).
>
>
> Consult the following sections in the PI spec (v1.6), volume 3:
>
> - 4.3 Example HOB Producer Phase Memory Map and Usage
> - 5.3 PHIT HOB
>
> The CoreInitializeMemoryServices() function searches the HOB list for a
> tested system memory "Resource Descriptor HOB that contains PHI

Re: [edk2] Question about memory map entries

[Rafael Machado]

Hi everyone

Based on the information shared by the members, the understanding is that
the current state of the system may impact fuutre boots.
The problem is that in my case, due to specific requirements, before
booting we need to stress the system's memory, allocating a big amount of
memory and doing some memory validation algorithms.
So the high number of allocations and frees is by choice and not by
mistakes.

Considering this. Is there any way to bypass the MemoryTypeInformation var
store actions?

Thanks and Regards
Rafael

Em qui, 2 de ago de 2018 às 17:39, Laszlo Ersek 
escreveu:

> On 08/02/18 21:18, Rafael Machado wrote:
> > Just found something interesting.
> > Based on the logs from the serial port.
> >
> > This system works fine:
> >
> > "PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B
> > Temp Stack : BaseAddress=0x40 Length=0x8
> > Temp Heap  : BaseAddress=0x48 Length=0x8
> > Total temporary memory:1048576 bytes.
> >   temporary memory stack ever used: 524288 bytes.
> >   temporary memory heap used:   63304 bytes.
> > Old Stack size 524288, New stack size 524288
> > Stack Hob: BaseAddress=0x93D5 Length=0x8
> > Heap Offset = 0x9395 Stack Offset = 0x9395
> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
> > ...
> > "CoreInitializeMemoryServices:
> >   BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
> > 0x5AC"
> >
> > This one is bricked:
> >
> > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
> > Temp Stack : BaseAddress=0x40 Length=0x8
> > Temp Heap  : BaseAddress=0x48 Length=0x8
> > Total temporary memory:1048576 bytes.
> >   temporary memory stack ever used: 524288 bytes.
> >   temporary memory heap used:   63304 bytes.
> > Old Stack size 524288, New stack size 524288
> > Stack Hob: BaseAddress=0x9C9000 Length=0x8
> > Heap Offset = 0x5C9000 Stack Offset = 0x5C9000
> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
> > ...
> > "CoreInitializeMemoryServices:
> >   BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000
> > "
> > ...
> > "ASSERT_EFI_ERROR (Status = Out of Resources)
> > ASSERT [DxeCore] ...\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c(299):
> > !EFI_ERROR (Status)
> > AllocatePoolPages: failed to allocate 1 pages
> > AllocatePool: failed to allocate 120 bytes"
>
> The location and the size of the permanent PEI RAM are extremely
> different between the two cases.
>
> - Functional system:
>
>   PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B
>
>   Base address is ~2365 MB, size is ~162 MB
>
> - Unbootable system:
>
>   PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
>
>   Base address is ~9 MB, size is ~2518 MB
>
> The numbers in the second (unbootable) case look very unusual to me. The
> permanent PEI RAM is usually tens or (maybe) hundreds of megabytes in
> size, and tends to start much higher (usually as high as possible under
> 4GB, on x86 anyway).
>
>
> Consult the following sections in the PI spec (v1.6), volume 3:
>
> - 4.3 Example HOB Producer Phase Memory Map and Usage
> - 5.3 PHIT HOB
>
> The CoreInitializeMemoryServices() function searches the HOB list for a
> tested system memory "Resource Descriptor HOB that contains PHIT range
> EfiFreeMemoryBottom..EfiFreeMemoryTop". (Quoted a comment from the code.)
>
> Basically, the function locates the system RAM HOB that contains the
> free permanent PEI RAM.
>
> If the search fails, then we trip an ASSERT(). This does not happen in
> your case, the search succeeds.
>
> If the search succeeds, then the DXE core will try to initialize itself
> in one of three locations in the RAM area defined by that HOB. In
> descending preference order: above the permanent PEI RAM, within the
> free permanent PEI RAM, and below the permanent PEI RAM.
>
> There is also a fallback (a fourth option) when even the third one from
> before proves too small -- the function will then search again for a
> memory descriptor HOB, top-down, avoiding the one HOB that it found
> earlier to contain the permanent PEI RAM (because, all three options for
> that have already failed, see above).
>
> As the result of this search, your broken system finishes with:
>
> BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000
>
> "MinimalMemorySizeNeeded" includes the previous measurements from
> MemoryTypeInformation, and the concrete value is very s

Re: [edk2] Question about memory map entries

[Rafael Machado]

Just found something interesting.
Based on the logs from the serial port.

This system works fine:

"PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B
Temp Stack : BaseAddress=0x40 Length=0x8
Temp Heap  : BaseAddress=0x48 Length=0x8
Total temporary memory:1048576 bytes.
  temporary memory stack ever used: 524288 bytes.
  temporary memory heap used:   63304 bytes.
Old Stack size 524288, New stack size 524288
Stack Hob: BaseAddress=0x93D5 Length=0x8
Heap Offset = 0x9395 Stack Offset = 0x9395
Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
...
"CoreInitializeMemoryServices:
  BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
0x5AC"

This one is bricked:

"PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
Temp Stack : BaseAddress=0x40 Length=0x8
Temp Heap  : BaseAddress=0x48 Length=0x8
Total temporary memory:1048576 bytes.
  temporary memory stack ever used: 524288 bytes.
  temporary memory heap used:   63304 bytes.
Old Stack size 524288, New stack size 524288
Stack Hob: BaseAddress=0x9C9000 Length=0x8
Heap Offset = 0x5C9000 Stack Offset = 0x5C9000
Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
...
"CoreInitializeMemoryServices:
  BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000
"
...
"ASSERT_EFI_ERROR (Status = Out of Resources)
ASSERT [DxeCore] ...\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c(299):
!EFI_ERROR (Status)
AllocatePoolPages: failed to allocate 1 pages
AllocatePool: failed to allocate 120 bytes"


It's really strange that the "Stack Hob base address" is so different, and
the "MemoryBegin" also.
This is making the memory to be detected incorrectly as far as I could
understand. So CoreInitializeMemoryServices does not have enougth memory to
work on.
Any idea about what could cause this difference?

Unfortunately I don't have the system in hands. And also cannot share the
entire log due to legal. But these are the differences between the bricked
system and the normal one.
Any idea?

Thanks and Regards
Rafael R. Machado


Em qui, 2 de ago de 2018 às 16:02, Rafael Machado <
rafaelrodrigues.mach...@gmail.com> escreveu:

> Hi Laszlo
>
> Got your point. Thanks for the comment.
>
> I'll keep working on it.
> In case someone has some other information or idea feel free to share.
>
> Thanks
> Rafael
>
> Em qui, 2 de ago de 2018 às 14:48, Laszlo Ersek 
> escreveu:
>
>> On 08/02/18 18:42, Rafael Machado wrote:
>> > Thanks Andrew and Laszlo for the clarification and guidance.
>> >
>> > About Laszlo questions
>> >
>> >> Is the reboot automatic (from the platform firmware), or application /
>> >> user initiated?
>> > Yes. We just do some clean up, finish the events and "return
>> EFI_SUCCESS;"
>>
>> That's really strange. I don't think that's valid or expected behavior.
>> If a boot option exits with success, then, as I understand it, the boot
>> manager is expected to return to the setup UI at once. (I don't have a
>> reference ready for this, but I remember someone mentioning it.) Boot
>> option processing continues only if the current boot option exits with
>> failure.
>>
>> I think the reboot you see is actually a crash. (Not saying that the
>> issue is in your application, just that the reboot should not be
>> triggered by either the application or the platform firmware.)
>>
>> Thanks,
>> Laszlo
>>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Question about memory map entries

[Rafael Machado]

Hi Laszlo

Got your point. Thanks for the comment.

I'll keep working on it.
In case someone has some other information or idea feel free to share.

Thanks
Rafael

Em qui, 2 de ago de 2018 às 14:48, Laszlo Ersek 
escreveu:

> On 08/02/18 18:42, Rafael Machado wrote:
> > Thanks Andrew and Laszlo for the clarification and guidance.
> >
> > About Laszlo questions
> >
> >> Is the reboot automatic (from the platform firmware), or application /
> >> user initiated?
> > Yes. We just do some clean up, finish the events and "return
> EFI_SUCCESS;"
>
> That's really strange. I don't think that's valid or expected behavior.
> If a boot option exits with success, then, as I understand it, the boot
> manager is expected to return to the setup UI at once. (I don't have a
> reference ready for this, but I remember someone mentioning it.) Boot
> option processing continues only if the current boot option exits with
> failure.
>
> I think the reboot you see is actually a crash. (Not saying that the
> issue is in your application, just that the reboot should not be
> triggered by either the application or the platform firmware.)
>
> Thanks,
> Laszlo
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Question about memory map entries

[Rafael Machado]

Thanks Andrew and Laszlo for the clarification and guidance.

About Laszlo questions

>Is the reboot automatic (from the platform firmware), or application /
>user initiated?
Yes. We just do some clean up, finish the events and "return EFI_SUCCESS;"

>Do you exit the application before the system is powered off?
No. At this test we just let the application finishes it's work and power
off the system.  No "return EFI_SUCCESS;"

Thanks and Regards
Rafael

Em qui, 2 de ago de 2018 às 11:44, Laszlo Ersek 
escreveu:

> On 08/02/18 14:39, Rafael Machado wrote:
> > Hi everyone
> >
> > After some other tasks I am back to this case :)
> >
> > After some debug, we detected the moment where things start to go wrong,
> > but I am not sure what may cause this.
> >
> > What we noticed is that the following assert is reached:
> >
> https://github.com/tianocore/edk2/blob/87acb6e298e718250dd8b741b6888a3a54c7cb5a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2199
> >
> > Just to remember, this assert is reached with the following steps:
> > 1 - Boot the application (renamed to BOOTX64.efi) from a usb stick
> > 2 - Execute the application tasks
> > 3 - exit the application (free everything, all events closed and  no
> memory
> > leaks detected as suggested to check by Andrew on the previous e-mail,
> then
> > return efi_success)
> > 4 - the system will reboot and reach the assert
>
> Is the reboot automatic (from the platform firmware), or application /
> user initiated?
>
> > But it does not happen with the following scenario:
> > 1 - Boot the application (renamed to BOOTX64.efi) from a usb stick
> > 2 - Execute the application tasks
> > 3 - Power off the system
>
> Do you exit the application before the system is powered off?
>
> >
> > As far as I could understand (please correct my understanding that may be
> > wrong since is the first time I look at this part of the code), at this
> > point the HOBs passed from sec phase are processed by PEI so the memory
> > could be "detected/mapped/initialized" correctly. But for some reason the
> > required HOB is no present at the list.
> >
> > Could someone with more experience at this part of the code please
> confirm
> > my understanding, and if possible give some guesses about what could
> cause
> > this scenario?
>
> PEI may act differently (produce different HOBs) dependent on boot mode.
> The PI spec defines several boot modes; it's platform-dependent what
> hardware states / transitions are mapped to what PI boot modes by the
> firmware.
>
> > My guess is that some memory cleanup that should be done by the bios
> after
> > the application exits is not being done correctly. So I believe the
> problem
> > is not at the application, but at the BIOS. A friend here mentioned about
> > the MemoryTypeInformation efi var, that may be corrupted, and considering
> > it's used to guide the boot process it may impact the boot, but I am not
> > sure if this is the case and also I didn't find to much information about
> > this var and it's usage, so any help about this would be well received
> also.
>
> MemoryTypeInformation measures peak usage (of various UEFI memory types)
> during boot, so that at next boot, the internal allocation "bins" can be
> primed with large enough sizes. The goal is to reduce fragmentation due
> to "unforeseen" allocations.
>
> If you exit the application gracefully in both scenarios (and the only
> difference is whether you reboot the system, or power it down,
> afterwards, e.g. by passing different options to the RESET command of
> the UEFI shell), then I don't see how MemoryTypeInformation could be
> relevant.
>
> Thanks
> Laszlo
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Question about memory map entries

[Rafael Machado]

Hi everyone

After some other tasks I am back to this case :)

After some debug, we detected the moment where things start to go wrong,
but I am not sure what may cause this.

What we noticed is that the following assert is reached:
https://github.com/tianocore/edk2/blob/87acb6e298e718250dd8b741b6888a3a54c7cb5a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2199

Just to remember, this assert is reached with the following steps:
1 - Boot the application (renamed to BOOTX64.efi) from a usb stick
2 - Execute the application tasks
3 - exit the application (free everything, all events closed and  no memory
leaks detected as suggested to check by Andrew on the previous e-mail, then
return efi_success)
4 - the system will reboot and reach the assert

But it does not happen with the following scenario:
1 - Boot the application (renamed to BOOTX64.efi) from a usb stick
2 - Execute the application tasks
3 - Power off the system

As far as I could understand (please correct my understanding that may be
wrong since is the first time I look at this part of the code), at this
point the HOBs passed from sec phase are processed by PEI so the memory
could be "detected/mapped/initialized" correctly. But for some reason the
required HOB is no present at the list.

Could someone with more experience at this part of the code please confirm
my understanding, and if possible give some guesses about what could cause
this scenario?

My guess is that some memory cleanup that should be done by the bios after
the application exits is not being done correctly. So I believe the problem
is not at the application, but at the BIOS. A friend here mentioned about
the MemoryTypeInformation efi var, that may be corrupted, and considering
it's used to guide the boot process it may impact the boot, but I am not
sure if this is the case and also I didn't find to much information about
this var and it's usage, so any help about this would be well received also.

Any ideas?

Thanks and Regards
Rafael R. Machado

Em sáb, 30 de jun de 2018 às 16:23, Andrew Fish  escreveu:

>
>
> > On Jun 30, 2018, at 5:02 AM, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
> >
> > Hi everyone. Thanks for the answers!
> > In this case, I just executed 3 shell command:
> >
> > memmap >> before.txt
> > app.efi
> > memmap >> after.txt
> >
> > Does anyone could clarify what could cause a new entry to be created at
> the
> > memmap output command?
>
> There is fragmentation caused the Apps high usage of memory and this can
> cause a lot more entries. I guess the DXE Core might also need to allocate
> some extra pages to track the fragmentation of the memory pool caused by
> the App.
>
> > My understanding was that the entries at the memmap command reflect the
> GCD
> > (global coherence domain), that is something that should not change too
> > much after the system is already at BDS phase.
>
> It is not really showing you GCD, it is showing the UEFI memory map. GCD
> implies the memory is being used as DRAM by the CPU , the UEFI memory map
> tracks the type of allocation and what areas of memory are free. That usage
> patter is changed by your App running.
>
> > As mentioned, the
> > application does a lot of AllocatePool() FreePool() calls. And these
> calls
> > are, as far as I could understand, creating a lot of entries of type
> "BS_Data"
> > and "Available".
> > Shouldn't the bios allocation routines try to reuse the pools already
> used
> > and freed to avoid massing and fragmenting the memory?
> >
> > Besides that, we just found a system that hangs on the subsequent boot
> > after executing the application. The strange is that the system just
> hangs
> > if you do the following steps:
> >
> > 1 - execute the application: app.efi
> > 2 - exit the shell with the command: exit
> > 3 - boot hangs not presenting the shell prompt
> >
> >
> > In case you do the following steps the hang doesn't happen:
> >
> > 1 - execute the application: app.efi
> > 2 - shut down the system by pressing the power button
> > 3 - boots normally entering at the shell prompt
> >
> > Any idea about what could cause this strange behavior, and if this may
> have
> > some relation with the increase of the memmap output entries?
>
> A common bug is for an Application to not clean up something and have the
> resource get freed. For example the App starts a timer event, forgets to
> stop it and when the App exits the memory gets freed back and if some one
> else allocates that memory they overwrite the code that executes in the
> timer event and kaboom. Same goes for publishing a protocol, etc.
>
> Given the 

Re: [edk2] Question About DxeDriver load process

[Rafael Machado]

Andrew,

Thanks for clarifying this!

Rafael

Em seg, 30 de jul de 2018 12:28, Andrew Fish  escreveu:

> Rafael,
>
> I forgot to mention that the DXE Core is loaded by the DXE IPL PEIM. This
> can sometime require the discovery of a new FV to find the DXE Core.
>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c#L254
>
> Thanks,
>
> Andrew Fish
>
> > On Jul 30, 2018, at 4:46 AM, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
> >
> > Hi Andrew
> >
> > Thanks a lot for the perfectly detailed explanation!
> > Amazing!
> >
> > Thanks and Regards
> > Rafael R. Machado
> >
> > Em sex, 27 de jul de 2018 às 19:14, Andrew Fish 
> escreveu:
> >
> >> Rafael,
> >>
> >> Since it is useful to also understand this when you are bringing up a
> >> platform
> >>
> >> SEC generally contains the hardware reset vector. SEC hands off to the
> PEI
> >> Core. Generally there is some build magic to help SEC find the PEI Core.
> >> Worst case you can walk the BFV (Boot Firmware Volume) and find it.
> >>
> >> SEC hands the PEI Core the EFI_SEC_PEI_HAND_OFF structure. This is how
> the
> >> PEI Core knows about stack, heap, and the location of the BFV to find
> PEIMs
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiPeiCis.h#L967
> >>
> >> The PEI Core has a PPI Notify Callback for
> >> gEfiPeiFirmwareVolumeInfoPpiGuid, and
> gEfiPeiFirmwareVolumeInfo2PpiGuid to
> >> discover new FVs.
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/FwVol/FwVol.c#L547
> >>
> >> PEI Code writes hobs, EFI_HOB_TYPE_FV and EFI_HOB_TYPE_FV3, to help DXE
> >> discover FVs.
> >>
> >> When the DXE Core is started it will call FwVolBlockDriverInit() and
> all
> >> the EFI_HOB_TYPE_FV, and optionally pick up the authentication status
> from
> >> EFI_HOB_TYPE_FV3, will get processed.
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/FwVolBlock/FwVolBlock.c#L625
> >>
> >> via calling ProduceFVBProtocolOnBuffer(). ProduceFVBProtocolOnBuffer()
> can
> >> also be called gBS->ProcessFirmwareVolume().
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/FwVolBlock/FwVolBlock.c#L452
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/FwVolBlock/FwVolBlock.c#L687
> >>
> >> Loading drivers from the FV is the job of the DXE Dispatcher. The DXE
> >> Dispatcher has protocol notify event on gEfiFirmwareVolume2ProtocolGuid
> >> that will get the executables in the Dispatch list, mDiscoveredList.
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c#L1193
> >>
> >> So adding a gEfiFirmwareVolume2ProtocolGuid driver, or calling
> >> gBS->ProcessFirmwareVolume() is how you would make an FV show up that
> was
> >> not listed in the HOBs.
> >>
> >> In the DXE Phase security is handle by gBS->LoadImage() and it uses
> >> gEfiSecurity2ArchProtocolGuid and gEfiSecurityArchProtocolGuid to
> validate
> >> the image. This makes sense as a signed EFI PE/COFF image has the
> signature
> >> in the PE/COFF image, so you have to start the PE/COFF loading process
> to
> >> verify that signature.  gEfiSecurity2ArchProtocolGuid lets you build
> >> security policy based on the location of the driver.
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Image/Image.c#L1041
> >>
> >> When the Dispatcher runs of things to Dispatch it returns and the DXE
> Core
> >> calls the BDS to process platform Boot Device Selection.
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c#L550
> >>
> >> After BDS starts the only way to run code from an FV would be to call
> >> gDS->Dispatcher(). Likely you would call gDS->ProcessFirmwareVolume()
> and
> >> then  gDS->Dispatcher(). To speed boot it is not uncommon to have
> multiple
> >> FVs. For example you could have an FV that contained all the setup
> >> resources and only call gDS->ProcessFirmwareVolume() on that FV if the
> user
> >> hit the Setup hot key.
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>
> &g

Re: [edk2] Question About DxeDriver load process

[Rafael Machado]

Hi Andrew

Thanks a lot for the perfectly detailed explanation!
Amazing!

Thanks and Regards
Rafael R. Machado

Em sex, 27 de jul de 2018 às 19:14, Andrew Fish  escreveu:

> Rafael,
>
> Since it is useful to also understand this when you are bringing up a
> platform
>
> SEC generally contains the hardware reset vector. SEC hands off to the PEI
> Core. Generally there is some build magic to help SEC find the PEI Core.
> Worst case you can walk the BFV (Boot Firmware Volume) and find it.
>
> SEC hands the PEI Core the EFI_SEC_PEI_HAND_OFF structure. This is how the
> PEI Core knows about stack, heap, and the location of the BFV to find PEIMs
>
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiPeiCis.h#L967
>
> The PEI Core has a PPI Notify Callback for
> gEfiPeiFirmwareVolumeInfoPpiGuid, and  gEfiPeiFirmwareVolumeInfo2PpiGuid to
> discover new FVs.
>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/FwVol/FwVol.c#L547
>
> PEI Code writes hobs, EFI_HOB_TYPE_FV and EFI_HOB_TYPE_FV3, to help DXE
> discover FVs.
>
> When the DXE Core is started it will call FwVolBlockDriverInit() and  all
> the EFI_HOB_TYPE_FV, and optionally pick up the authentication status from
> EFI_HOB_TYPE_FV3, will get processed.
>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/FwVolBlock/FwVolBlock.c#L625
>
> via calling ProduceFVBProtocolOnBuffer(). ProduceFVBProtocolOnBuffer() can
> also be called gBS->ProcessFirmwareVolume().
>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/FwVolBlock/FwVolBlock.c#L452
>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/FwVolBlock/FwVolBlock.c#L687
>
> Loading drivers from the FV is the job of the DXE Dispatcher. The DXE
> Dispatcher has protocol notify event on gEfiFirmwareVolume2ProtocolGuid
> that will get the executables in the Dispatch list, mDiscoveredList.
>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c#L1193
>
> So adding a gEfiFirmwareVolume2ProtocolGuid driver, or calling
> gBS->ProcessFirmwareVolume() is how you would make an FV show up that was
> not listed in the HOBs.
>
> In the DXE Phase security is handle by gBS->LoadImage() and it uses
> gEfiSecurity2ArchProtocolGuid and gEfiSecurityArchProtocolGuid to validate
> the image. This makes sense as a signed EFI PE/COFF image has the signature
> in the PE/COFF image, so you have to start the PE/COFF loading process to
> verify that signature.  gEfiSecurity2ArchProtocolGuid lets you build
> security policy based on the location of the driver.
>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Image/Image.c#L1041
>
> When the Dispatcher runs of things to Dispatch it returns and the DXE Core
> calls the BDS to process platform Boot Device Selection.
>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c#L550
>
> After BDS starts the only way to run code from an FV would be to call
> gDS->Dispatcher(). Likely you would call gDS->ProcessFirmwareVolume() and
> then  gDS->Dispatcher(). To speed boot it is not uncommon to have multiple
> FVs. For example you could have an FV that contained all the setup
> resources and only call gDS->ProcessFirmwareVolume() on that FV if the user
> hit the Setup hot key.
>
> Thanks,
>
> Andrew Fish
>
> PS For x86 (0xFFF0 reset vector) and any other architectures that have
> the reset vector at the end there is a special file name in the FV called
> gEfiFirmwareVolumeTopFileGuid that tells the FV creation tools to put that
> file at the very end of the FV, so the end of that file would end up at the
> reset vector location.
>
>
> > On Jul 27, 2018, at 11:12 AM, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
> >
> > Hi everyone
> >
> > I have a question.
> > Let's suppose I have a BIOS with several FV regions. Between these FV
> there
> > is one that is empty.
> >
> > My question is:
> > In case I get this BIOS and inject a dxe driver at this FV. Would it be
> > executed, or there are specific FVs that are considered as containers to
> > executable code avoiding other FVs content to be executed?
> >
> > In case the answer comes with some code examples from edk2 tree it would
> be
> > amazing :)
> >
> > Thanks and Regards
> > Rafael
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Question About DxeDriver load process

[Rafael Machado]

Hi everyone

I have a question.
Let's suppose I have a BIOS with several FV regions. Between these FV there
is one that is empty.

My question is:
In case I get this BIOS and inject a dxe driver at this FV. Would it be
executed, or there are specific FVs that are considered as containers to
executable code avoiding other FVs content to be executed?

In case the answer comes with some code examples from edk2 tree it would be
amazing :)

Thanks and Regards
Rafael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Question about memory map entries

[Rafael Machado]

Hi everyone. Thanks for the answers!
In this case, I just executed 3 shell command:

memmap >> before.txt
app.efi
memmap >> after.txt

Does anyone could clarify what could cause a new entry to be created at the
memmap output command?
My understanding was that the entries at the memmap command reflect the GCD
(global coherence domain), that is something that should not change too
much after the system is already at BDS phase. As mentioned, the
application does a lot of AllocatePool() FreePool() calls. And these calls
are, as far as I could understand, creating a lot of entries of type "BS_Data"
and "Available".
Shouldn't the bios allocation routines try to reuse the pools already used
and freed to avoid massing and fragmenting the memory?

Besides that, we just found a system that hangs on the subsequent boot
after executing the application. The strange is that the system just hangs
if you do the following steps:

1 - execute the application: app.efi
2 - exit the shell with the command: exit
3 - boot hangs not presenting the shell prompt


In case you do the following steps the hang doesn't happen:

1 - execute the application: app.efi
2 - shut down the system by pressing the power button
3 - boots normally entering at the shell prompt

Any idea about what could cause this strange behavior, and if this may have
some relation with the increase of the memmap output entries? (maybe
something related with the MemoryTypeInformation information that seems to
be saved to make the subsequent boots easier from the bios perspective.
This guess is based on [1] page 19, that explains the creation of the
BIN.DXE, but things are a little dark to me yet. Not sure if my
understanding is correct.)

[1]
https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Memory_Map_in%20UEFI_BIOS.pdf

Thanks and Regards
Rafael R. Machado

Em sex, 29 de jun de 2018 às 22:31, Ni, Ruiyu  escreveu:

> Yes.
> Check the PCD PcdShellMaxHistoryCommandCount (0x20) which sets
> the maximum command history.
> The memmap output should be stable after you run more than
> 0x20 commands.
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Yao,
> > Jiewen
> > Sent: Saturday, June 30, 2018 3:28 AM
> > To: Rafael Machado ; edk2-
> > de...@lists.01.org
> > Subject: Re: [edk2] Question about memory map entries
> >
> > Shell itself may allocate internal buffer to save something, such as
> history.
> >
> > Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > > Rafael Machado
> > > Sent: Friday, June 29, 2018 12:06 PM
> > > To: edk2-devel@lists.01.org
> > > Subject: [edk2] Question about memory map entries
> > >
> > > Hi everyone
> > >
> > > I have a question related to the memory map entries.
> > > Doing some tests, we noticed that if I have an application that has a
> > > lot of allocatepool() and freepool() calls, when this app is closed
> > > the amount of entries returned by the memmap shell commands increases a
> > lot.
> > >
> > > Just for reference. This is the mapping before executing the
> application:
> > >
> > > Type   StartEnd  # Pages
> > > Attributes
> > > BS_Code-0FFF 0001
> > > 000F
> > > BS_Data1000-1FFF 0001
> > > 000F
> > > BS_Code2000-BFFF 000A
> > > 000F
> > > Available  C000-00057FFF 004C
> > > 000F
> > > Reserved   00058000-00058FFF 0001
> > > 000F
> > > Available  00059000-00069FFF 0011
> > > 000F
> > > BS_Data0006A000-0006AFFF 0001
> > > 000F
> > > BS_Code0006B000-0008BFFF 0021
> > > 000F
> > > Reserved   0008C000-0009 0014
> > > 000F
> > > BS_Code0010-0010 0010
> > > 000F
> > > Available  0011-4D684FFF 0004D575
> > > 000F
> > > BS_Data4D685000-4D6A4FFF 0020
> > > 000F
> > > Available  4D6A5000-4E34EFFF 0CAA
> > > 000F 

[edk2] Question about memory map entries

[Rafael Machado]

Hi everyone

I have a question related to the memory map entries.
Doing some tests, we noticed that if I have an application that has a lot
of allocatepool() and freepool() calls, when this app is closed the amount
of entries returned by the memmap shell commands increases a lot.

Just for reference. This is the mapping before executing the application:

Type   StartEnd  # Pages  Attributes
BS_Code-0FFF 0001
000F
BS_Data1000-1FFF 0001
000F
BS_Code2000-BFFF 000A
000F
Available  C000-00057FFF 004C
000F
Reserved   00058000-00058FFF 0001
000F
Available  00059000-00069FFF 0011
000F
BS_Data0006A000-0006AFFF 0001
000F
BS_Code0006B000-0008BFFF 0021
000F
Reserved   0008C000-0009 0014
000F
BS_Code0010-0010 0010
000F
Available  0011-4D684FFF 0004D575
000F
BS_Data4D685000-4D6A4FFF 0020
000F
Available  4D6A5000-4E34EFFF 0CAA
000F
LoaderCode 4E34F000-4E42CFFF 00DE
000F
BS_Data4E42D000-50510FFF 20E4
000F
ACPI_NVS   50511000-50511FFF 0001
000F
RT_Data50512000-50512FFF 0001
800F
BS_Data50513000-50673FFF 0161
000F
BS_Code50674000-50674FFF 0001
000F
Available  50675000-52B6EFFF 24FA
000F
BS_Data52B6F000-53572FFF 0A04
000F
Available  53573000-53834FFF 02C2
000F
BS_Data53835000-53A0DFFF 01D9
000F
Available  53A0E000-53A64FFF 0057
000F
BS_Data53A65000-54778FFF 0D14
000F
Available  54779000-54785FFF 000D
000F
BS_Data54786000-547CAFFF 0045
000F
Available  547CB000-547D3FFF 0009
000F
BS_Data547D4000-5481DFFF 004A
000F
Available  5481E000-5481 0002
000F
BS_Data5482-56683FFF 1E64
000F
Available  56684000-590C2FFF 2A3F
000F
BS_Code590C3000-59E83FFF 0DC1
000F
RT_Code59E84000-59F4BFFF 00C8
800F
RT_Data59F4C000-5B164FFF 1219
800F
Reserved   5B165000-5B566FFF 0402
000F
ACPI_NVS   5B567000-5B599FFF 0033
000F
ACPI_Recl  5B59A000-5B5FEFFF 0065
000F
BS_Data5B5FF000-5B5F 0001
000F
Available  0001-00029E7F 0019E800
000F
Reserved   000A-000F 0060

Reserved   5B60-5F7F 4200

MMIO   F000-F7FF 8000
8001
MMIO   FE01-FE010FFF 0001
8001

  Reserved  : 18,039 Pages (73,887,744 Bytes)
  LoaderCode:222 Pages (909,312 Bytes)
  LoaderData:  0 Pages (0 Bytes)
  BS_Code   :  3,582 Pages (14,671,872 Bytes)
  BS_Data   : 23,116 Pages (94,683,136 Bytes)
  RT_Code   :200 Pages (819,200 Bytes)
  RT_Data   :  4,634 Pages (18,980,864 Bytes)
  ACPI_Recl :101 Pages (413,696 Bytes)
  ACPI_NVS  : 52 Pages (212,992 Bytes)
  MMIO  : 32,769 Pages (134,221,824 Bytes)
  MMIO_Port :  0 Pages (0 Bytes)
  PalCode   :  0 Pages (0 Bytes)
  Available :  2,039,014 Pages (8,351,801,344 Bytes)
  --
Total Memory:  8,089 MB (8,482,492,416 Bytes)



And this is the mapping after executing the application.


Type   StartEnd  # Pages  Attributes
BS_Code-0FFF 0001
000F
BS_Data1000-1FFF 0001
000F
BS_Code2000-BFFF 

Re: [edk2] OSFC 2018

[Rafael Machado]

Nice initiative!

Will the presentations be recorded and posted at youtube?

Thanks
Rafael R. Machado

Em ter, 5 de jun de 2018 às 09:10, Philipp Deppenwiese <
zaolin.dais...@gmail.com> escreveu:

> Dear Ladies and Gentlemen,
>
> We invite you to the Open Source Firmware Conference 2018
> ( www.osfc.io ) which takes place at the 12th - 15th September
> in Erlangen, Germany.
>
> The OSFC 2018 is the first conference focusing exclusively on Open
> Source firmware.
> Therefore, our mission is to provide an appropriate platform to bring
> together as many Open Source projects,
> hardware manufacturers and developers as possible.
> In order to collaborate, share knowledge and push the Open Source
> firmware development.
>
> Get in touch with community of coreboot, LinuxBoot, Tianocore, U-Boot
> and be part of our amazing firmware conference!
>
> Tickets are available: https://osfc.io/tickets
> CFP is available: https://easychair.org/cfp/osfc2018
> Follow us on Twitter: osfc_io
>
>
> Best Regards, Philipp
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Empty function at BaseCacheMaintenanceLib

[Rafael Machado]

Got it!

Thanks for the answer Andrew.

Rafael Machado

Em ter, 8 de mai de 2018 às 12:55, Andrew Fish <af...@apple.com> escreveu:

> Rafael,
>
> I seem to remember those functions are used to manage the cache on a
> Harvard architecture caches  [1].
>
> If you look at InvalidateInstructionCacheRange() you will notice it is
> used when code gets loaded into memory to keep the data and instruction
> caches coherent. If the instruction cache maintains coherency in hardware
> then there is no need for this functions to do anything.
>
> If you notice the IPF version actually does something, and that is why
> these functions exists.
>
> [1]  https://en.wikipedia.org/wiki/Harvard_architecture
>
> Thanks,
>
> Andrew Fish
>
> On May 8, 2018, at 6:46 AM, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
>
> Hi everyone
>
> I have a question. During a research I got to the BaseCacheMaintenanceLib,
> and noticed that there is a function that is not implemented.
>
> The function InvalidateInstructionCache does not have a body, but as far as
> I
> could check it's used in some places.
>
> Is it ok to have this function empty?
>
> Thanks and Regards
> Rafael R. Machado
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Empty function at BaseCacheMaintenanceLib

[Rafael Machado]

Hi everyone

I have a question. During a research I got to the BaseCacheMaintenanceLib,
and noticed that there is a function that is not implemented.

The function InvalidateInstructionCache does not have a body, but as far as
I
could check it's used in some places.

Is it ok to have this function empty?

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] NVMe Smart Data Buffer Size

[Rafael Machado]

Hi Hao Wu

Thanks for clarifying. The problem was that my code didn't consider the
command packet CDw10 as 0's based.

Best Regards
Rafael R. Machado

Em qua, 28 de mar de 2018 às 22:30, Wu, Hao A <hao.a...@intel.com> escreveu:

> Hi,
>
> Some comments below:
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Rafael Machado
> > Sent: Wednesday, March 28, 2018 9:32 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] NVMe Smart Data Buffer Size
> >
> > Hi everyone
> >
> > I'am working on a development related to retrieving the SMART data
> > information from a NVMe device.
> > After some research I got to a code that works correctly, but I would
> like
> > to have a 100% understanding of why it works.
> >
> > To retrieve the SMART data I send the command
> > (EFI_NVM_EXPRESS_COMMAND) as
> > follows:
> >
> > //
> > //Fill the EFI_NVM_EXPRESS_COMMAND struct
> > Command->Cdw0.Opcode = NVME_ADMIN_GET_LOG_PAGE_CMD; //This is
> > the command
> > 0x02
> > Command->Nsid =   NVME_ALL_VALID_NSID; //The NSID used in this case is
> > the 0x to retrieve the global information
> > Command->Cdw10 =  (4096 << 16) | 2; // page 2 is the Smart/Health log
> page
> > Command->Cdw11 =  0x0;
> > Command->Cdw12 =  0x0;
> > Command->Cdw13 =  0x0;
> > Command->Flags =  CDW10_VALID
> >  | CDW11_VALID
> >  | CDW12_VALID
> >  | CDW13_VALID;
> >
> > // Fill the EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET struct
> > This->Nsid = NVME_ALL_VALID_NSID;  //This is the NSID used by
> > the NVME_PROTOCOL, that is also 0x
> > CommandPacket->NvmeCmd= Command;
> > CommandPacket->NvmeCompletion = Completion;
> > CommandPacket->TransferBuffer = (VOID*) SmartData;
> > CommandPacket->TransferLength = 4096;
> > CommandPacket->CommandTimeout = 0;
> > CommandPacket->QueueType  = NVME_ADMIN_QUEUE;
> > CommandPacket->MetadataBuffer = NULL;
> > CommandPacket->MetadataLength = 0;
> > //
> >
> > The question I have, is about the size of the buffer to be used as the
> > transfer buffer at the EFI_NVM_EXPRESS_COMMAND and at the
> > EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET. At the Nvme spec we
> > see that the
> > SmartData information is 512 bytes long.
> >
> > So the question is.
> > Why, even having just 512 bytes to be retrieved by the GetLogCommand page
> > 0x02, do I need to create a 4096 bytes buffer to retrieve the SMART data
> ?
>
> I have a check on the NVMe v1.1 spec for the Get Log Page command:
>
> For Command Dword 10:
> 27:16 Number of Dwords (NUMD):
> This field specifies the number of Dwords to return. If host software
> specifies a size larger than the log page requested, the results are
> undefined. This is a 0's based value.
>
> Per my understanding, since the field requires a 0's based Dword value,
> for getting the SMART / Health Information (which is 512 bytes in length),
> the Cdw10 should be:
> Command->Cdw10 =  (127 << 16) | 2; // 128 Dword, 0's based
>
> And for the PassThru command packet:
> CommandPacket->TransferLength = 512;
>
> Please help to verify if this works properly for you. Thanks in advance.
>
> >
> > Command->Cdw10 =  (4096 << 16) | 2;
> > CommandPacket->TransferBuffer = (VOID*) SmartData; (allocated previously)
> > CommandPacket->TransferLength = 4096;
> >
> > Just for reference. When I create a 512 bytes buffer I get a DeviceError
> > status after the PassThru. With the sample code below:
> >
> > Command->Cdw10 =  (512 << 16) | 2;
> > CommandPacket->TransferBuffer = (VOID*) SmartData; (allocated previously)
> > CommandPacket->TransferLength = 512;
> >
> >
> > Another question I have is:
> > We have two places that we need to set the Nsid.
> >
> > EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET. Nsid
> > EFI_NVM_EXPRESS_COMMAND.Nsid
> >
> > Since I am not a NVme expert, my question is if both represent the same
> > information.
> > Should I use 0x in both?
>
> Yes, you are right.
>
> These two values:
> NamespaceId param for EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL.PassThru() and
> Nsid field of EFI_NVM_EXPRESS_COMMAND
>
> should be set to the same value.
>
> Best Regards,
> Hao Wu
>
> >
> > Thanks and Regards
> > Rafael R. Machado
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] NVMe Smart Data Buffer Size

[Rafael Machado]

Hi everyone

I'am working on a development related to retrieving the SMART data
information from a NVMe device.
After some research I got to a code that works correctly, but I would like
to have a 100% understanding of why it works.

To retrieve the SMART data I send the command (EFI_NVM_EXPRESS_COMMAND) as
follows:

//
//Fill the EFI_NVM_EXPRESS_COMMAND struct
Command->Cdw0.Opcode = NVME_ADMIN_GET_LOG_PAGE_CMD; //This is the command
0x02
Command->Nsid =   NVME_ALL_VALID_NSID; //The NSID used in this case is
the 0x to retrieve the global information
Command->Cdw10 =  (4096 << 16) | 2; // page 2 is the Smart/Health log page
Command->Cdw11 =  0x0;
Command->Cdw12 =  0x0;
Command->Cdw13 =  0x0;
Command->Flags =  CDW10_VALID
 | CDW11_VALID
 | CDW12_VALID
 | CDW13_VALID;

// Fill the EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET struct
This->Nsid = NVME_ALL_VALID_NSID;  //This is the NSID used by
the NVME_PROTOCOL, that is also 0x
CommandPacket->NvmeCmd= Command;
CommandPacket->NvmeCompletion = Completion;
CommandPacket->TransferBuffer = (VOID*) SmartData;
CommandPacket->TransferLength = 4096;
CommandPacket->CommandTimeout = 0;
CommandPacket->QueueType  = NVME_ADMIN_QUEUE;
CommandPacket->MetadataBuffer = NULL;
CommandPacket->MetadataLength = 0;
//

The question I have, is about the size of the buffer to be used as the
transfer buffer at the EFI_NVM_EXPRESS_COMMAND and at the
EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET. At the Nvme spec we see that the
SmartData information is 512 bytes long.

So the question is.
Why, even having just 512 bytes to be retrieved by the GetLogCommand page
0x02, do I need to create a 4096 bytes buffer to retrieve the SMART data ?

Command->Cdw10 =  (4096 << 16) | 2;
CommandPacket->TransferBuffer = (VOID*) SmartData; (allocated previously)
CommandPacket->TransferLength = 4096;

Just for reference. When I create a 512 bytes buffer I get a DeviceError
status after the PassThru. With the sample code below:

Command->Cdw10 =  (512 << 16) | 2;
CommandPacket->TransferBuffer = (VOID*) SmartData; (allocated previously)
CommandPacket->TransferLength = 512;


Another question I have is:
We have two places that we need to set the Nsid.

EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET. Nsid
EFI_NVM_EXPRESS_COMMAND.Nsid

Since I am not a NVme expert, my question is if both represent the same
information.
Should I use 0x in both?

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] DMA Buffer write operation not persisted

[Rafael Machado]

Hi Andrew

Thanks for the answer.

The allocation was done at other part of the code. But yet, I used the
PciI->AllocateBuffer() function.

One question, about the topics retrieved from the spec.
When the spec says "• The common buffer can now be accessed equally by the
processor and the DMA bus master."

Does this means that I can write some data using a simple pointer, like for
example copying some data using MemCopy? Or should I still use the
PciIo->Mem.Write...?

I'll really this part of the spec carefully.

Thanks and Regards
Rafael R. Machado

Em qui, 25 de jan de 2018 às 17:04, Andrew Fish <af...@apple.com> escreveu:

> Rafeal,
>
> There are some good summaries in the UEFI Spec that really help.
>
> DMA Bus Master Common Buffer Operation
> • Call AllocateBuffer() to allocate a common buffer.
> • Call Map() for EfiPciOperationBusMasterCommonBuffer or
> EfiPciOperationBusMasterCommonBuffer64.
> • Program the DMA Bus Master with the DeviceAddress returned by Map().
> • The common buffer can now be accessed equally by the processor and the
> DMA bus master.
> • Call Unmap().
> • Call FreeBuffer().
>
> Did you miss the PciIo->AllocateBuffer() call?
>
> For x86 it can abstract things like DMA only supported < 4GB.
> For ARM it may need to change the cacheability of the region etc.
>
> Thanks,
>
> Andrew Fish
>
> > On Jan 25, 2018, at 10:53 AM, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
> >
> > Hi everyone.
> >
> > I'm currently work on a task, and I need to write some data at a DMA
> buffer.
> > At the UEFI Driver Writer's guide, at page 359 there is a sample code of
> > how to do that.
> >
> > Considering that code and adapting to my scenario I got the following
> > function (some debug prints are present for clarification):
> >
> > EFI_STATUS
> > EFIAPI
> > DoBusMasterWrite (
> >  IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciIo,
> >  IN UINT8 *HostAddress,
> >  IN UINTN *Length,
> >  IN UINT32 Value
> > )
> > {
> >  EFI_STATUS Status;
> >  UINTN NumberOfBytes;
> >  EFI_PHYSICAL_ADDRESS DeviceAddress;
> >  VOID *Mapping;
> >  UINT64 ReadValue;
> >
> >  //
> >  // Call Map() to retrieve the DeviceAddress to use for the bus
> >  // master write operation. The Map() function may not support
> >  // performing a DMA operation for the entire length, so it may
> >  // be broken up into smaller DMA operations.
> >  //
> >  NumberOfBytes = *Length;
> >  Status = PciIo->Map (PciIo, // This
> >
> > EfiPciIoOperationBusMasterCommonBuffer, // Operation
> > (VOID *)HostAddress, // HostAddress
> > , // NumberOfBytes
> > , //DeviceAddress
> >  //Mapping);
> >
> >  if (EFI_ERROR (Status)) {
> >return Status;
> >  }
> >
> >  //
> >  // Write the data to the desired address
> >  // This write operation also starts the DMA transaction
> >  //
> >  Status = PciIo->Mem.Write (PciIo, // This
> >   EfiPciIoWidthUint32, //
> Width
> >   *HostAddress,
> >   1, // Count
> >// Buffer
> >   );
> >
> >  Print(L"NumberOfBytes: %d\r\n", NumberOfBytes);
> >  Print(L"address: 0x%x\r\n", HostAddress);
> >  Print(L"Value: 0x%x\r\n", Value);
> >  Print(L"Status: %r\r\n", Status);
> >
> >  if (EFI_ERROR (Status)) {
> > return Status;
> >  }
> >
> >  //
> >  // The operations performed by PollMem() also flush all posted
> >  // writes from the PCI bus master and through PCI-to-PCI bridges.
> >  //
> >  Status = PciIo->PollMem (PciIo, // This
> >   EfiPciIoWidthUint32, //
> Width
> >   *HostAddress, // Offset
> >   0x,// Mask
> >   Value,// Value
> >   EFI_TIMER_PERIOD_SECONDS
> > (1), // Timeout
> >// Result
> >   );
> >  Print(L"Status2: %r\r\n", Status);
> >
> >  if (EFI_ERROR (Status)) {
>

[edk2] DMA Buffer write operation not persisted

[Rafael Machado]

Hi everyone.

I'm currently work on a task, and I need to write some data at a DMA buffer.
At the UEFI Driver Writer's guide, at page 359 there is a sample code of
how to do that.

Considering that code and adapting to my scenario I got the following
function (some debug prints are present for clarification):

EFI_STATUS
EFIAPI
DoBusMasterWrite (
  IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciIo,
  IN UINT8 *HostAddress,
  IN UINTN *Length,
  IN UINT32 Value
)
{
  EFI_STATUS Status;
  UINTN NumberOfBytes;
  EFI_PHYSICAL_ADDRESS DeviceAddress;
  VOID *Mapping;
  UINT64 ReadValue;

  //
  // Call Map() to retrieve the DeviceAddress to use for the bus
  // master write operation. The Map() function may not support
  // performing a DMA operation for the entire length, so it may
  // be broken up into smaller DMA operations.
  //
  NumberOfBytes = *Length;
  Status = PciIo->Map (PciIo, // This

 EfiPciIoOperationBusMasterCommonBuffer, // Operation
 (VOID *)HostAddress, // HostAddress
 , // NumberOfBytes
 , //DeviceAddress
  //Mapping);

  if (EFI_ERROR (Status)) {
return Status;
  }

  //
  // Write the data to the desired address
  // This write operation also starts the DMA transaction
  //
  Status = PciIo->Mem.Write (PciIo, // This
   EfiPciIoWidthUint32, // Width
   *HostAddress,
   1, // Count
// Buffer
   );

  Print(L"NumberOfBytes: %d\r\n", NumberOfBytes);
  Print(L"address: 0x%x\r\n", HostAddress);
  Print(L"Value: 0x%x\r\n", Value);
  Print(L"Status: %r\r\n", Status);

  if (EFI_ERROR (Status)) {
return Status;
  }

  //
  // The operations performed by PollMem() also flush all posted
  // writes from the PCI bus master and through PCI-to-PCI bridges.
  //
  Status = PciIo->PollMem (PciIo, // This
   EfiPciIoWidthUint32, // Width
   *HostAddress, // Offset
   0x,// Mask
   Value,// Value
   EFI_TIMER_PERIOD_SECONDS
(1), // Timeout
// Result
   );
  Print(L"Status2: %r\r\n", Status);

  if (EFI_ERROR (Status)) {
return Status;
  }

  //
  // Call Flush() to flush all write transactions to system memory
  //
  Status = PciIo->Flush (PciIo);
  Print(L"Status3: %r\r\n", Status);

  if (EFI_ERROR (Status)) {
return Status;
  }

  //
  // Call Unmap() to complete the bus master write operation
  //
  Status = PciIo->Unmap (PciIo, Mapping);
  Print(L"Status4: %r\r\n", Status);

  if (EFI_ERROR (Status)) {
return Status;
  }
  return Status;
}

The output of this function is this:
  NumberOfBytes: 4
  address: 0xCCCAC000
  Value: 0xA
  Status: Success
  Status2: Success
  Status3: Success
  Status4: Success

The problem is that when I try to read this memory content using the dmem
command at the efiShell the value 0xA cannot be found. Seems something
is locking the DMA trasaction.
Can someone give me some light?

Thanks and Regard
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] UEFI App embedded on another uefi app

[Rafael Machado]

Hi Everyone.

I have a limited space problem at a project.
To solve this we had an idea, but would like to ask to you before expending
time on trying to do it, due to some tight schedule. (We know that the best
is to try before ask, but we do not have time for that now. Sorry for that.)

The idea is to create a kind of DecompressorApp.efi, that
uses  EFI_DECOMPRESS_PROTOCOL

During the compilation process of the application the tasks would be:

- Compile App.efi
- Compress App.efi, generating the App.efi.compressed (using
tianoCompress.exe)
- Compile the Decompressor.efi app (with the App.efi.compressed embedded)
   - The idea to do this is to add the compressed app as a Binary at
the DecompressorApp.efi .inf file using the [Binaries] tag


So during the entrypoint of the Decompressor.efi app, the application will
need to copy the compressed part of the app (App.efi.compressed), to a
buffer, and after that this buffer will be decompressed using the
EFI_DECOMPRESS_PROTOCOL. Finally the execution control is passed to the
App.efi decompressed (not sure how to do that yet).

So the questions we have for know are:

- How to detect the App.efi.compressed insyde the loaded app, so we can
have an address to decompress
- How to pass the application executions control to another app, that is in
a buffer (not sure if this can be done with the EFI Boot Service
LoadImage(), since this buffer does not have a valid file device path)

Could you help us on understanding if this is possible?

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] How do i generate a SHA256 hash in UEFI

[Rafael Machado]

Hi Amit

You can use the CryptoPkg functionalities.

https://github.com/tianocore/edk2/tree/UDK2017/CryptoPkg

At this package you will find some hash functions that are wrapped from
OpenSSL

https://github.com/tianocore/edk2/tree/UDK2017/CryptoPkg/Library/BaseCryptLib/Hash

With this you'll not need to rely on the system hash protocols.

Hope this can help.
Rafael Machado

Em seg, 25 de set de 2017 às 15:41, Amit kumar <akami...@hotmail.com>
escreveu:

> Hi ,
>
> I am trying to write a uefi standalone application ( not a uefi shell
> app), which generates a sh256 hash, can some body tell me the right way to
> do it.
> Do i really need to use hash protocol. Is there any other way to do it
> without using this protocol ?
> Best Regards
> Amit Kumar
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] What Bios data is sent to the Bootloader/OS ?

[Rafael Machado]

Hi Igor

Nice catch.
Thanks for this idea!

Rafael Machado

On seg, 14 de ago de 2017 17:49 Igor Skochinsky <skochin...@gmail.com>
wrote:

>
> Hi Rafael,
>
> It's certainly possible although not trivial.
> One possible approach is DUET which can emulate UEFI environment on top of
> the legacy BIOS. So you could have your legacy bootloader load DUET, which
> would in turn load and boot the UEFI-compatible OS. This page may be of
> use: http://www.rodsbooks.com/bios2uefi/index.html
>
> AFAIK GRUB already supports both BIOS and UEFI booting, so you may not
> have to do anything except set it up correctly.
>
> On Fri, Aug 11, 2017 at 3:00 PM, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
>
>> Hi everyone
>>
>> I have a question that probably some guys here can help.
>> The scenario I have, is that I need to create a OS image that must be able
>> to boot at a UEFI system (with no csm module), and at a legacy bios
>> system.
>> My fist thought is that this is not possible.
>>
>> The first thing I see that is different is the what the memory map is
>> presented to the Bootloader/OS. At legacy bios the int15/0xE820 is used,
>> and at a UEFI bios the GetMemoryMap() from the boot service is used. Is my
>> understanding correct?
>>
>> Besides that. Is there any other change that could not make it possible to
>> create a single BootloaderLoader/OS image able to boot on a UEFI BIOS(with
>> no CSM) and on a Legacy Bios ?
>>
>> I would like to create a list or arguments to talk with my client that
>> requested this, in case this is really not possible.
>>
>> The OS in this case is Linux, and the bootloader is Grub or Syslinux.
>>
>> Thanks and Regards
>> Rafael R. Machado
>>
> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>>
>
>
>
> --
> WBR, Igor
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] What Bios data is sent to the Bootloader/OS ?

[Rafael Machado]

Thanks a lot Andrew and Rod. Your comments clarified a lot.

Just onde last question.
In case of int15/e820 and uefi getMemoryMap. Do you know If this
information os used by the bootloaders?
And do you know the format on these calls outputs? (For the  getMemoryMap
the uefi Spec os clear, but didn't find anything about e820).

Thanks and Regards
Rafael Machado

Em sáb, 12 de ago de 2017 00:23, Rod Smith <rodsm...@rodsbooks.com>
escreveu:

> On Aug 11, 2017, at 6:00 AM, Rafael Machado
> <rafaelrodrigues.mach...@gmail.com> wrote:
> >>
> >> Hi everyone
> >>
> >> I have a question that probably some guys here can help.
> >> The scenario I have, is that I need to create a OS image that must be
> able
> >> to boot at a UEFI system (with no csm module), and at a legacy bios
> system.
> >> My fist thought is that this is not possible.
>
> If I understand you correctly, it most definitely IS possible. Most
> major Linux distributions provide installation media that can boot in
> either BIOS/CSM/legacy mode or in EFI/UEFI mode. Replicating what those
> media do might not be the best way to go, though, since they are also
> typically designed to boot when written to optical media or when written
> to USB flash drives. To do this, they use a sort of "Frankenstein's
> Monster" disk format, so unless you need this cross-media compatibility,
> too, using the tools and procedures used to create these installation
> media would be overkill and would create something that's overly
> complex. These media do illustrate the practicality of what you're
> suggesting -- or at least, what I *BELIEVE* you're suggesting. If I've
> misinterpreted, please clarify your needs.
>
> >> The OS in this case is Linux, and the bootloader is Grub or Syslinux.
>
> A single GRUB (or SYSLINUX) binary will not do the job; however, there
> are both BIOS and EFI builds of both GRUB and SYSLINUX. The details of
> what you'd do would depend on the boot medium (hard disk, USB flash
> drive, optical disc, etc.); however, broadly speaking you need to write
> both BIOS-mode and EFI-mode versions of your chosen boot loader to the
> boot medium, with suitable configuration files in appropriate locations.
>
> Both GRUB and SYSLINUX are boot loaders that can load a Linux kernel
> into memory. The Linux kernel, in turn, does not need to be built for
> either BIOS or EFI environments; the same kernel binary will work in
> either environment. (One partial exception is that there's a feature
> known as the EFI stub loader that turns the Linux kernel into its own
> EFI boot loader. If you wanted to use this feature, it would obviously
> need to be compiled into the kernel. GRUB does not require this feature,
> though, and its presence will not interfere with the kernel being booted
> on a BIOS-based computer. Thus, you probably don't need to worry about
> it for your purposes. I mention it simply so you don't think it's an
> issue if you read something about it elsewhere.)
>
> --
> Rod Smith
> rodsm...@rodsbooks.com
> http://www.rodsbooks.com
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] What Bios data is sent to the Bootloader/OS ?

[Rafael Machado]

Hi everyone

I have a question that probably some guys here can help.
The scenario I have, is that I need to create a OS image that must be able
to boot at a UEFI system (with no csm module), and at a legacy bios system.
My fist thought is that this is not possible.

The first thing I see that is different is the what the memory map is
presented to the Bootloader/OS. At legacy bios the int15/0xE820 is used,
and at a UEFI bios the GetMemoryMap() from the boot service is used. Is my
understanding correct?

Besides that. Is there any other change that could not make it possible to
create a single BootloaderLoader/OS image able to boot on a UEFI BIOS(with
no CSM) and on a Legacy Bios ?

I would like to create a list or arguments to talk with my client that
requested this, in case this is really not possible.

The OS in this case is Linux, and the bootloader is Grub or Syslinux.

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] UEFI ABI calling convention details

[Rafael Machado]

Thanks a lot Marvin!!

Em qua, 28 de jun de 2017 às 12:02, Marvin H?user <
marvin.haeu...@outlook.com> escreveu:

> Hey Rafael,
>
> The UEFI calling conventions are detailed in the UEFI specification, more
> specifically section 2.3 of the UEFI 2.7 specification.
>
> Regards,
> Marvin.
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Rafael Machado
> > Sent: Wednesday, June 28, 2017 1:55 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] UEFI ABI calling convention details
> >
> > Hi everyone
> >
> > I have a question.
> > Some time ago, at this conversation "
> > https://www.mail-archive.com/edk2-devel@lists.01.org/msg25383.html; it
> > was mentioned the UEFI ABI calling convention.
> >
> > I've tried to search for some document with the details of this calling
> > convention, but didn't find anything.
> > Does anyone know where can I have more details about this ? (UEFI ABI
> > calling convention)
> >
> > Thanks and Regards
> > Rafael R. Machado
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] UEFI ABI calling convention details

[Rafael Machado]

Hi everyone

I have a question.
Some time ago, at this conversation "
https://www.mail-archive.com/edk2-devel@lists.01.org/msg25383.html; it was
mentioned the UEFI ABI calling convention.

I've tried to search for some document with the details of this calling
convention, but didn't find anything.
Does anyone know where can I have more details about this ? (UEFI ABI
calling convention)

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] MemoryProfile at UDK2015

[Rafael Machado]

Perfect.

Thanks for the answer Brian!

Em seg, 10 de abr de 2017 às 16:26, Richardson, Brian <
brian.richard...@intel.com> escreveu:

> UDL2015 is a stable snapshot of EDK II modules validated on Intel
> architecture platforms. This module isn't validated as part of that
> snapshot, hence the omission. You can still use this module with UDK2015,
> as long as you pull from the git hash or SVN revision from the UDK2015
> release notes.
>
> Thanks ... br
> ---
> Brian Richardson, Senior Technical Marketing Engineer, Intel Software
> brian.richard...@intel.com -- @intel_Brian (Twitter & WeChat)
>
> https://software.intel.com/en-us/meet-the-developers/evangelists/team/brian-richardson
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Rafael Machado
> Sent: Monday, April 10, 2017 3:15 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] MemoryProfile at UDK2015
>
> Hi everyone.
>
> I was taking a look on how to detect a memory leak, and found this page:
>
> https://github.com/tianocore/tianocore.github.io/wiki/Memory-leak-detection-with-memory-profile-feature
>
> When trying to follow these steps, I noticed that we don't have the
> MemoryProfileLib available at the UDK2015 branch, but it's available at the
> master branch, at edk2 <https://github.com/tianocore/edk2>/MdeModulePkg
> <https://github.com/tianocore/edk2/tree/master/MdeModulePkg>/Include
> <https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Include
> >/Library
> <
> https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Include/Library
> >
> /MemoryProfileLib.h
>
> Is there any incompatibility or something like this that limits the use of
> this lib at the UDK2015?
>
> Thanks
> Rafael Machado
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] MemoryProfile at UDK2015

[Rafael Machado]

Hi everyone.

I was taking a look on how to detect a memory leak, and found this page:
https://github.com/tianocore/tianocore.github.io/wiki/Memory-leak-detection-with-memory-profile-feature

When trying to follow these steps, I noticed that we don't have the
MemoryProfileLib available at the UDK2015 branch, but it's available at the
master branch, at edk2 <https://github.com/tianocore/edk2>/MdeModulePkg
<https://github.com/tianocore/edk2/tree/master/MdeModulePkg>/Include
<https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Include>/Library
<https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Include/Library>
/MemoryProfileLib.h

Is there any incompatibility or something like this that limits the use of
this lib at the UDK2015?

Thanks
Rafael Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Sec and Reset vector

[Rafael Machado]

Hi guys.

This e-mail if for the future generations, and proves everything you guys
commented to guide me when I did the first question.

So if you have a uefi firmware image, and would like to check how
everything happens using radare,
you need to do the following:

step 1: Check your .bin file size (in my case the image has 16MB)
step 2: convert the image size using a calculator (16MB * 1024 * 1024 =
0x100 )
step 3: Since everything at the first stages of the boot happens in real
mode, the instructions are 16 bits long, so you need to go back 16 bits,
this gives you the position 0xF0. Now you are at the reset vector

At radare you can do all this using these commands:

radare2.exe mybios.bin -b 16
> s 0x100
> s -16
> pd 10

The attached image shows an example of the result.
Thanks everyone for the comments and tips.


Rafael R. Machado

[image: FindingTheResetVector.png]


Em sex, 4 de nov de 2016 às 20:19, Rafael Machado <
rafaelrodrigues.mach...@gmail.com> escreveu:

> All the answers were really detailed and I agree with Andrew. These
> answers are a great help when we are learning.
>
> Thanks a lot guys. I learn a lot with this community.
>
> Thanks and regards
>
>
> Rafael
>
> Em sex, 4 de nov de 2016 19:28, Kinney, Michael D <
> michael.d.kin...@intel.com> escreveu:
>
> Rafael,
>
> The first instruction executed for IA32 SEC phase is typically 16-bytes
> from
> the end of the Firmware Device (FD) image generated by a build.
>
> If you look at QuarkPlatformPkg/Quark.dsc as an example build, it generates
> an 8MB  file called Quark.FD.  The reset vector is 16-bytes from the end of
> that file.  The reset vector and rest of SEC code are all in a special FFS
> file
> known at the Volume Top File(VFT).
>
> The source code for the reset vector is in the file:
>
> UefiCpuPkg/SecCore/Ia32/ResetVector.nasmb
>
> This source file contains the code that fills the last 0x40 bytes of the
> VTF
> which is also the last 0x40 bytes of Quark.FD.
>
> The build tools do some special fixups on this file, so 16-bit relative JMP
> instruction at line 79 is fixed up to jump to the symbol _ModuleEntryPoint.
>
> ResetHandler:
> nop
> nop
> ApStartup:
> ;
> ; Jmp Rel16 instruction
> ; Use machine code directly in case of the assembler
> optimization
> ; SEC entry point relative address will be fixed up by some
> build tool.
> ;
> ; Typically, SEC entry point is the function
> _ModuleEntryPoint() defined in
> ; SecEntry.asm
> ;
> DB  0e9h
> DW  -3
>
> For Quark.FD, _ModuleEntryPoint is from the PlatformSecLib library at:
>
> QuarkPlatformPkg/Library/PlatformSecLib
>
> Specifically Line l5 of the file:
>
> QuarkPlatformPkg/Library/PlatformSecLib/Ia32/Flat32.asm
>
> _ModuleEntryEntryPoint starts in 16-bit real mode and transitions to
> 32-bit protected mode, initializes ESRAM to be used as a stack, and
> transfers control to the C function PlatformSecLibStartup() at line 220.
> The goal is to minimize the amount of assembly code and get into C code
> as quickly as possible.
>
> The PlatformSecLibStartup() function implementation is in the same
> PlatformSecLib library at line 68 of the file:
>
> QuarkPlatformPkg/Library/PlatformSecLib/PlatformSecLib.c
>
> Best regards,
>
> Mike
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Rafael Machado
> > Sent: Friday, November 4, 2016 12:34 PM
> > To: Andrew Fish <af...@apple.com>
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] Sec and Reset vector
> >
> > Hi Andrew
> >
> > Maybe my question was not clear.
> > But thanks for the information you provided.
> >
> > I think we can simplify what I need based on your last comment. You told:
> >
> > *"The .com file contains the hardware real mode reset vector
> (0xFFF0).
> > So execution starts up high. The 1st far jmp you do gets you running in
> the
> > 0x000F**** range (the ROM is aliased to the old PC address)"*
> >
> > How could I find the .com file inside the dump of a bios (I have used
> > DediProg to get the dump)?
> > I'm hunting the first far jump the firmware has.
> >
> > Thanks
> > Rafael
> >
> > Em sex, 4 de nov de 2016 às 16:50, Andrew Fish <af...@apple.com>
> escreveu:
> >
> > > On Nov 4, 2016, at 10:48 AM, Rafael Machado <
> > > rafaelrodrigues.mach...@gmail.com> wrote:
> > &g

Re: [edk2] Intel raid EFI Shell driver wanted

[Rafael Machado]

Hi David.

Theo only UEFI RAID driver I know is for LSI controllers.
This is the link with the details:

https://www.broadcom.com/support/knowledgebase/1211161503938/lsi-preboot-efi-packages-for-flashing-lsi-products

Thanks
Rafael

Em ter, 21 de fev de 2017 23:16, david moheban 
escreveu:

> Hi,
>
> Was wondering if there exists an Intel Raid EFI driver that would allow one
> to view the contents of an Intel Raid array within a EFI shell?
>
> Thank you.
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Question about OS initialization at UEFI firmware (x86)

[Rafael Machado]

Thanks a lot guys.

Now things make sense.

Em qui, 5 de jan de 2017 às 11:18, Laszlo Ersek <ler...@redhat.com>
escreveu:

> On 01/05/17 13:16, Alcantara, Paulo wrote:
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Rafael Machado
> >> Sent: quinta-feira, 5 de janeiro de 2017 10:00
> >> To: edk2-devel@lists.01.org
> >> Subject: [edk2] Question about OS initialization at UEFI firmware (x86)
> >>
> >> Hi everyone
> >>
> >> I was taking a look at how the OS boots after the firmware and
> bootloader
> >> are done.
> >>
> >> To understand this I started to take a look at the linux source code,
> and the
> >> strange is that I saw some bios legacy interrupts being called.
> >>
> >> The flow I checked is this:
> >>
> >> void main(void)  -->  linux/arch/x86/boot/main.c
> >>  int detect_memory(void) -->  linux/arch/x86/boot/memory.c
> >>static int detect_memory_e820(void) -->
> >> linux/arch/x86/boot/memory.c
> >>intcall(0x15, , ) -->
> linux/arch/x86/boot/memory.c
> >>
> >>
> >> At the last call the value of ireg is this one:
> >>
> >> ireg.ax  = 0xe820;
> >> ireg.cx  = sizeof buf;
> >> ireg.edx = SMAP;
> >> ireg.di  = (size_t)
> >>
> >>
> >> As we can see this is done so the OS knows the memory map, so the OS can
> >> do all its magic.
> >>
> >> Finally, my question is:
> >>
> >> How could linux, or any other OS, boot on a system with UEFI firmware
> that
> >> does not have CSM (compatibility support module) ?
> >
> > The code you pasted above seems to be executed when booting Linux on
> > PC BIOS firmware. See below.
> >
> >> I consider that some parts of the hypothetical OS need to be written to
> call
> >> some UEFI protocols. Am I right ?
> >
> > As far as I know, there are currently two ways of booting Linux on
> > UEFI firmware:
> >
> > 1) The OS loader (bootloader as a PE/COFF image) uses the EFI handover
> > protocol to boot the Linux kernel image. What the loader does is
> > basically to find the entry point offset (handover_offset) in that
> > image and jump to it. The entry point conforms to ABI defined in UEFI
> > spec.
> >
> > 2) The kernel may be built as PE/COFF binary (UEFI image) so the
> firmware can
> > directly boot it at BDS without any external OS loader.
> >
> > You might want to look at how OVMF boots up Linux through QEMU's
> command-line parameter "-kernel" by using EFI handover protocol.
>
> See also:
>
> https://lwn.net/Articles/632528/
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Improvement at Wiki (EFI_SHELL_INTERFACE)

[Rafael Machado]

Hi everyone

During a a development I faced the following wiki information at
tianocore's github:

https://github.com/tianocore/tianocore.github.io/wiki/Creating-a-Shell-Application#Using_EFI_SHELL_PROTOCOL

I remember a case when I was working with a system that didn't have a
instance of the EFI_SHELL_PARAMETERS_PROTOCOL, and the solution was to use
the EFI_SHELL_INTERFACE protocol, that seems to be a newer protocol to be
used when doing something like what the wiki presents.

I believe it would be nice to update this wiki adding this information.

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Question about OS initialization at UEFI firmware (x86)

[Rafael Machado]

Hi everyone

I was taking a look at how the OS boots after the firmware and bootloader
are done.

To understand this I started to take a look at the linux source code, and
the strange is that I saw some bios legacy interrupts being called.

The flow I checked is this:

void main(void)  -->  linux/arch/x86/boot/main.c
 int detect_memory(void) -->  linux/arch/x86/boot/memory.c
   static int detect_memory_e820(void) -->
linux/arch/x86/boot/memory.c
   intcall(0x15, , ) -->
linux/arch/x86/boot/memory.c


At the last call the value of ireg is this one:

ireg.ax  = 0xe820;
ireg.cx  = sizeof buf;
ireg.edx = SMAP;
ireg.di  = (size_t)


As we can see this is done so the OS knows the memory map, so the OS can do
all its magic.

Finally, my question is:

How could linux, or any other OS, boot on a system with UEFI firmware that
does not have CSM (compatibility support module) ?
I consider that some parts of the hypothetical OS need to be written to
call some UEFI protocols. Am I right ?

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Question about OS initialization at UEFI firmware (x86)

[Rafael Machado]

Hi everyone

I was taking a look at how the OS boots after the firmware and bootloader
are done.

To understand this I started to take a look at the linux source code, and
the strange is that I saw some bios legacy interrupts being called.

The flow I checked is this:

void main(void)  -->  linux/arch/x86/boot/main.c
 int detect_memory(void) -->  linux/arch/x86/boot/memory.c
   static int detect_memory_e820(void) -->
linux/arch/x86/boot/memory.c
   intcall(0x15, , ) -->
linux/arch/x86/boot/memory.c


At the last call the value of ireg is this one:

ireg.ax  = 0xe820;
ireg.cx  = sizeof buf;
ireg.edx = SMAP;
ireg.di  = (size_t)


As we can see this is done so the OS knows the memory map, so the OS can do
all its magic.

Finally, my question is:

How could linux, or any other OS, boot on a system with UEFI firmware that
does not have CSM (compatibility support module) ?
I consider that some parts of the hypothetical OS need to be written to
call some UEFI protocols. Am I right ?

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Accessing I2C GPIO Device

[Rafael Machado]

Hi everyone

I have a platform that has a I2C device connected directly to a processor's
I2C pins.
Now I'm researching the way to send and receive information to this device.

The first idea we had was to use the I2C Protocol Stack, but I'd like to
clarify one point.

After reading the documentation related to the I2C Protocol Stack, seems
this is application just in case the system has a I2C bus were other
devices are connected.

As far as I could understand on out case, since the device is attached
directly to the CPU pins, I understand that the correct wai ti access this
device is using the CPU I/O Protocol.

Is my understanding correct?

In case someone has some details about a scenario like this it would be
really helpful.

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Accessing I2C GPIO Device

[Rafael Machado]

Hi everyone

I have a platform that has a I2C device connected directly to a processor's
I2C pins.
Now I'm researching the way to send and receive information to this device.

The first idea we had was to use the I2C Protocol Stack, but I'd like to
clarify one point.

After reading the documentation related to the I2C Protocol Stack, seems
this is application just in case the system has a I2C bus were other
devices are connected.

As far as I could understand on out case, since the device is attached
directly to the CPU pins, I understand that the correct wai ti access this
device is using the CPU I/O Protocol.

Is my understanding correct?

In case someone has some details about a scenario like this it would be
really helpful.

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Sec and Reset vector

[Rafael Machado]

All the answers were really detailed and I agree with Andrew. These answers
are a great help when we are learning.

Thanks a lot guys. I learn a lot with this community.

Thanks and regards
Rafael

Em sex, 4 de nov de 2016 19:28, Kinney, Michael D <
michael.d.kin...@intel.com> escreveu:

> Rafael,
>
> The first instruction executed for IA32 SEC phase is typically 16-bytes
> from
> the end of the Firmware Device (FD) image generated by a build.
>
> If you look at QuarkPlatformPkg/Quark.dsc as an example build, it generates
> an 8MB  file called Quark.FD.  The reset vector is 16-bytes from the end of
> that file.  The reset vector and rest of SEC code are all in a special FFS
> file
> known at the Volume Top File(VFT).
>
> The source code for the reset vector is in the file:
>
> UefiCpuPkg/SecCore/Ia32/ResetVector.nasmb
>
> This source file contains the code that fills the last 0x40 bytes of the
> VTF
> which is also the last 0x40 bytes of Quark.FD.
>
> The build tools do some special fixups on this file, so 16-bit relative JMP
> instruction at line 79 is fixed up to jump to the symbol _ModuleEntryPoint.
>
> ResetHandler:
> nop
> nop
> ApStartup:
> ;
> ; Jmp Rel16 instruction
> ; Use machine code directly in case of the assembler
> optimization
> ; SEC entry point relative address will be fixed up by some
> build tool.
> ;
> ; Typically, SEC entry point is the function
> _ModuleEntryPoint() defined in
> ; SecEntry.asm
> ;
> DB  0e9h
> DW  -3
>
> For Quark.FD, _ModuleEntryPoint is from the PlatformSecLib library at:
>
> QuarkPlatformPkg/Library/PlatformSecLib
>
> Specifically Line l5 of the file:
>
> QuarkPlatformPkg/Library/PlatformSecLib/Ia32/Flat32.asm
>
> _ModuleEntryEntryPoint starts in 16-bit real mode and transitions to
> 32-bit protected mode, initializes ESRAM to be used as a stack, and
> transfers control to the C function PlatformSecLibStartup() at line 220.
> The goal is to minimize the amount of assembly code and get into C code
> as quickly as possible.
>
> The PlatformSecLibStartup() function implementation is in the same
> PlatformSecLib library at line 68 of the file:
>
> QuarkPlatformPkg/Library/PlatformSecLib/PlatformSecLib.c
>
> Best regards,
>
> Mike
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Rafael Machado
> > Sent: Friday, November 4, 2016 12:34 PM
> > To: Andrew Fish <af...@apple.com>
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] Sec and Reset vector
> >
> > Hi Andrew
> >
> > Maybe my question was not clear.
> > But thanks for the information you provided.
> >
> > I think we can simplify what I need based on your last comment. You told:
> >
> > *"The .com file contains the hardware real mode reset vector
> (0xFFF0).
> > So execution starts up high. The 1st far jmp you do gets you running in
> the
> > 0x000F range (the ROM is aliased to the old PC address)"*
> >
> > How could I find the .com file inside the dump of a bios (I have used
> > DediProg to get the dump)?
> > I'm hunting the first far jump the firmware has.
> >
> > Thanks
> > Rafael
> >
> > Em sex, 4 de nov de 2016 às 16:50, Andrew Fish <af...@apple.com>
> escreveu:
> >
> > > On Nov 4, 2016, at 10:48 AM, Rafael Machado <
> > > rafaelrodrigues.mach...@gmail.com> wrote:
> > >
> > > Hi everyone
> > >
> > > Thanks Andrew and Marvin for the clarification.
> > > Now things start to make sense.
> > >
> > > But I was still not able to understand were things start on a real
> binary
> > >
> > >
> > > Rafeal,
> > >
> > > I'm not sure what you are asking?
> > >
> > > The .com file contains the hardware real mode reset vector
> (0xFFF0).
> > > So execution starts up high. The 1st far jmp you do gets you running
> in the
> > > 0x000F range (the ROM is aliased to the old PC address). The .com
> file
> > > is patched with the entry point of the PE/COFF (or TE) .efi and just
> jumps
> > > into that code. At some point early in the processes the code
> transitions
> > > to protected mode and starts executing up high again (only a small
> part of
> > > the ROM is aliased down low).
> > >
> > > The SEC PE/COFF  (

Re: [edk2] Sec and Reset vector

[Rafael Machado]

Hi Andrew

Maybe my question was not clear.
But thanks for the information you provided.

I think we can simplify what I need based on your last comment. You told:

*"The .com file contains the hardware real mode reset vector (0xFFF0).
So execution starts up high. The 1st far jmp you do gets you running in the
0x000F range (the ROM is aliased to the old PC address)"*

How could I find the .com file inside the dump of a bios (I have used
DediProg to get the dump)?
I'm hunting the first far jump the firmware has.

Thanks
Rafael

Em sex, 4 de nov de 2016 às 16:50, Andrew Fish <af...@apple.com> escreveu:

> On Nov 4, 2016, at 10:48 AM, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
>
> Hi everyone
>
> Thanks Andrew and Marvin for the clarification.
> Now things start to make sense.
>
> But I was still not able to understand were things start on a real binary
>
>
> Rafeal,
>
> I'm not sure what you are asking?
>
> The .com file contains the hardware real mode reset vector (0xFFF0).
> So execution starts up high. The 1st far jmp you do gets you running in the
> 0x000F range (the ROM is aliased to the old PC address). The .com file
> is patched with the entry point of the PE/COFF (or TE) .efi and just jumps
> into that code. At some point early in the processes the code transitions
> to protected mode and starts executing up high again (only a small part of
> the ROM is aliased down low).
>
> The SEC PE/COFF  (or TE) .efi image entry point can be found in the
> PE/COFF (or TE) header that is part of that image. This is how the PEI Core
> passes control to PEIMs, and it is also what the PEI/DXE/SMM cores use to
> pass control to images that are loaded into memory.
>
> There is a library that given a PE/COFF or TE image will return the entry
> point.
>
>
> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c#L44
> RETURN_STATUS
> EFIAPI
> PeCoffLoaderGetEntryPoint (
> IN VOID *Pe32Data,
> OUT VOID **EntryPoint
> )
> {
> EFI_IMAGE_DOS_HEADER *DosHdr;
> EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION Hdr;
> ASSERT (Pe32Data != NULL);
> ASSERT (EntryPoint != NULL);
> DosHdr = (EFI_IMAGE_DOS_HEADER *)Pe32Data;
> if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE) {
> //
> // DOS image header is present, so read the PE header after the DOS image
> header.
> //
> Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)((UINTN) Pe32Data + (UINTN)
> ((DosHdr->e_lfanew) & 0x0));
> } else {
> //
> // DOS image header is not present, so PE header is at the image base.
> //
> Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)Pe32Data;
> }
> //
> // Calculate the entry point relative to the start of the image.
> // AddressOfEntryPoint is common for PE32 & PE32+
> //
> if (Hdr.Te->Signature == EFI_TE_IMAGE_HEADER_SIGNATURE) {
> *EntryPoint = (VOID *)((UINTN)Pe32Data + (UINTN)(Hdr.Te->AddressOfEntryPoint
> & 0x0) + sizeof(EFI_TE_IMAGE_HEADER) - Hdr.Te->StrippedSize);
> return RETURN_SUCCESS;
> } else if (Hdr.Pe32->Signature == EFI_IMAGE_NT_SIGNATURE) {
> *EntryPoint = (VOID *)((UINTN)Pe32Data + (UINTN)(Hdr.Pe32->OptionalHeader.
> AddressOfEntryPoint & 0x0));
> return RETURN_SUCCESS;
> }
> return RETURN_UNSUPPORTED;
> }
>
>
> Thanks,
>
> Andrew Fish
>
> On the attached image ResetVectorCoreboot.png we have the entry point on a
> coreboot image.
> What I would like to do is to find something similar to this on a UEFI Bios
> image.
>
> Based on Marvin's idea, I got the UEFI Tool and star to check the image I
> have.
> On the attached image TopFileInfo.png we can see to Top File mentioned by
> Andrew.
> The details about the Top File are these:
>
>  Offset: FF8018h
>
>  File GUID: 1BA0062E-C779-4582-8566-336AE8F78F09
>
>  Type: 03h
>
>  Attributes: 08h
>
>  Full size: 7FE8h (32744)
>
>  Header size: 18h (24)
>
>  Body size: 7FD0h (32720)
>
>  Tail size: 0h (0)
>
>  State: F8h
>
>  Header checksum: 99h, valid
>
>  Data checksum: AAh, valid
>
>  Header memory address: 8018h
>
>  Data memory address: 8030h
>
>  Compressed: No
>
>  Fixed: No
>
>
> I tried to find something similar to what I see at the coreboot image, but
> didn't find anything. Neither on the PE Image section, not on the Raw image
> sections.
>
>
> Any idea about how could I find the entry point of sec in this case?
>
> Thanks and Regards
> Rafael R. Machado
>
>
> Em sáb, 22 de out de 2016 às 16:19, Andrew Fish <af...@apple.com>
> escreveu:
>
> On Oct 22, 2016, at 10:03 AM, Marvin H?user <marvin.haeu...@outlook.com>
> wrote:
&

Re: [edk2] Sec and Reset vector

[Rafael Machado]

One additional information.
I checked the code mentioned by Andrew, and at the code things make sense.

Now I'd like to see that kind of initial code at the final binary.

Thanks
Rafael

Em sex, 4 de nov de 2016 às 15:48, Rafael Machado <
rafaelrodrigues.mach...@gmail.com> escreveu:

> Hi everyone
>
> Thanks Andrew and Marvin for the clarification.
> Now things start to make sense.
>
> But I was still not able to understand were things start on a real binary
> On the attached image ResetVectorCoreboot.png we have the entry point on a
> coreboot image.
> What I would like to do is to find something similar to this on a UEFI
> Bios image.
>
> Based on Marvin's idea, I got the UEFI Tool and star to check the image I
> have.
> On the attached image TopFileInfo.png we can see to Top File mentioned by
> Andrew.
> The details about the Top File are these:
>
>   Offset: FF8018h
>
>   File GUID: 1BA0062E-C779-4582-8566-336AE8F78F09
>
>   Type: 03h
>
>   Attributes: 08h
>
>   Full size: 7FE8h (32744)
>
>   Header size: 18h (24)
>
>   Body size: 7FD0h (32720)
>
>   Tail size: 0h (0)
>
>   State: F8h
>
>   Header checksum: 99h, valid
>
>   Data checksum: AAh, valid
>
>   Header memory address: 8018h
>
>   Data memory address: 8030h
>
>   Compressed: No
>
>   Fixed: No
>
>
> I tried to find something similar to what I see at the coreboot image, but
> didn't find anything. Neither on the PE Image section, not on the Raw image
> sections.
>
>
> Any idea about how could I find the entry point of sec in this case?
>
> Thanks and Regards
> Rafael R. Machado
>
>
> Em sáb, 22 de out de 2016 às 16:19, Andrew Fish <af...@apple.com>
> escreveu:
>
> On Oct 22, 2016, at 10:03 AM, Marvin H?user <marvin.haeu...@outlook.com>
> wrote:
>
> Hey Rafael,
>
> There actually is some generic SEC code in UefiCpuPkg you might want to
> take a look at. It's generic because it does not have "Intel NDA" code,
> such as CAR (Cache-As-RAM) etc.
> The Reset Vector may or may not be part of SecCore. It's either embedded
> within the SecCore module, or a separate file in the FFS. You can check the
> start/end address of the modules (e.g. with UEFITool) and find the Reset
> Vector file that way.
>
>
> Rafael,
>
> There is some strange construction things going on with the SEC for X86.
>
> If you look in the FDF file you will see that the SEC is a PE/COFF (or TE)
> image and a raw binary for the 16-bit real mode reset vector code.
>
>
> https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L876
> [Rule.Common.SEC]
> FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
> PE32 PE32 Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi
> RAW BIN Align = 16 |.com
> }
>
> The .com files are constructed from *.nasmb, *.asm16, or *.S16 files.
> https://github.com/tianocore/edk2/tree/master/UefiCpuPkg/SecCore/Ia32
>
> Special extensions are needed to have special build rules. The build rules
> are here:
>
> https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template#L480
> Look at the [Masm16-Code-File] and [Nasm-to-Binary-Code-File] rules.
>
> The build tools also do some magic to stitch the .com and PE/COFF (TE)
> file together.
>
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb#L46
> ;
> ; Pointer to the entry point of the PEI core
> ; It is located at 0xFFE0, and is fixed up by some build tool
> ; So if the value 8..1 appears in the final FD image, tool failure occurs.
> ;
> PeiCoreEntryPoint: DD 87654321h
>
>
> The reason you need special build rules is it is really hard to get code
> at the end of a PE/COFF file, so you need a stripped binary for the reset
> vector.
>
> The next problem is how do you get the FV File to be at the end of the FV
> (that is usually free space). The PI spec defines that if an FFS file has
> the File GUID of gEfiFirmwareVolumeTopFileGuid then it gets place at the
> end of the FV. Thus the X86 SEC must have this file guid. This also
> triggers the magic behavior to stitch the .com and PE/COFF together.
>
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/SecCore.inf#L25
> FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
>
>
>
> For ARM things are much simpler. The FV reserves 16-bytes at the start of
> the volume for the reset vector. If the build tools see an FV has an ARM
> SEC it can patch in a branch to the SEC PE/COFF (TE) entry point (going
> from memory hopefully I did not botch that).
>
>
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L110
> ///
> /// The fi

[edk2] Sec and Reset vector

[Rafael Machado]

Hi eveyrone

I'm doing some studies on edk2 and coreboot, but I'm having some questions
that I believe you can help.

On the journey to try to understand things since the beginning, so they
make sense in future, I'm trying to understand how does the Initial phases
of UEFI  / PI firmware work. To do that I got a bios image and start to
reverse it to check the modules and everything present at that bios. Now I
understand, at least the basics, about DXE and PEI phase.

The main question that I have now is about the SEC phase.
To try to understand the SEC phase I tried to reverse this firmware so I
could check the reset vector's first jump or something like that.
The surprise I have is that I was not able to find this code.

To be sure I was reversing on the correct way I generated a coreboot image.
On the image below we can see the initial code of a firmware generated
using coreboot

[image: pasted1]

But at the UEFI firmware I'm studying I'm not able to find anything similar
to that.
My guess before starting this was that at least the SEC initial code should
be similar to the legacy way of doing things, a jmp at 0xfff:fff0
and after that the magic should get started with all uefi phases.

Could someone please give me some light on that?


Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Sending command to SAS devices

[Rafael Machado]

Hi everyone

I'm trying to send a command to a SAS (serial attached scsi) storage device
to retrieve some SMART information, but I'm facing some problems that maybe
you can give me some light.

During a research about how does the SAS devices work I faced this
specification: http://www.t10.org/members/w_sat4.htm.
My hope was to have a SCSI or ATA protocol attached to this device /
controller, so I could create a SAT library and would be able to end a ATA
command over the SCSI protocol, or a SCSI command over a ATA protocol (not
sure about the correct option yet).

After checking the handles created on this device I had a terrible surprise.
No ATA_PASS_THRU protocol instance was created to it, and no
SCSI_EXT_PASS_THRU protocol instance was created too.

My questions are:

Does anyone ever worked with SAS devices and had success with it?
In case I really need to do that, seems I would need to create a SAS
controller driver so I could send the command to the correct device. Am I
right about this?
Any other idea?

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Ingebrigtsen: The End of Gmane?

[Rafael Machado]

Nice!!!

Em ter, 6 de set de 2016 às 13:20, Bruce Cran  escreveu:

> On 9/6/16 3:25 AM, Laszlo Ersek wrote:
>
> > The gmane web interface is gone, and I'm unaware of anyone who has
> > picked up the archive and exposed it under the same URLs (via domain
> > name transfer etc). So, at the moment (to my knowledge) all our
> > historical gmane links are broken. Neither do I know how someone could
> > access edk2-devel messages that predate Mike's enablement of the
> > built-in  archive.
>
> As of today, it seems a reboot is underway:
> http://home.gmane.org/2016/09/06/reboot-v1/
>
> "I just re-enabled some of the URLs and traffic is flowing.
>
> This rebuild is going to require an ongoing effort to bring it back to
> its former glory but we will get there shortly."
>
> --
> Bruce
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Ingebrigtsen: The End of Gmane?

[Rafael Machado]

Hi Laszlo.

Thanks for the answer, even being terrible news.
The archive helped me a lot to solve several situations in the past.

We know how this kind of information is important for the community.
Hope someone could give us some light on that.

Not sure if I can help to solve this, in case there is something I can do
let me know.

Rafael R. Machado

Em ter, 6 de set de 2016 às 06:25, Laszlo Ersek <ler...@redhat.com>
escreveu:

> On 09/05/16 19:51, Rafael Machado wrote:
> > Hi everyone.
> >
> > Sorry for the possibly stupid question, maybe I lose something. Did we
> > get to a conclusion about this?
> > I tried to access the link https://lists.01.org/pipermail/edk2-devel/
> > but didn't find to much information. Just e-mails from 3 moths ago.
>
> The gmane web interface is gone, and I'm unaware of anyone who has
> picked up the archive and exposed it under the same URLs (via domain
> name transfer etc). So, at the moment (to my knowledge) all our
> historical gmane links are broken. Neither do I know how someone could
> access edk2-devel messages that predate Mike's enablement of the
> built-in <https://lists.01.org/pipermail/edk2-devel/> archive.
>
> Sorry :(
> Laszlo
>
> > Em seg, 1 de ago de 2016 às 10:25, Laszlo Ersek <ler...@redhat.com
> > <mailto:ler...@redhat.com>> escreveu:
> >
> > On 07/31/16 04:25, Bruce Cran wrote:
> > > On 7/28/2016 1:19 PM, Andrew Fish wrote:
> > >
> > >> Seems he will send you the disks. What could go wrong?
> > >
> > > I'm actually tempted to take him up on that offer.
> > > Just today I went looking for information about UefiDebugLib to
> see if
> > > it was possible for a driver to print debug information to the
> serial
> > > port (or other sort of debug device) instead of the console, and
> came
> > > across the thread at
> > > http://comments.gmane.org/gmane.comp.bios.tianocore.devel/3024
> where
> > > thanks to Google's cache I learned that:
> > >
> > > "The EDK used some Tiano and implementation defined protocols to
> > support
> > > DEBUG and ASSERT macros. So DEBUG
> > > and ASSERT from the EDK can only be reliably used if you compile
> > all the
> > > EDK firmware together. As Liming
> > > points out it is much safer to use a UEFI console based debug
> message
> > > for developing generic drivers and
> > > applications."
> > >
> > > It's a shame to lose information like that.
> >
> > I think the Internet Archive intends to pick up the DB + WebUI:
> >
> >
> https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13501
> >
> > Also, from Lars Ingebrigtsen (speaking to a yet to be determined
> > entity):
> >
> > "I hand over the gmane.org <http://gmane.org> domain to you [...]
> > All previous
> > permalink.gmane.org <http://permalink.gmane.org> (etc.) links
> > continue to work as before, but they’ll
> > look new and spiffy in your new and spiffy web interface."
> >
> >
> https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
> >
> > (Actually, I'm a huge fan of the current (oldie but goldie) WebUI, so
> > "new and spiffy" is a minus for me, but at least the links should
> > continue to work.)
> >
> > Going forward I'll have to constrain myself to the builtin mailman2
> > links at <https://lists.01.org/pipermail/edk2-devel/>. (Thanks again
> > Bruce and Mike for enabling those.)
> >
> > Thanks
> > Laszlo
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> >
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Ingebrigtsen: The End of Gmane?

[Rafael Machado]

Hi everyone.

Sorry for the possibly stupid question, maybe I lose something. Did we get
to a conclusion about this?
I tried to access the link https://lists.01.org/pipermail/edk2-devel/
but didn't find to much information. Just e-mails from 3 moths ago.

Thanks
Rafael R. Machado

Em seg, 1 de ago de 2016 às 10:25, Laszlo Ersek 
escreveu:

> On 07/31/16 04:25, Bruce Cran wrote:
> > On 7/28/2016 1:19 PM, Andrew Fish wrote:
> >
> >> Seems he will send you the disks. What could go wrong?
> >
> > I'm actually tempted to take him up on that offer.
> > Just today I went looking for information about UefiDebugLib to see if
> > it was possible for a driver to print debug information to the serial
> > port (or other sort of debug device) instead of the console, and came
> > across the thread at
> > http://comments.gmane.org/gmane.comp.bios.tianocore.devel/3024 where
> > thanks to Google's cache I learned that:
> >
> > "The EDK used some Tiano and implementation defined protocols to support
> > DEBUG and ASSERT macros. So DEBUG
> > and ASSERT from the EDK can only be reliably used if you compile all the
> > EDK firmware together. As Liming
> > points out it is much safer to use a UEFI console based debug message
> > for developing generic drivers and
> > applications."
> >
> > It's a shame to lose information like that.
>
> I think the Internet Archive intends to pick up the DB + WebUI:
>
>
> https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13501
>
> Also, from Lars Ingebrigtsen (speaking to a yet to be determined entity):
>
> "I hand over the gmane.org domain to you [...] All previous
> permalink.gmane.org (etc.) links continue to work as before, but they’ll
> look new and spiffy in your new and spiffy web interface."
>
>
> https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
>
> (Actually, I'm a huge fan of the current (oldie but goldie) WebUI, so
> "new and spiffy" is a minus for me, but at least the links should
> continue to work.)
>
> Going forward I'll have to constrain myself to the builtin mailman2
> links at . (Thanks again
> Bruce and Mike for enabling those.)
>
> Thanks
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Memory Consumption after BLT (GOP)

[Rafael Machado]

Thanks guys. Andrew and Aaron especially.

Now things make sense!!

Rafael R. Machado


Em qui, 2 de jun de 2016 às 13:40, <aaron@congatec.com> escreveu:

> Hi Rafael,
>
> The short answer is that no, once pages of memory are converted from
> available to another type, they will never be converted back to available,
> and this is as intended.
>
> The long answer is complex. Firmware is, at its most basic level, meant to
> initialize hardware and give control to an operating system. There are
> multiple goals the firmware wants to achieve as part of this. It wants to
> deterministic (the next boot wants to be as close to this boot as possible
> in the order of drivers run, the amout of memory consumed, the memory
> fragmentation, etc) . To keep the memory footprint to a minimum and the
> memory fragmentation to a minimum, the EDK2 creates memory bins for each
> type of memory that is defined in the specification. These memory bins are
> meant to prevent memory fragmentation (and thus reduce the number of memory
> map entries, E820 entries, etc, etc).  The amount of memory required for
> each memory type is tracked in the EDK2 and saved so that when memory is
> discovered, the amount of each memory type will be allocated in contiguous
> chunks, and that these chunks will be large enough to accommodate all
> allocations for the rest of the boot process.
>
> So in this case, when you boot to Shell, you have essentially completed
> the end of the firmware process and the system has uefi booted. The Boot
> Services are still available, and you can allocate memory, etc, but the
> deterministic portion of the boot process has completed.  Any of your
> interactions, allocations, etc, are outside of the known amount memory that
> was used in previous boots, which will cause available memory to be
> converted to boot services memory.
>
> Also keep in mind that since the firmware's goal is to transfer control to
> an operating system, and that when the operating system calls exit boot
> services, all boot services memory used by the firmware is abandoned.
> After its abandoned, it becomes available for the operating system to use,
> so the changes in the memory map's boot services have no effect.
>
> I hope this helps clarify your questions.
>
>
>
>
>
> From:Rafael Machado <rafaelrodrigues.mach...@gmail.com>
> To:aaron@congatec.com
> Cc:"Carsey, Jaben" <jaben.car...@intel.com>, "
> edk2-devel@lists.01.org" <edk2-devel@lists.01.org>, edk2-devel <
> edk2-devel-boun...@lists.01.org>, Andrew Fish <af...@apple.com>
> Date:06/02/2016 05:49 AM
> Subject:Re: [edk2] Memory Consumption after BLT (GOP)
> Sent by:"edk2-devel" <edk2-devel-boun...@lists.01.org>
> --
>
>
>
> Hi everyone / Aaron
>
> I was studying Aaron's message to be sure I got everything he explained.
> Now I have just one last question.
>
> You mentioned that the calls to LocateHandleBuffer, AllocatePool and
> GOP->BLT change some memory types and allocate them.
> I can confirm that this is exactly what happens. Before the memory is
> decreased I have this map from the memmap uefi shell command:
>
>   available  64059000-64086FFF  002E
> 000F
>
>   BS_data   :  10,774 Pages (44,130,304)
>   available : 407,183 Pages (1,667,821,568)
>
> And after some executions I have this map:
>
>   available  64059000-64085FFF  002D
> 000F
>   BS_data64086000-64086FFF  0001
> 000F
>
>   BS_data   :  10,775 Pages (44,134,400)
>   available : 407,182 Pages (1,667,817,472)
>
> Now my question is.
> After my function is done shouldn't the memory that was converted to
> BS_Data, and that was released, go back to the "available memory" memory
> type ? Since this is not happening seems there is some leak at some place.
> I did a test executing the application 10k times, and BS_Data keeps
> increasing and available keeps decreasing.
>
> At the and the result is:
>
>  LoaderData:  26 Pages (106,496)
>  BS_data   :  14,201 Pages (58,167,296)
>  available : 403,755 Pages (1,653,780,480)
>
>
> Just one additional information. Some memory was stolen from LoaderData
> memory type. It was bigger at the first execution:
>
>  LoaderData: 649 Pages (2,658,304)
>
>
> Any comments are well received.
>
> Thanks and regards
> Rafael R. Machado
>
>
> Em qua, 1 de jun de 2016 às 16:52, Rafael Machado <
&

Re: [edk2] Memory Consumption after BLT (GOP)

[Rafael Machado]

Hi everyone / Aaron

I was studying Aaron's message to be sure I got everything he explained.
Now I have just one last question.

You mentioned that the calls to LocateHandleBuffer, AllocatePool and
GOP->BLT change some memory types and allocate them.
I can confirm that this is exactly what happens. Before the memory is
decreased I have this map from the memmap uefi shell command:

   available  64059000-64086FFF  002E
000F

   BS_data   :  10,774 Pages (44,130,304)
   available : 407,183 Pages (1,667,821,568)

And after some executions I have this map:

   available  64059000-64085FFF  002D
000F
   BS_data64086000-64086FFF  0001
000F

   BS_data   :  10,775 Pages (44,134,400)
   available : 407,182 Pages (1,667,817,472)

Now my question is.
After my function is done shouldn't the memory that was converted to
BS_Data, and that was released, go back to the "available memory" memory
type ? Since this is not happening seems there is some leak at some place.
I did a test executing the application 10k times, and BS_Data keeps
increasing and available keeps decreasing.

At the and the result is:

  LoaderData:  26 Pages (106,496)
  BS_data   :  14,201 Pages (58,167,296)
  available : 403,755 Pages (1,653,780,480)


Just one additional information. Some memory was stolen from LoaderData
memory type. It was bigger at the first execution:

  LoaderData: 649 Pages (2,658,304)


Any comments are well received.

Thanks and regards
Rafael R. Machado


Em qua, 1 de jun de 2016 às 16:52, Rafael Machado <
rafaelrodrigues.mach...@gmail.com> escreveu:

> Amazing explanation Aaron!!
> Thanks a lot!!
>
> Rafael R. Machado
>
> Em qua, 1 de jun de 2016 às 15:29, <aaron@congatec.com> escreveu:
>
>> Hi Rafael,
>>
>> I think your application is exposing some of the rough edges of the EDK2
>> memory allocation routines.
>>
>> Your application is calling allocatepool for boot servies data. It is
>> first doing this to get a handle buffer of GOP devices, then it is doing
>> this to create a Blt buffer.
>>
>> Your application does free this memory, but once you understand how the
>> internals of the edk2 memory allocation work, the behavior is as expected.
>> e
>> When you call allocate pool, if the amount of memory that you are trying
>> to allocate is greater than a page then the edk2 will round the amount of
>> memory that you are requesting up to the next page and just allocate pages
>> of memory to you.
>>
>> If you call allocate pool, and the amount of memory you are trying to
>> allocate is less than a page of memory, the edk2 will look at the current
>> sets of memory that are of the type you are trying to allocate
>> (EfiBootServicesData in your case).  If it can find an available amount of
>> memory in its previously allocated pages, it will return that memory to
>> you.  If it cannot find that amount of memory, it will convert available
>> pages of memory into the type of memory and give that to you.
>>
>> If your example code's case, you allocate for a handle buffer, then you
>> allocate for a gop blt buffer, then you call blt (which may perform memory
>> allocations too).  In all of this, you may have exhausted the amount of
>> BootServicesData pages that were currently available and caused the system
>> to convert available memory into Boot Services Data memory.
>>
>> I hope this helps explain the behavior that you are seeing.
>>
>>
>>
>>
>> From:Andrew Fish <af...@apple.com>
>> To:Rafael Machado <rafaelrodrigues.mach...@gmail.com>
>> Cc:"Carsey, Jaben" <jaben.car...@intel.com>, "
>> edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
>> Date:06/01/2016 11:16 AM
>> Subject:Re: [edk2] Memory Consumption after BLT (GOP)
>> Sent by:"edk2-devel" <edk2-devel-boun...@lists.01.org>
>> --
>>
>>
>>
>>
>> > On Jun 1, 2016, at 11:10 AM, Rafael Machado <
>> rafaelrodrigues.mach...@gmail.com> wrote:
>> >
>> > The draw application is this one:
>> >
>>
>> Yikes that is hard for me to read without indentation
>>
>> Why don't you try putting some of the GraphicProtocol calls in a loop to
>> see if that leaks more memory?
>>
>> Thanks,
>>
>> Andrew Fish
>>
>> > #include 
>> > #include 
>> > #include 
>> >

Re: [edk2] Memory Consumption after BLT (GOP)

[Rafael Machado]

I did that :)

To get the available memory I did the following function:

EFI_STATUS CalculateAvaiableMemoryForDebug (VOID)
{

  EFI_STATUS Status = EFI_SUCCESS;
  EFI_MEMORY_DESCRIPTOR *MemMap = NULL;
  EFI_MEMORY_DESCRIPTOR *Desc;
  UINTN DescriptorSize = 0;
  UINT32 DescriptorVersion = 0; UINTN MapKey;
  UINTN MemMapSize = sizeof(EFI_MEMORY_DESCRIPTOR);
  UINTN Index = 0;
  UINTN NoDesc = 0;


  UINTN TotalOfPages = 0;
  UINTN TotalOfFreePages = 0;
  UINTN TotalOfBlocks= 0;
  UINTN CurrentBlock = 0;



  if (MemMap != NULL) {
  FreePool(MemMap);
  }

  Status = gBS->AllocatePool(EfiBootServicesData,
 MemMapSize,
 (VOID**));

  if (Status == EFI_SUCCESS) {
Status = gBS->GetMemoryMap(,
   MemMap,
   ,
   ,
   );
  } else {
Status = EFI_DEVICE_ERROR;
  }

  if (Status == EFI_SUCCESS) {

CurrentBlock = 1;
Desc = MemMap;
NoDesc = MemMapSize / DescriptorSize;

for(Index = 0; Index < NoDesc; Index++) {

  if (Desc->Type == EfiConventionalMemory) {
TotalOfFreePages += (UINTN) Desc->NumberOfPages;
TotalOfBlocks++;
  }

  TotalOfPages += (UINTN) Desc->NumberOfPages;

  Desc = NextMemoryDescriptor (Desc, DescriptorSize);
}

  } else {
Status = EFI_DEVICE_ERROR;
  }

  if (MemMap != NULL) {
  FreePool(MemMap);
  }

  DEBUG_LOG(DbgFileModeMemoryAvailable,
 DEBUG_LEVEL_DUMP,
 L"-Available Pages: %ld \n",
 TotalOfFreePages);


  return Status;
}

The available memory also decreases in this case.
I didn't find any leak at this function too.

I'm considering some problem with other driver that is causing this
memory decrease during the execution time.

Thanks
Rafael R. Machado

Em qua, 1 de jun de 2016 às 14:53, Carsey, Jaben <jaben.car...@intel.com>
escreveu:

> Well... sadly the best way to debug would be to get the memory map
> yourself, run your graphical operation, and then compare all inside the
> same program (assuming that you allocate no memory within your memory map
> acquisitions).
>
> -Jaben
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Rafael Machado
> > Sent: Wednesday, June 01, 2016 10:33 AM
> > To: Carsey, Jaben <jaben.car...@intel.com>
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] Memory Consumption after BLT (GOP)
> > Importance: High
> >
> > The system has one page decreased after some executions.
> > I used the following script to check this:
> >
> > FS1:
> > echo -off
> > memmap >> memmapShellBefore.txt
> > for %a run (1 10)
> >  TestesImagemBMP.efi
> >  memmap >> memmapShellAfter_%a.txt
> > endfor
> >
> > The decrease happened at execution number 4 and 9
> > From execution 1 to 2, and 2 to 3  no decrease was detected. The same
> with
> > execution 4 to 5, 5 to 6 6 to 7 and 7 to 8
> >
> > I thought that since I'm using the script no command log was saved by the
> > shell application.
> > At the begin I added a echo -off to avoid scroll.
> >
> >
> > Thanks and Regards
> > Rafael R. Machado
> >
> > Em qua, 1 de jun de 2016 às 14:13, Carsey, Jaben <jaben.car...@intel.com
> >
> > escreveu:
> >
> > > Does the pattern continue or level off after time?
> > >
> > > I ask as the shell will make some allocations to save things like
> command
> > > history and output history for up/down page up/page down support...
> > >
> > > -Jaben
> > >
> > > > On Jun 1, 2016, at 10:10 AM, Rafael Machado <
> > > rafaelrodrigues.mach...@gmail.com> wrote:
> > > >
> > > > Hi Everyone.
> > > >
> > > > I'm doing some tests related to the GOP and graphical applications.
> > > > What I've seeing is that after calling the GOP->BLT several times the
> > > > available memory from the system decrease.
> > > >
> > > > For example. When the system just boot I have the following at the
> uefi
> > > > shell memmap command:
> > > >
> > > >  reserved  : 124 Pages (507,904)
> > > >  LoaderCode: 186 Pages (761,856)
> > > >  LoaderData:  24 Pages (98,304)
> > > >  BS_code   :   1,719 Pages (7,041,024)
> > > >  BS_data   :  10,774 Pages (44,130,304)
> > > >  RT_code   : 256 Pages (1,048,576)
> > > >  RT_data   : 660 Pages (2,703,360)
> > > >  *available 

Re: [edk2] Memory Consumption after BLT (GOP)

[Rafael Machado]

The system has one page decreased after some executions.
I used the following script to check this:

FS1:
echo -off
memmap >> memmapShellBefore.txt
for %a run (1 10)
 TestesImagemBMP.efi
 memmap >> memmapShellAfter_%a.txt
endfor

The decrease happened at execution number 4 and 9
From execution 1 to 2, and 2 to 3  no decrease was detected. The same with
execution 4 to 5, 5 to 6 6 to 7 and 7 to 8

I thought that since I'm using the script no command log was saved by the
shell application.
At the begin I added a echo -off to avoid scroll.


Thanks and Regards
Rafael R. Machado

Em qua, 1 de jun de 2016 às 14:13, Carsey, Jaben <jaben.car...@intel.com>
escreveu:

> Does the pattern continue or level off after time?
>
> I ask as the shell will make some allocations to save things like command
> history and output history for up/down page up/page down support...
>
> -Jaben
>
> > On Jun 1, 2016, at 10:10 AM, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
> >
> > Hi Everyone.
> >
> > I'm doing some tests related to the GOP and graphical applications.
> > What I've seeing is that after calling the GOP->BLT several times the
> > available memory from the system decrease.
> >
> > For example. When the system just boot I have the following at the uefi
> > shell memmap command:
> >
> >  reserved  : 124 Pages (507,904)
> >  LoaderCode: 186 Pages (761,856)
> >  LoaderData:  24 Pages (98,304)
> >  BS_code   :   1,719 Pages (7,041,024)
> >  BS_data   :  10,774 Pages (44,130,304)
> >  RT_code   : 256 Pages (1,048,576)
> >  RT_data   : 660 Pages (2,703,360)
> >  *available : 407,184 Pages (1,667,825,664)*
> >  ACPI_recl :  96 Pages (393,216)
> >  ACPI_NVS  : 129 Pages (528,384)
> >  MemMapIO  :   1 Pages (4,096)
> > Total Memory: 1,644 MB (1,724,530,688) Bytes
> >
> > After executing a sample application that just draw a white box 10
> times, I
> > have the following:
> >
> >  reserved  : 124 Pages (507,904)
> >  LoaderCode: 186 Pages (761,856)
> >  LoaderData:  24 Pages (98,304)
> >  BS_code   :   1,719 Pages (7,041,024)
> >  BS_data   :  10,776 Pages (44,138,496)
> >  RT_code   : 256 Pages (1,048,576)
> >  RT_data   : 660 Pages (2,703,360)
> > * available : 407,182 Pages (1,667,817,472)*
> >  ACPI_recl :  96 Pages (393,216)
> >  ACPI_NVS  : 129 Pages (528,384)
> >  MemMapIO  :   1 Pages (4,096)
> > Total Memory: 1,644 MB (1,724,530,688) Bytes
> >
> >
> > So the situation is that on a Graphical UEFI application, there is a
> > possibility of getting too much memory.
> > As much as I execute the application the available memory keeps
> decreasing.
> >
> > Could someone please help me to find some problem on the sample
> application
> > code ?
> >
> > "
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> >
> > #define BoxWidth 100
> > #define BoxHeight 100
> >
> > EFI_STATUS PrintImage(EFI_HANDLE ImageHandle, UINTN ImagePositionX, UINTN
> > ImagePositionY){
> >
> > UINTN Size;
> > EFI_STATUS Status;
> > UINTN HandleIndex = 0;
> > EFI_HANDLE *HandleArray = NULL;
> > EFI_GRAPHICS_OUTPUT_PROTOCOL *GraphicProtocol = NULL;
> > EFI_GUID gGraphicalProtocol = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
> > EFI_GUID gEdidActivated = EFI_EDID_ACTIVE_PROTOCOL_GUID;
> > EFI_EDID_ACTIVE_PROTOCOL *EdidActivated = NULL;
> > EFI_GRAPHICS_OUTPUT_BLT_PIXEL* inMemoryImage = NULL;
> >
> > Status = gBS->LocateHandleBuffer(ByProtocol,
> > ,
> > NULL,
> > ,
> > );
> >
> > if(!EFI_ERROR(Status))
> > {
> > for(HandleIndex=0; HandleIndex<Size; HandleIndex++)
> > {
> >
> > Status = gBS->OpenProtocol(HandleArray[HandleIndex],
> > ,
> > (VOID**) ,
> > ImageHandle,
> > NULL,
> > EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL);
> >
> > if(EFI_ERROR(Status)){
> >
> > gBS->CloseProtocol(HandleArray[HandleIndex],
> > ,
> > ImageHandle,
> > NULL);
> >
> > GraphicProtocol = NULL;
> >
> > continue;
> > } else {
> >
> > // Verifies if current handle corresponds to current video
> > Status = gBS->OpenProtocol(HandleArray[HandleIndex],
> > ,
> > (VOID**) ,
> > ImageHandle,
> > NULL,
> > EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL);
> >
> > if(EFI_ERROR(Status)){
> >
> > gBS->CloseProtocol(Ha

[edk2] Memory Consumption after BLT (GOP)

[Rafael Machado]

Hi Everyone.

I'm doing some tests related to the GOP and graphical applications.
What I've seeing is that after calling the GOP->BLT several times the
available memory from the system decrease.

For example. When the system just boot I have the following at the uefi
shell memmap command:

  reserved  : 124 Pages (507,904)
  LoaderCode: 186 Pages (761,856)
  LoaderData:  24 Pages (98,304)
  BS_code   :   1,719 Pages (7,041,024)
  BS_data   :  10,774 Pages (44,130,304)
  RT_code   : 256 Pages (1,048,576)
  RT_data   : 660 Pages (2,703,360)
  *available : 407,184 Pages (1,667,825,664)*
  ACPI_recl :  96 Pages (393,216)
  ACPI_NVS  : 129 Pages (528,384)
  MemMapIO  :   1 Pages (4,096)
Total Memory: 1,644 MB (1,724,530,688) Bytes

After executing a sample application that just draw a white box 10 times, I
have the following:

  reserved  : 124 Pages (507,904)
  LoaderCode: 186 Pages (761,856)
  LoaderData:  24 Pages (98,304)
  BS_code   :   1,719 Pages (7,041,024)
  BS_data   :  10,776 Pages (44,138,496)
  RT_code   : 256 Pages (1,048,576)
  RT_data   : 660 Pages (2,703,360)
 * available : 407,182 Pages (1,667,817,472)*
  ACPI_recl :  96 Pages (393,216)
  ACPI_NVS  : 129 Pages (528,384)
  MemMapIO  :   1 Pages (4,096)
Total Memory: 1,644 MB (1,724,530,688) Bytes


So the situation is that on a Graphical UEFI application, there is a
possibility of getting too much memory.
As much as I execute the application the available memory keeps decreasing.

Could someone please help me to find some problem on the sample application
code ?

"
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define BoxWidth 100
#define BoxHeight 100

EFI_STATUS PrintImage(EFI_HANDLE ImageHandle, UINTN ImagePositionX, UINTN
ImagePositionY){

UINTN Size;
EFI_STATUS Status;
UINTN HandleIndex = 0;
EFI_HANDLE *HandleArray = NULL;
EFI_GRAPHICS_OUTPUT_PROTOCOL *GraphicProtocol = NULL;
EFI_GUID gGraphicalProtocol = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
EFI_GUID gEdidActivated = EFI_EDID_ACTIVE_PROTOCOL_GUID;
EFI_EDID_ACTIVE_PROTOCOL *EdidActivated = NULL;
EFI_GRAPHICS_OUTPUT_BLT_PIXEL* inMemoryImage = NULL;

Status = gBS->LocateHandleBuffer(ByProtocol,
,
NULL,
,
);

if(!EFI_ERROR(Status))
{
for(HandleIndex=0; HandleIndexOpenProtocol(HandleArray[HandleIndex],
,
(VOID**) ,
ImageHandle,
NULL,
EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL);

if(EFI_ERROR(Status)){

gBS->CloseProtocol(HandleArray[HandleIndex],
,
ImageHandle,
NULL);

GraphicProtocol = NULL;

continue;
} else {

// Verifies if current handle corresponds to current video
Status = gBS->OpenProtocol(HandleArray[HandleIndex],
,
(VOID**) ,
ImageHandle,
NULL,
EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL);

if(EFI_ERROR(Status)){

gBS->CloseProtocol(HandleArray[HandleIndex],
,
ImageHandle,
NULL);

GraphicProtocol = NULL;

gBS->CloseProtocol(HandleArray[HandleIndex],
,
ImageHandle,
NULL);

EdidActivated = NULL;

continue;
} else {
break;
}
}
}

if(!EFI_ERROR(Status))
{
Status = gBS->AllocatePool(EfiBootServicesData,
sizeof(EFI_GRAPHICS_OUTPUT_BLT_PIXEL) *
BoxWidth * BoxHeight,
);

if(!EFI_ERROR(Status))
{

gBS->SetMem(inMemoryImage,
sizeof(EFI_GRAPHICS_OUTPUT_BLT_PIXEL) *
BoxWidth * BoxHeight,
0xFF);

Status = GraphicProtocol->Blt(GraphicProtocol,
inMemoryImage,
EfiBltBufferToVideo,
0,
0,
ImagePositionX,
ImagePositionY,
BoxWidth,
BoxHeight,
0);

if(EFI_ERROR(Status)){
Print(L"Fail to print Image");
goto CLEAR;
}
} else {
Print(L"Fail to allocate buffer");
goto CLEAR;
}

}else{
Print(L"Fail to locate GraphicIoProtocol devices");
goto CLEAR;
}
}

CLEAR:

if(inMemoryImage != NULL) {
FreePool(inMemoryImage);
inMemoryImage = NULL;
}

if(GraphicProtocol != NULL) {

Status = gBS->CloseProtocol(HandleArray[HandleIndex],
,
ImageHandle,
NULL);

GraphicProtocol = NULL;
}

if(EdidActivated != NULL) {

Status = gBS->CloseProtocol(HandleArray[HandleIndex],
,
ImageHandle,
NULL);

EdidActivated = NULL;
}

if(HandleArray != NULL) {
FreePool(HandleArray);
HandleArray = NULL;
}

return Status;
}


EFI_STATUS testMain(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
return PrintImage(ImageHandle, 50, 50);
}
"


Any help will be really useful.

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Question about Chipset initialization

[Rafael Machado]

Hi Everyone

Thanks for the guidance Marvin. A lot of good things and ideas for me to
take a look.

One question that I had after starting to take a look at the IntelFspPkg.
There are two files that are really close to each other.
These:

/IntelFspPkg/FspSecCore/Ia32/ResetVec.asm16
/IntelFspPkg/FspSecCore/Vtf0/Ia16/ResetVec.asm16

I tried to find some meaning for this duplicity, but didn't find a reason
for this. They are really close to each other.
Does anyone know why do we need these two files instead of one ? Maybe some
assembly magic that I didn't understand.

Thanks and Regards
Rafael R. Machado

Em seg, 28 de mar de 2016 às 13:11, Marvin Häuser <
marvin.haeu...@outlook.com> escreveu:

> Hello Rafael,
>
> Chipset initialization should be done in the PEI phase, along with the
> initialization of any critical hardware (DRAM, etc.). In DXE, usually the
> optional devices are initialized (controllers like USB and such). Here is a
> nice picture of the boot flow from the TianoCore Wiki:
>
>
> https://raw.githubusercontent.com/tianocore/tianocore.github.io/master/images/PI_Boot_Phases.JPG
>
> For further information, you can check out the Intel Firmware Support
> Package Documentation, as I believe that many vendor implementations use
> it, its code or at least based their code of the flow described in the
> Specification.
>
> I would suggest that you make your Audio driver an UEFI driver, as DXE
> drivers should be primarily used to expose everything needed during the
> Boot Services availability (NVRAM, System Reset, Console devices and such).
> By the time an UEFI app would run from the disk, audio would be available.
> For other drivers using audio, they should install a Protocol Notify hook
> to handle the Audio protocol installation. Apple has an HDA driver in their
> firmware (used for VoiceOver in their BootPicker and probably OS loader),
> in case you want to take a look at how others do it.
>
> Regards,
> Marvin.
>
> ____________
> Von: edk2-devel <edk2-devel-boun...@lists.01.org> im Auftrag von Rafael
> Machado <rafaelrodrigues.mach...@gmail.com>
> Gesendet: Montag, 28. März 2016 18:00
> An: edk2-devel@lists.01.org
> Betreff: [edk2] Question about Chipset initialization
>
> Hi everyone.
>
> I'm doing some studies related to audio at UEFI. To in future enable BIOS
> to be accessible. This is part of my MSc in Computer Science degree. It's
> take some time, but I'm not worried. The challenge was already accepted.
>
> Currently I'm checking is the chipset is already enabled correctly at the
> point a UEFI application can be executed after DXE phase.
>
> My questions are:
>
> What is normally the driver that enable the chipset?
> Is it at PEI phase or at DXE phase ?
>
> To understand the scenario and how things work at this point, I'm doing
> some reverse engineering using UEFITool and the framework radare2. Any
> other idea about how to proceed with these studies would be appreciated.
>
> Thanks and Regards
> Rafael R. Machado
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Question about Chipset initialization

[Rafael Machado]

Hi everyone.

I'm doing some studies related to audio at UEFI. To in future enable BIOS
to be accessible. This is part of my MSc in Computer Science degree. It's
take some time, but I'm not worried. The challenge was already accepted.

Currently I'm checking is the chipset is already enabled correctly at the
point a UEFI application can be executed after DXE phase.

My questions are:

What is normally the driver that enable the chipset?
Is it at PEI phase or at DXE phase ?

To understand the scenario and how things work at this point, I'm doing
some reverse engineering using UEFITool and the framework radare2. Any
other idea about how to proceed with these studies would be appreciated.

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Intel HDA Audio - Multimedia UEFI driver

[Rafael Machado]

Hi Galla / Everyone

My name is Rafael Machado and I'm doing an UEFI driver as my MSc (computer
science) teses.

The idea is to create accessible bios in future. This driver will just open
the first door.

I didn't find any solution related to Audio at UEFI, and this is the reason
I'll do this work.

Soon I'll start to ask the experts some guidance to do this task. I'm just
reading and doing some tests to have some background and avoid stupid
questions.

In any case, it'll be an opensource driver ( I'll try to add it to the UDK
tree after having the community approval).

It will take some time to do that, but I'll do my best.

Thanks and Regards
Rafael R. Machado

Em ter, 15 de mar de 2016 às 01:10, Galla Rao <gallagnv@gmail.com>
escreveu:

> Hello All,
>
> would be interested to know about playing Audio notes in "UEFI"
>
> examined default codec's are not installed in UEFI Audio driver
>
> have any generic hardware solution for Speaker & Microphone in UEFI?
>
> The chipset spec says
>
> "ACPI BIOS polls the DCKSTS.DM <http://dcksts.dm/> bit and when it detects
> it is set to 1,
> conveys this to the OS through a plug-N-play IRP. This eventually invokes
> the HD Audio Bus Driver, which then begins it's codec discovery,
> enumeration, and configuration process" (HD Audio Bus OS Driver)
>
> Audio codecs can be installed in UEFI?
>
> Thanks
> -Galla
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Transition to GitHub is complete

[Rafael Machado]

Hi everyone.

It is working now Jordan. Thanks!!

Rafael R. Machado

Em sáb, 6 de fev de 2016 às 22:19, Jordan Justen <jordan.l.jus...@intel.com>
escreveu:

> On 2016-02-06 04:43:36, Rafael Machado wrote:
> >Hi everyone
> >I just noticed that the driver writers guide is not accessible at the
> >github wiki.
> >
> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide
>
> Thanks for pointing that out. I think the PDF link was broken. It
> should be fixed now.
>
> Let me know if it is still not working for you.
>
> -Jordan
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Transition to GitHub is complete

[Rafael Machado]

Hi everyone

I just noticed that the driver writers guide is not accessible at the
github wiki.

https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide

Thanks
Rafael Machado

Em qua, 3 de fev de 2016 às 17:29, Jordan Justen <jordan.l.jus...@intel.com>
escreveu:

> On 2016-02-03 06:04:06, El-Haj-Mahmoud, Samer wrote:
> > Excellent and thanks to everyone who made this happen!
> >
> > From the wiki, it looks like all tasks were completed except these two:
> >
> > Post transition follow on tasks:
> >
> > #  Automated mirroring of git repo to git mirrors
> > #  Automated mirroring of git repo (master, UDK branches) back to
> deprecated svn repo
> >
> > When do we expect the automated mirroring of git to legacy SF SVN
> > repo to get started?
> >
>
> In terms of being automated, it is nearly ready to go. (Thanks to Hao
> Wu.) Erik will be finishing the task up. We just want to verify the
> automation using the live data from GitHub on a local test svn repo.
>
> In the meantime, we'll be manually syncronizing on a regular basis.
> Feel free to ping Erik and I if you need a sync done sooner for a
> particularly important commit.
>
> -Jordan
>
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jordan Justen
> > Sent: Tuesday, February 2, 2016 5:41 PM
> > To: edk2-devel@lists.01.org
> > Cc: Jarlstrom, Laurie <laurie.jarlst...@intel.com>; Laszlo Ersek <
> ler...@redhat.com>
> > Subject: [edk2] Transition to GitHub is complete
> >
> > On 2016-02-02 09:47:23, Jordan Justen wrote:
> > > As mentioned previously, we will attempt to transition to GitHub
> > > starting this morning (around 10AM PST, UTC-8). One of the first steps
> > > will be to disable SourceForge SVN write access.
> > >
> > > You can follow the progress here:
> > >
> > > https://github.com/tianocore/tianocore.github.io/wiki/Transition-to-Gi
> > > tHub
> > >
> >
> > Ok, all the major transition tasks have been completed now.
> >
> > Laszlo took the honor of pushing the first commit directly to the GitHub
> repo, so it appears that the package maintainers should have push access
> now. (Thanks Laszlo!)
> >
> > And, for months, quite a few people at Intel have been working behind
> the scenes to get everything ready for the transition. Thanks!
> >
> > Now, good luck to us on a (hopefully smooth) transition to using git
> directly for day-to-day development work!
> >
> > Merry EDK II Git Day!
> >
> > -Jordan
> >
> > > Or, on IRC (#edk2 on http://www.oftc.net/)
> > >
> > > On 2016-01-29 16:16:59, Jarlstrom, Laurie wrote:
> > > > To: EDK II Community
> > > >
> > > > The transition to GitHub will start February 2nd at around 10AM PST
> > > > (UTC-8). We estimate it to be completed by February 4th at 5PM PST.
> > > > During this time a number of changes will be happening including the
> > > > disabling of write access to the EDK II repository on SourceForge.
> > > > The time that write access is disabled will be reduced as much as
> > > > possible. A notification will be sent out prior to disabling write
> > > > access on SourceForge as well as a mail when write access is enabled
> > > > on GitHub.
> > > >
> > > > For status on the transition to GitHub see the Wiki page below.
> > > > https://github.com/tianocore/tianocore.github.io/wiki/Transition-to-
> > > > GitHub
> > > >
> > > > Please post any comments or questions related to this transition to
> > > > the edk2-devel mailing list or reply to the email message.
> > > >
> > > > Thanks, Tianocore.org Administration
> > > > ___
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] edk2 Bug tracking - help fixing issues

[Rafael Machado]

Hi everyone

I'd like to help the project to grow fixing some issues and developing new
features.
The problem is that I was not able to find a place where the issues are
tracked as mentioned at:
https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Issues

Is there any place where I can check the issues and try to help solving
them ?

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel