Re: [edk2] EFI_BLOCK_IO_PROTOCOL questions

Hello Mike,

I would like to resume this discussion as I have made some progress.
Just to summarize, I am working on a PCIe option ROM which installs a EFI_BLOCK_IO_PROTOCOL. I am able to create a .rom file (MyDrv.rom) by using efirom.exe ( from the tools directory of \Platform\X64\Tools).

The target system has no other bootable devices except a 64bit DUET USB key.

At this point, I've programmed this image into my card and booted my target system.

I see a system hang when the DUET shell tries to initialize. With some debugging, I figured out that it is hanging when it is trying to list the devices it found during the boot (it hangs right after it displays the shell banner showing the version number).

I have tested this .rom file under shell, in my earlier experiments, by using loadpcirom command and I can see my driver listed, when I use the drivers command.

I took some DEBUG() traces in both cases ( i.e. when loaded from shell and when loaded as option ROM).

When loaded from shell

When loaded from shell (using loadpcirom), I see that first the Read() function is called (only once) with a block count of 1 and a valid Buffer address. Then I do map -r from the shell and I see that the Flush () function is called followed by a call to the Read() function with a block count of 1 and a valid physical address. At this point point I can see my drive in the list of bootable devices in shell. I can also navigate into my driver ( dir, cp, etc.)

=== after loadpcirom command ===
Read_func Buffer_PhyAdd: CCDCF01C

Read_func blk cnt: 1

== after map -r ===
Entered Flush function
Read_func Buffer_PhyAdd: CCDCEC98
Read_func blk cnt: 1

When loaded as expansion ROM

In this case, the behavior from the above case. It starts with calling the Read() function 6 times with a block count of 1 and a valid Buffer address. The Buffer address are sometimes the same and sometimes they are different. Then it calls the Flush() followed by a call to the Read() function again. In this last call to Read(), the block count is huge and so is the Buffer address

Read_func Buffer_PhyAdd: CD2C301C

Read_func blk cnt: 1

Read_func Buffer_PhyAdd: CD30BD98

Read_func blk cnt: 1

Read_func Buffer_PhyAdd: CD30BD98

Read_func blk cnt: 1

Read_func Buffer_PhyAdd: CCE2101C

Read_func blk cnt: 1

Read_func Buffer_PhyAdd: CCE36A18

Read_func blk cnt: 1

Read_func Buffer_PhyAdd: CCE36A18

Read_func blk cnt: 1

Entered Flush function

Read_func Buffer_PhyAdd: 23FFF2018

Read_func blk cnt: 78006F

Could you explain why the block count is so high ? Since I am reading one block at a time, the high block count number in the last Read() explains why I am seeing the system hang.

FYI, since I am in the initial stage of development, I am advertising my drive to be of 5 MBs. I am basically trying to prove the concept here.

Thanks in advance and let me know if you any need any other information

Regards,

Sai

On Fri, Jul 30, 2010 at 12:23 PM, Kinney, Michael D <michael.d.kinney@intel.com> wrote:

The PCI Bus Driver will read the PE/COFF image from the Option ROM and start it during PCI enumeration. This is done by calling LoadImage() and StartImage().

A UEFI Driver that follows the UEFI Driver Model will only register a Driver Binding Protocol in the entry point of the driver, so no connect operations will be performed when the driver is started by the PCI Bus Driver.

The Boot Manager (BDS Phase) is responsible for connecting the devices required to establish console(s) and connect the devices required for booting. The Boot Manager does this through calls to ConnectController(). ConnectController() calls the Supported() and Start() functions in drivers that have registered Driver Binding Protocols.

The EFI Shell command “connect –r” will force all drivers to be connected to all devices.

If your driver is not showing up in the “drivers” command list, then the driver is not be loaded from the PCI Option ROM. If you manually load the driver from the shell, do you see your driver in the “drivers” list? If so, then you may have an issue with the PCI Option ROM format or programming.

When you load your driver from the Shell, are Block I/O Protocols produced? If not, then you may have some issues with your Supported() or Start() functions.

The “dh –d <HandleNumber>” is a useful command to see what devices a driver is managing or the state of a device that is being managed by a driver.

The “openinfo” command is useful for debugging the use of the OpenProtocol() API to make sure the state of your controller and any child devices follows the UEFI Spec.

Other useful commands are “devices” and “devtree”.

Best regards,

Mike

From: rangasai C [mailto:rangasaic@gmail.com]
Sent: Friday, July 30, 2010 10:33 AM

To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EFI_BLOCK_IO_PROTOCOL questions

I am curious to know what would the host BIOS do when

1. It finds an option ROM for a bootable device, reads the first few LBAs and finds no valid data ( garbage). Will it try to still boot ? or try for some time and give up? or unload the driver ?

2. It finds an option ROM for a bootable device, tries to do a read but the Read() function returns a EFI_DEVICE_ERROR or EFI_NO_MEDIA ?

Thanks,

Sai

On Fri, Jul 30, 2010 at 10:24 AM, rangasai C <rangasaic@gmail.com> wrote:

