On May 28, 2014, at 12:10 PM, Felipe Mesquita <felipe.mesqu...@lsbd.ufc.br>
wrote:
> Hello everyone,
>
> I've been working on trying to set up a RAM disk and obtain an
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instance that "points" to a FAT32 volume in
> it.
> My team managed to accomplish this by loading the RamDisk.efi driver and
> reproducing a portion of the code that implements the 'mount' command[1]. We
> had to do it because simply loading the RamDisk.efi driver(which installs a
> BlockIO protocol instance providing access to a FAT32-formatted memory
> buffer) does not trigger the creation of an EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
> by the filesystem driver: we needed to reinstall the BlockIO protocol
> provided by the driver in order to finally make the filesystem driver get
> notified and detect the new volume in the RAM disk.
>
> This solution is working so far, but we've been bugged by having to rely on
> this workaround: after all, wasn't the filesystem driver supposed to be
> notified every time a new BlockIO is registered and then, if it detects a
> valid FAT volume in it, generate the appropriate
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instance? Why is it only notified when the
> BlockIO protocol instance is reinstalled?
>
Because this is obsolete EFI 1.0 behavior. Per UEFI 2.4
ReinstallProtocolInterface()
EFI 1.10 Extension
The extension to this service directly addresses the limitations described in
the section above. There may be some number of drivers currently consuming the
protocol interface that is being reinstalled. In this case, it may be dangerous
to replace a protocol interface in the system. It could result in an unstable
state, because a driver may attempt to use the old protocol interface after a
new one has
been reinstalled. Since the usage of protocol interfaces is now being tracked
for components that use the OpenProtocol() and CloseProtocol() boot services, a
safe version of this function can be implemented.
When this function is called, a call is first made to the boot service
InstallProtocolInterface(). This will guarantee that all of the agents are
currently consumingtheprotocolinterfaceOldInterfacewillstopusingOldInterface.
If UninstallProtocolInterface() returns EFI_ACCESS_DENIED, then this function
returns EFI_ACCESS_DENIED, OldInterface remains on Handle, and the protocol
notifies are not processed because NewInterface was never installed.
If UninstallProtocolInterface() succeeds, then a call is made to the boot
service InstallProtocolInterface() to put the NewInterface onto Handle.
Finally, the boot service ConnectController() is called so all agents that were
forced to release OldInterface with UninstallProtocolInterface() can now
consume the protocol interface NewInterface that was installed with
InstallProtocolInterface(). After OldInterface has been replaced with
NewInterface, any process that has registered to wait for the installation of
the interface is notified.
> The comment below can be found just before the code we checked inmount.c, but
> we couldn't relate it to the scenario we have:
>
> //
> // In EFI the file system driver registers to get notified when DiskIo
> // Devices are added to the system. DiskIo devices register to get notified
> // when BlkIo devices are added to the system. So when a block device shows
> // up a DiskIo is added, and then a file system if added if the media
> // contains a file system. This works great, but when you boot with no media
> // in the device and then put media in the device there is no way to make
> // the notify happen.
> //
So the comment is obsolete for EFI 1.10 and all of UEFI.
> // This code reads a block device. If the BlkIo device returns
> // EFI_MEDIA_CHANGE then it must reinstall in BlkIo protocol. This cause the
> // notifies that make the file system show up. The 4 loops is just a guess
> it
> // has no magic meaning.
> //
>
> So could anyone explain what piece of understanding is missing here?
> Thank you all in advance.
>
The FAT (and partition) driver are EFI 1.10 driver model drivers and they just
produce the Driver Binding protocol. It is platform policy when devices get
connected. To boot quickly you don’t want to auto connect every driver, just
the ones you are booting too. The Shell does a connect all when it launches to
connect devices, and there are shell commands to connect and disconnect
drivers.
Thanks,
Andrew Fish
> [1] at EdkCompatibilityPkg/Other/Maintained/Application/Shell/mount/mount.c,
> around line 250.
>
> --
>
> Felipe Martins Mesquita
> Technical Lead
> BSc in Computer Science - UFC
> GTalk: felipe.mesqu...@lsbd.ufc.br
> Skype: felipe.martins23
> ------------------------------------------------------------------------------
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet_______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
