[gPXE-devel] [PATCH] EFI Simple Network Protocol driver

[Michael Brown]

On Tuesday 01 Jun 2010 19:56:58 Geoff Lywood wrote:
> I don't think that it is possible to use OpenProtocol for the
>  EFI_CPU_ARCH_PROTOCOL because you never know which handle to use. Having
>  said that, I don't think the EFI_CPU_ARCH_PROTOCOL is defined in the UEFI
>  spec and it may not be guaranteed to exist on all platforms. The "right
>  thing" is probably to use boot services instead, but comments in the code
>  hint that doing so may not always work? (Can you use a high frequency
>  timer and increment a tick count yourself?)

We could use boot services to set up a recurring timer; it wouldn't need to be 
high frequency.  (currticks() on PC BIOS has a resolution of only 18Hz.)  It 
would require a startup and shutdown function in efi_timer.c, but I think it 
should work.

> For the PCI and I/O protocols, I think that the network driver is generally
>  expected to do all accesses through the EFI_PCI_IO_PROTOCOL attached to
>  the handle for the network device, which you already open BY_DRIVER in
>  efi_snp_netdev. Currently the wiring isn't in place to keep it open and
>  have all config space, I/O and memory accesses go through it. I don't see
>  how that will be possible without some major rearchitecture: every
>  inb/outb in every driver would have to pass a device handle as a second
>  argument.

Yes; it was a deliberate design decision on my part not to break the 
fundamental model of memory-mapped I/O when adding EFI support.  (The 
EFI_PCI_IO_PROTOCOL is one of the worst abstraction designs I've seen in any 
code anywhere; it pretends that memory-mapped I/O doesn't exist, and is about 
as sensible as having an EFI_ADD_OR_SUBTRACT_PROTOCOL for performing basic 
arithmetic operations.)

Michael