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 _______________________________________________ gPXE-devel mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe-devel
