Thanks for the feedback. I cleaned up the code so it should compile on all the supported systems.
Only then did I discover a much simpler approach. It turns out that Linux (recent versions, at least) allow selective mmap access to /dev/mem even with various strict security features enabled. Simply not calling iopl() solves the problem.
I've posted a new patch for review.
--Ed
On Sat, Feb 28, 2015 at 4:08 PM, Stefan Tauner stefan.tauner@alumni.tuwien.ac.at wrote:
On Thu, 26 Feb 2015 13:53:13 -0800 Ed Swierk eswierk@skyportsystems.com wrote:
On Thu, Feb 26, 2015 at 4:10 AM, Patrick Georgi pgeorgi@google.com wrote:
2015-02-26 1:57 GMT+01:00 Ed Swierk eswierk@skyportsystems.com:
Running flashrom on a Linux system with CONFIG_STRICT_DEVMEM=y, I can now successfully program the SPI flash on an Intel 10G NIC using the
+#if !defined(__DJGPP__) && !defined(__LIBPAYLOAD__) +static void *pcidev_mapbar_sysfs(struct pci_dev *dev, const char *descr, int bar, off_t offset, size_t length)
Isn't that actually Linux specific, instead of non-djgpp-or-libpayload specific?
I suppose that's a safe assumption, though I don't know much about any of the other platforms flashrom supports. libpci already figures out whether the platform supports sysfs. I piggyback off that logic by checking pacc->method.
Here we're just deciding whether the platform uses mmap() to access physical address space. I followed the same approach used in physmap.c, since pcidev_mapbar_sysfs() is doing the same thing as sys_physmap_rw_uncached(), just with a PCI resource file instead of /dev/mem.
But I can switch to #if IS_LINUX if you think that's clearer. We can revisit that if and when some other sprouts a similar mmapped sysfs interface to PCI resources.
I have not really looked into the patch... but I did a little compile test on top of r1885. I'll just let the buildbot speak for itself: http://buildbot.flashrom.org/buildresults/flashrom-000164-Zcc/results.txt sparc7 is expected to fail with r1885.
-- Kind regards/Mit freundlichen Grüßen, Stefan Tauner