I don't see my driver in the Shell, when I type "drivers" command in shell (and I am not sure why). Although, if I don't install the BLOCK_IO protocol ( i.e comment that line in the code). I do see my driver in the shell (ofcourse it won't do anything).

It's interesting to know that the driver won't be connected automatically. My understand was (and please correct me if I am wrong here), in general, during PCI enumeration, the BIOS allocates resources and checks for option ROMs. If it detects option ROM image (after verifying the signature bytes), it shadows the image and jumps to it's entry point and starts executing it. Is shadowing not similar to loading the image and executing not analogous to connecting the driver ?

On Fri, Jul 30, 2010 at 10:12 AM, Andrew Fish <afish@apple.com> wrote:

Can you see your driver in the shell drivers command?

You driver will not get connected (have its Supported() and Stop() functions called) automatically. It will only get connected in specific places, like when the shell loads, or if you do a connect command from the shell.

Andrew Fish

On Jul 30, 2010, at 10:08 AM, rangasai C wrote:

Tian,

I am using DUET only for obtaining shell environment. So basically I have formatted my USB key to a DUET disk to boot a 64bit shell..My driver, on the other hand, is built under EDK1.05 framework and doesn't use of the DUET files or libraries.

Also, I am able to see my debug messages otherwise. It's just that after I install the block Io Protocol, I don't see any messages that I have printed in my read() write(), reset() and Flush () functions.

Basically I can say that for some reason, the BIOS is not calling the functions of EFI_BLOCK_IO_PROTOCOL, even though the interface has been published by my driver.

Thanks,

Sai

On Thu, Jul 29, 2010 at 8:16 PM, Tian, Feng <feng.tian@intel.com> wrote:

Hi, Sai

Could you ensure the debug lib instance of your Pcie device driver is chosen correctly?

In DuetPkg, because of the size limitation, most of drivers are assigned to use BaseDebugLibNull instance which will cause no debug info output.

If you want to see the DEUBG message for your module, you should add such rule in DuetPkgX64.dsc

Path to your Pcie device driver/xxx.inf {

    <PcdsFixedAtBuild>

      gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F

      gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80000042

    <LibraryClasses>

      DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf

      SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf

}

Because your case is hard to root-cause by description, so using debug message to debugging seems the only wayJ

Thanks

Tian Feng

From: rangasai C [mailto:rangasaic@gmail.com]
Sent: Friday, July 30, 2010 7:47 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EFI_BLOCK_IO_PROTOCOL questions

I agree. These kind of issues is hard to explain or guess via emails but I will try to provide as much information I can.

Basically I am using EDK1.05 framework. I am installing the Driver Binding protocol as a global variable, in my driver entry point

   return INSTALL_ALL_DRIVER_PROTOCOLS_OR_PROTOCOLS2 (

   ImageHandle,

   SystemTable,

   &gMyDriverBinding,

   ImageHandle,

   &gMyDriverComponentName,

   NULL,

   NULL

   );

Where gMyDriverBinding is a global variable

EFI_DRIVER_BINDING_PROTOCOL gMyDriverBinding = {

  MyDriverBindingSupported,

  MyDriverBindingStart,

  MyDriverBindingStop,

  0x15,

  NULL,

  NULL

};

and gMyDriverComponentName is also a global variable

EFI_COMPONENT_NAME2_PROTOCOL gMyDriverComponentName = {

  MyDriverComponentNameGetDriverName,

  MyDriverComponentNameGetControllerName,

  LANGUAGE_CODE_ENGLISH

};

On Thu, Jul 29, 2010 at 4:15 PM, Andrew Fish <afish@apple.com> wrote:

OK Hard to guess at what is wrong? Are you allocating your protocol as a local variable on the stack so it no longer exists when your driver entry point returns?

Andrew Fish

On Jul 29, 2010, at 3:40 PM, rangasai C wrote:

You are right. Since this is a device driver, I am installing EFI_DRIVER_BINDING_PROTOCOL. The start() function first initializes the controller and before exiting, it installs EFI_BLOCK_IO_PROTOCOL. For debugging purpose I modified the Read(), Write(), Flush() and Reset() functions such that it just prints a debug message (something like DEBUG((EFI_D_ERROR,"Entered Read function \n")); ) and returns EFI_SUCCESS. I dont' see those messages in my hyperterminal.

On Thu, Jul 29, 2010 at 3:33 PM, Andrew Fish <afish@apple.com> wrote:

You should be installing an EFI_DRIVER_BINDING_PROTOCOL and the Start() function should install an instance of the EFI_BLOCK_IO protocol.

Sent from my iPad

On Jul 29, 2010, at 2:19 PM, rangasai C <rangasaic@gmail.com> wrote:

> Hi All,
> I have written a PCIe device driver which, after initializing the controller, installs a EFI_BLOCK_IO protocol. I don't have a debugger but with DEBUG() macro and DUET, I could verify that Initialization code works and gBS->InstallMultipleProtocolInterfaces () returns Success after I install (or produce) EFI_BLOCK_IO protocol. At this point I would expect that the host BIOS should call the EFI_BLOCK_IO protocol function (Read(), Write(), Reset() and Flush()). However, I see the system hangs. The last message I see in my hyper terminal is the return status of gBS->InstallMultipleProtocolInterfaces, which is EFI_SUCCESS.
>
> Has anyone seen this kind of behavior ? Is there anything, I should be doing here ?.. By the way, I tested my driver by loading through the shell before I converted into option ROM. It works fine in the shell environment.
>
> I am not sure where to look in order to debug this issue !
>
> Thanks in advance.
> Regards,
> Sai

> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel