On Jan 25, 2013, at 3:11 AM, 雅虎邮箱 <linyao...@yahoo.cn> wrote:
> Hi Andrew,
> Thanks for your reply!
>
> I have completed the service driver, but about the application using
> EFI_FIRMWARE_VOLUME2_PROTOCOL, I have some new problems.
>
> I have seen your reply of the topic locating and dumping the BIOS firmware
> (edk2-devel Digest, Vol 37, Issue 97 ) which is launched by cruxpot, its the
> same task I want to complete:
> Since my last email, I was able to write platform-specific code that can
> access the firmware from an X64 platform and extract it. Is there a way to
> extract and/or dissect the FV or FVs that have the SEC and PEI Core for a
> given .FD or .ROM file (assume I have no corresponding .FDF file and do not
> know the structure)? The goal here is to do some integrity checks on key
> files or modules that are consistent and do not change (unless they are
> updated). I want to ignore sections of the ROM that have volatile data that
> changes frequently such as firmware settings changes, the clock, etc.. (write
> by cruxpot)
>
> And your reply is like this:
> UEFI is focused on defining the interfaces to option ROMs and OS loaders,
> >> and pushing policy decisions, where possible, in the platform firmware.
> >> UEFI tends to not define how the construct the platform Firmware. The UEFI
> >> PI specs go into more detail of firmware construction, but mostly so
> >> modules can interoperate. PI does not focus on things that are higher level
> >> platform firmware features.
> >>
> >> The PI terminology is FD (Flash Device) and there is no way to access the
> >> FD programmatically. The platform firmware produces FVs (Firmware Volumes)
> >> out of the FD in PEI (memory discovery/S3) and DXE (EFI services) phases.
> >> The FV containing the SEC and PEI Core are often executed directly from the
> >> FD, but most other FVs are compressed. This is all done via platform
> >> specific code. (On Mon, Dec 3, 2012 at 5:35 PM)
>
> My question is that, I tried to use EFI_FIRMWARE_VOLUME2_PROTOCOL in my
> application, but it can not be include like other protocol, the build will
> prompt errors and warnings, and I found that only the core of DXE phase can
> use this protocol normal, just as your reply above. Moreover, there are no
> information about this protocol in UEFI Spec.
I'll guess you are using:
#include <Uefi.h>
vs.
#include <PiDxe.h>
The build system supports building UEFI and UEFI + PI modules. Not all UEFI
systems are built out of PI. The basic idea is chunks of the firmware can
assume PI, but option ROMs, OS loaders, shells, etc. should not assume that
things PI exists.
Thanks,
Andrew
>
> So how can I complete the task of extract and/or dissect the BIOS ROM Image
> (FD or FV)? Could you give me some advices!
>
> Thanks & Best Regards!
>
> Justin Lin
>
> 发件人： Andrew Fish
> 发送时间： 2013-01-22 01:35
> 收件人： linyao_71
> 抄送： edk2-devel
> 主题： Re: Some Problems about driver and UINTN
>
> On Jan 21, 2013, at 8:42 AM, 雅虎邮箱 <linyao...@yahoo.cn> wrote:
>
>> Hi All,
>>
>> I meet with some problems now.
>>
>> 1. I am writing an Application use EFI_FIRMWARE_VOLUME2_PROTOCOL
>> (MdePkg\Include\Protocol\FirmwareVolume2.h), but when I compile it with
>> VS2010 compiler, it will prompt a warning C4431, which warning that UINTN
>> type is not recognized by compiler and must specify its width, like
>> UINT8/UINT16/UINT32/UINT64. Could anyone give me some advices?
>>
>
> Well the MdePkg Include/Base.h includes Include/X64/ProcessorBind.h (or the
> correct one for your processor type) and this contains the correct typedef
> for UINTN for your processor. So if you start your include list with
> something like #include <PiDxe.h> you should get UINTN properly defined.
>
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Include/Base.h
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Include/X64/ProcessorBind.h
>
> Could it be you are passing a UINTN type to a UINT32 argument? Maybe you
> define AuthenticationStatus as a UINTN?
>
>> 2. I am trying to write Service Driver now, the function is to show system
>> time on screen, but I have a problem that Driver will return EFI_SUCCESS in
>> Driver Entry Point, how can I make the event of show-time still work. I
>> don't understand the working mechanism of driver.
>>
> Your driver does not run. Your driver publishes protocols that get called by
> others to do work. Your driver can register timer event that will get called
> periodically. If you look in the UEFI specification Boot Services chapter you
> can read about CreateEvent() and SetTimer().
>
> In general it is not recommended that a driver write to the screen in EFI.
>
> Thanks,
>
> Andrew Fish
>> Thanks & Best Regards!
>>
>> Justin Lin
>
>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
