pci support

pci support

[vincent guffens]

Hi!

I was wondering if there was still an interest in pci support as
discussed previously. That is a general interface exported by a module
such as

struct grub_pci_support
{
  /* My name.  */
  const char *name;

  void (*init)(void);
  void (*fini)(void);

  void (*adjust) (grub_pci_device_t p);

  /* Base Address Register helper functions. There are up to 6 BARs
     PCI_BASE_ADDRESS_{[0-5]} in the configuration space of each device */
  unsigned long (*bar_start) (grub_pci_device_t, unsigned int bar);
  unsigned long (*bar_size) (grub_pci_device_t, unsigned int bar);

  int (*find_capability) (grub_pci_device_t, int cap);

  /* Call HOOK with each pci device.  */
  grub_err_t (*iterate) (int (*hook) (grub_pci_device_t));

  /* Fill the pci device structure (romaddr, ioaddr, membase, irq)*/
  grub_err_t (*init_pdev) (grub_pci_device_t);

  /* Low level io functions.  */
  struct grub_pci_io_support *io;
};

which allows multiple implementations such as one for instance from
etherboot which I have now.

It was written original with the idea of importing the etherboot drivers
so I don't know if it would still be usefull. The implementation that I
have uses direct pci access which maybe does not fit very well with the
idea of using pxe later on as it will require dealing with some bios
stuff anyway. It is basically usefull now for the lspci command which
could be made to print some nice text just like the Linux lspci command.

If so, I can prepare a separated patch for it and prepare the changelog.

Cheers,

--
    Vincent Guffens

Re: pci support

[Vesa Jääskeläinen]

vincent guffens wrote:
> Hi!
> 
> I was wondering if there was still an interest in pci support as
> discussed previously. That is a general interface exported by a module
> such as

Yes there is, in example PCI support would be enable usage of more ATA
Controllers than legacy ports support. PCI device enumeration could be
used to scan for ports to access those other controllers in system.

> If so, I can prepare a separated patch for it and prepare the changelog.
> 
> Cheers,
> 
> --
>     Vincent Guffens

Please do :).

Thanks,
Vesa Jääskeläinen

Re: pci support

[Marco Gerards]

vincent guffens <v.guffens@imperial.ac.uk> writes:

Hi Vincent,

> I was wondering if there was still an interest in pci support as
> discussed previously. That is a general interface exported by a module
> such as

Yes, that will make it possible to implement all kinds of drivers and
make something like lspci possible.

Sorry I still didn't start working on the networking stuff as planned.
Scripting and other stuff occupies me longer than I originally
expected. :)

--
Marco

Re: pci support

[vincent guffens]

Marco Gerards wrote:
> vincent guffens <v.guffens@imperial.ac.uk> writes:
> 
> Hi Vincent,
> 
> 
>>I was wondering if there was still an interest in pci support as
>>discussed previously. That is a general interface exported by a module
>>such as
> 
> 
> Yes, that will make it possible to implement all kinds of drivers and
> make something like lspci possible.
> 
> Sorry I still didn't start working on the networking stuff as planned.
> Scripting and other stuff occupies me longer than I originally
> expected. :)

Sure, no problem! In fact, I was wondering if it would be possible to
have a discussion about the overall networking strategy that will be put
in place for grub2 (and which is schedulled for the next release !).

As I understand, supporting the etherboot drivers is no longer the
primary option. As it is out of the question to have its own set of
driver,  the UNDI driver seems like a good idea. However, UNDI support
would constrain significantly the design of the network stack. In
particular, it defines a lot of structure such as dhcp header, ipv4
addresses and so on. It also involves interruption while it was assumed
previously that the interfaces would be polled.

There is also the option of calling etherboot from grub2, which seems
quite appealing but I think I don't really quite get that.

cheers!

Re: pci support

[Marco Gerards]

vincent guffens <v.guffens@imperial.ac.uk> writes:

> Marco Gerards wrote:
>> vincent guffens <v.guffens@imperial.ac.uk> writes:
>> 
>> Hi Vincent,
>> 
>> 
>>>I was wondering if there was still an interest in pci support as
>>>discussed previously. That is a general interface exported by a module
>>>such as
>> 
>> 
>> Yes, that will make it possible to implement all kinds of drivers and
>> make something like lspci possible.
>> 
>> Sorry I still didn't start working on the networking stuff as planned.
>> Scripting and other stuff occupies me longer than I originally
>> expected. :)
>
> Sure, no problem! In fact, I was wondering if it would be possible to
> have a discussion about the overall networking strategy that will be put
> in place for grub2 (and which is schedulled for the next release !).

Sure!

> As I understand, supporting the etherboot drivers is no longer the
> primary option. As it is out of the question to have its own set of
> driver,  the UNDI driver seems like a good idea. However, UNDI support
> would constrain significantly the design of the network stack. In
> particular, it defines a lot of structure such as dhcp header, ipv4
> addresses and so on. It also involves interruption while it was assumed
> previously that the interfaces would be polled.

Well, I do not really know UNDI.  I had the impression it was able to
send and receive raw ehternet frames.  Which is what I want, nothing
more and nothing less.

At interrupt time, you can store the frames in a queue so they can be
polled at a later moment.  Or the design should be changed so
interruptions can be supported.  That's not a big issue I think.

> There is also the option of calling etherboot from grub2, which seems
> quite appealing but I think I don't really quite get that.

Is that etherboot specific or is that the case for every UNDI
implementation?

--
Marco

Re: pci support

[vincent guffens]

Marco Gerards wrote:
> vincent guffens <v.guffens@imperial.ac.uk> writes:
> 
> 
>>Marco Gerards wrote:
>>
>>>vincent guffens <v.guffens@imperial.ac.uk> writes:
>>>
>>>Hi Vincent,
>>>
>>>
>>>
>>>>I was wondering if there was still an interest in pci support as
>>>>discussed previously. That is a general interface exported by a module
>>>>such as
>>>
>>>
>>>Yes, that will make it possible to implement all kinds of drivers and
>>>make something like lspci possible.
>>>
>>>Sorry I still didn't start working on the networking stuff as planned.
>>>Scripting and other stuff occupies me longer than I originally
>>>expected. :)
>>
>>Sure, no problem! In fact, I was wondering if it would be possible to
>>have a discussion about the overall networking strategy that will be put
>>in place for grub2 (and which is schedulled for the next release !).
> 
> 
> Sure!
> 
> 
>>As I understand, supporting the etherboot drivers is no longer the
>>primary option. As it is out of the question to have its own set of
>>driver,  the UNDI driver seems like a good idea. However, UNDI support
>>would constrain significantly the design of the network stack. In
>>particular, it defines a lot of structure such as dhcp header, ipv4
>>addresses and so on. It also involves interruption while it was assumed
>>previously that the interfaces would be polled.
> 
> 
> Well, I do not really know UNDI.  I had the impression it was able to
> send and receive raw ehternet frames.  Which is what I want, nothing
> more and nothing less.
> 
> At interrupt time, you can store the frames in a queue so they can be
> polled at a later moment.  Or the design should be changed so
> interruptions can be supported.  That's not a big issue I think.

yes, you can use it with a polling mechanism as well. But UNDI has a
much more complex API then just sending and receiving raw frames. You
have API calls to request a file via tftp or even mtftp, get the
information received from the dhcp server, send UDP packets and so on.
It would be waste, I think, to go through the work of supporting UNDI
and not getting the entire benefit which would require a strong
coordination between the PXE/UNDI code and the net code of grub2
(through the PXE specification)

> 
>>There is also the option of calling etherboot from grub2, which seems
>>quite appealing but I think I don't really quite get that.
> 
> 
> Is that etherboot specific or is that the case for every UNDI
> implementation?

well, I just mentioned the idea that was raised by Okuji in an earlier
post. That is what I meant and I don't know if I understood properly but
etherboot implements a PXE stacks. So if a network card does not support
it, it would be possible to use etherboot as the PXE stack. But I don't
know how it would work. When etherboot is located in an extension rom,
then maybe the bios can scan it and use it ? I am not sure but I have
sent the question to the etherboot mailing list, I am waiting for some
comments.

Re: pci support

[Marco Gerards]

vincent guffens <v.guffens@imperial.ac.uk> writes:

>>>As I understand, supporting the etherboot drivers is no longer the
>>>primary option. As it is out of the question to have its own set of
>>>driver,  the UNDI driver seems like a good idea. However, UNDI support
>>>would constrain significantly the design of the network stack. In
>>>particular, it defines a lot of structure such as dhcp header, ipv4
>>>addresses and so on. It also involves interruption while it was assumed
>>>previously that the interfaces would be polled.
>> 
>> 
>> Well, I do not really know UNDI.  I had the impression it was able to
>> send and receive raw ehternet frames.  Which is what I want, nothing
>> more and nothing less.
>> 
>> At interrupt time, you can store the frames in a queue so they can be
>> polled at a later moment.  Or the design should be changed so
>> interruptions can be supported.  That's not a big issue I think.
>
> yes, you can use it with a polling mechanism as well. But UNDI has a
> much more complex API then just sending and receiving raw frames. You
> have API calls to request a file via tftp or even mtftp, get the
> information received from the dhcp server, send UDP packets and so on.
> It would be waste, I think, to go through the work of supporting UNDI
> and not getting the entire benefit which would require a strong
> coordination between the PXE/UNDI code and the net code of grub2
> (through the PXE specification)

The less we rely on PXE code, the less bugs we have to deal with I
think.  Most firmware implementations are full of bugs, I don't expect
the PXE implementations are an exception.

Ad besides that, we need full networking support anyways.  For example
for the PPC port.

>>>There is also the option of calling etherboot from grub2, which seems
>>>quite appealing but I think I don't really quite get that.
>> 
>> 
>> Is that etherboot specific or is that the case for every UNDI
>> implementation?
>
> well, I just mentioned the idea that was raised by Okuji in an earlier
> post. That is what I meant and I don't know if I understood properly but
> etherboot implements a PXE stacks. So if a network card does not support
> it, it would be possible to use etherboot as the PXE stack. But I don't
> know how it would work. When etherboot is located in an extension rom,
> then maybe the bios can scan it and use it ? I am not sure but I have
> sent the question to the etherboot mailing list, I am waiting for some
> comments.

Please let me know.

--
Marco

PCI support

[Marco Gerards]

Hi,

Here is a patch that allows you to iterate over PCI devices.  The file
pci.c adds a function to iterate over the devices and a function to
generate an address to query the PCI device.  Furthermore, there is a
function to actually access the hardware, which is machine specific.
I only implemented this for i386-pc.  I assume it can be shared with
linuxbios, i386-efi and i386-ieee1275.  When you want to use this,
just include <grub/pci.h>.

When you want to detect if your device is supported, just use
grub_pci_iterate.  It gives you every PCI device.  For example, the
class has to be read to determine if a device is an ATA device.  This
will be added to the ATA driver.

The lspci that is included shows the PCIID and the class of the
device.  It's not capable of reading pci.ids yet.  I have some code
for this, but it is just too damn slow...  But I am sure this will do
for now
:-)

I wanted to wait with this patch until the ATA driver is adapted.  But
I won't have time for that this week.  So I can better get this
committed and people working on this ;-).  There is some code for ATA,
but it was not tested yet.  The main problem here is qemu.

Does someone know if it is possible, at all, to have ATA devices
showing up as non-legacy PCI devices in Qemu?  IDE interfaces are
placed (and locked) in Legacy mode, meaning default IRQs and IO ports
are used.  This means just our old ISA code will be used.  To support
non-legacy modes, it would be nice if I could do some testing.  Does
someone have suggestions?

--
Marco



2009-01-28  Marco Gerards  <marco@gnu.org>

	* bus/pci.c: New file.

	* include/grub/pci.h: Likewise.

	* include/grub/i386/pc/pci.h: Likewise.

	* commands/lspci.c: Likewise.

	* conf/i386-pc.rmk (pkglib_MODULES): Add `pci.mod' and
	`lspci.mod'.
	(pci_mod_SOURCES): New variable.
	(pci_mod_CFLAGS): Likewise.
	(pci_mod_LDFLAGS): Likewise.
	(lspci_mod_SOURCES): Likewise.
	(lspci_mod_CFLAGS): Likewise.
	(lspci_mod_LDFLAGS): Likewise.	


Index: bus/pci.c
===================================================================
RCS file: bus/pci.c
diff -N bus/pci.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ bus/pci.c	28 Jan 2008 13:47:00 -0000
@@ -0,0 +1,55 @@
+/* pci.c - Generic PCI interfaces.  */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2008  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <grub/dl.h>
+#include <grub/pci.h>
+
+grub_pci_address_t
+grub_pci_make_address (int bus, int device, int function, int reg)
+{
+  return (1 << 31) | (bus << 16) | (device << 11) | (function << 8) | (reg << 2);
+}
+
+void
+grub_pci_iterate (grub_pci_iteratefunc_t hook)
+{
+  int bus;
+  int dev;
+  int func;
+  grub_pci_address_t addr;
+  grub_pci_id_t id;
+
+  for (bus = 0; bus < 256; bus++)
+    {
+      for (dev = 0; dev < 32; dev++)
+	{
+	  for (func = 0; func < 3; func++)
+	    {
+	      addr = grub_pci_make_address (bus, dev, func, 0);
+	      id = grub_pci_read (addr);
+
+	      /* Check if there is a device present.  */
+	      if (id >> 16 == 0xFFFF)
+		continue;
+
+	      hook (bus, dev, func, id);
+	    }
+	}
+    }
+}
Index: commands/lspci.c
===================================================================
RCS file: commands/lspci.c
diff -N commands/lspci.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ commands/lspci.c	28 Jan 2008 13:47:00 -0000
@@ -0,0 +1,163 @@
+/* lspci.c - List PCI devices.  */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2007  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <grub/pci.h>
+#include <grub/dl.h>
+#include <grub/normal.h>
+#include <grub/misc.h>
+
+struct grub_pci_classname
+{
+  int class;
+  int subclass;
+  char *desc;
+};
+
+static const struct grub_pci_classname grub_pci_classes[] =
+  {
+    { 0, 0, "" },
+    { 1, 0, "SCSCI Controller" },
+    { 1, 1, "IDE Controller" },
+    { 1, 2, "Floppy Controller" },
+    { 1, 3, "IPI Controller" },
+    { 1, 4, "RAID Controller" },
+    { 1, 0x80, "Mass storage Controller" },
+    { 2, 0, "Ethernet Controller" },
+    { 2, 1, "Token Ring Controller" },
+    { 2, 2, "FDDI Controller" },
+    { 2, 3, "ATM Controller" },
+    { 2, 4, "ISDN Controller" },
+    { 2, 0x80, "Network controller" },
+    { 3, 0, "VGA Controller" },
+    { 3, 1, "XGA Controller" },
+    { 3, 2, "3D Controller" },
+    { 3, 0x80, "Display Controller" },
+    { 4, 0, "Multimedia Video Device" },
+    { 4, 1, "Multimedia Audio Device" },
+    { 4, 2, "Multimedia Telephony Device" },
+    { 4, 0x80, "Multimedia device" },
+    { 5, 0, "RAM Controller" },
+    { 5, 1, "Flash Memory Controller" },
+    { 5, 0x80, "Memory Controller" },
+    { 6, 0, "Host Bridge" },
+    { 6, 1, "ISA Bridge" },
+    { 6, 2, "EISA Bride" },
+    { 6, 3, "MCA Bridge" },
+    { 6, 4, "PCI-PCI Bridge" },
+    { 6, 5, "PCMCIA Bridge" },
+    { 6, 6, "NuBus Bridge" },
+    { 6, 7, "CardBus Bridge" },
+    { 6, 8, "Raceway Bridge" },
+    { 6, 0x80, "Unknown Bridge" },
+    { 7, 0x80, "Communication controller" },
+    { 8, 0x80, "System hardware" },
+    { 9, 0, "Keyboard Controller" },
+    { 9, 1, "Digitizer" },
+    { 9, 2, "Mouse Controller" },
+    { 9, 3, "Scanner Controller" },
+    { 9, 4, "Gameport Controller" },
+    { 9, 0x80, "Unknown Input Device" },
+    { 10, 0, "Generic Docking Station" },
+    { 10, 0x80, "Unkown Docking Station" },
+    { 11, 0, "80386 Processor" },
+    { 11, 1, "80486 Processor" },
+    { 11, 2, "Pentium Processor" },
+    { 11, 0x10, "Alpha Processor" },
+    { 11, 0x20, "PowerPC Processor" },
+    { 11, 0x30, "MIPS Processor" },
+    { 11, 0x40, "Co-Processor" },
+    { 11, 0x80, "Unkown Processor" },
+    { 12, 0x80, "Serial Bus Controller" },
+    { 13, 0x80, "Wireless Controller" },
+    { 14, 0, "I2O" },
+    { 15, 0, "iRDA Controller" },
+    { 15, 1, "Consumer IR" },
+    { 15, 0x10, "RF-Controller" },
+    { 15, 0x80, "Satellite Communication Controller" },
+    { 16, 0, "Network Decryption" },
+    { 16, 1, "Entertainment Decryption" },
+    { 16, 0x80, "Unkown Decryption Controller" },
+    { 17, 0, "Digital IO Module" },
+    { 17, 0x80, "Unkown Data Input System" },
+    { 0, 0, 0 },
+  };
+
+static const char *
+grub_pci_get_class (int class, int subclass)
+{
+  const struct grub_pci_classname *curr = grub_pci_classes;
+
+  while (curr->desc)
+    {
+      if (curr->class == class && curr->subclass == subclass)
+	return curr->desc;
+      curr++;
+    }
+
+  return 0;
+}
+
+static int
+grub_lspci_iter (int bus, int dev, int func, grub_pci_id_t pciid)
+{
+  grub_uint32_t class;
+  const char *sclass;
+  grub_pci_address_t addr;
+
+  grub_printf ("%02x:%02x.%x %04x:%04x.%d", 0, dev, func, pciid >> 16, pciid & 0xFFFF, func);
+  addr = grub_pci_make_address (bus, dev, func, 2);
+  class = grub_pci_read (addr);
+	  
+  /* Lookup the class name, if there isn't a specific one,
+     retry with 0x80 to get the generic class name.  */
+  sclass = grub_pci_get_class (class >> 24, (class >> 16) & 0xFF);
+  if (! sclass)
+    sclass = grub_pci_get_class (class >> 24, 0x80);
+  if (! sclass)
+    sclass = "";
+
+  grub_printf (" %s\n", sclass);
+
+  return 0;
+}
+
+static grub_err_t
+grub_cmd_lspci (struct grub_arg_list *state __attribute__ ((unused)),
+		int argc __attribute__ ((unused)),
+		char **args __attribute__ ((unused)))
+{
+  grub_pci_iterate (grub_lspci_iter);
+  return GRUB_ERR_NONE;
+}
+
+
+\f
+
+GRUB_MOD_INIT(pci)
+{
+  (void) mod;			/* To stop warning. */
+  grub_register_command ("lspci", grub_cmd_lspci, GRUB_COMMAND_FLAG_BOTH,
+			 "lspci", "List PCI devices", 0);
+}
+
+
+GRUB_MOD_FINI(pci)
+{
+  grub_unregister_command ("lspci");
+}
Index: conf/i386-pc.rmk
===================================================================
RCS file: /sources/grub/grub2/conf/i386-pc.rmk,v
retrieving revision 1.100
diff -u -p -u -p -r1.100 i386-pc.rmk
--- conf/i386-pc.rmk	6 Jan 2008 15:34:11 -0000	1.100
+++ conf/i386-pc.rmk	28 Jan 2008 13:47:00 -0000
@@ -136,7 +136,7 @@ pkglib_MODULES = biosdisk.mod _chain.mod
 	_multiboot.mod chain.mod multiboot.mod reboot.mod halt.mod	\
 	vbe.mod vbetest.mod vbeinfo.mod video.mod gfxterm.mod \
 	videotest.mod play.mod bitmap.mod tga.mod cpuid.mod serial.mod	\
-	ata.mod vga.mod
+	ata.mod vga.mod pci.mod lspci.mod
 
 # For biosdisk.mod.
 biosdisk_mod_SOURCES = disk/i386/pc/biosdisk.c
@@ -264,4 +264,14 @@ vga_mod_SOURCES = term/i386/pc/vga.c
 vga_mod_CFLAGS = $(COMMON_CFLAGS)
 vga_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
+# For pci.mod
+pci_mod_SOURCES = bus/pci.c
+pci_mod_CFLAGS = $(COMMON_CFLAGS)
+pci_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
+# For lspci.mod
+lspci_mod_SOURCES = commands/lspci.c
+lspci_mod_CFLAGS = $(COMMON_CFLAGS)
+lspci_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
 include $(srcdir)/conf/common.mk
Index: include/grub/pci.h
===================================================================
RCS file: include/grub/pci.h
diff -N include/grub/pci.h
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ include/grub/pci.h	28 Jan 2008 13:47:00 -0000
@@ -0,0 +1,37 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2008  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef	GRUB_PCI_H
+#define	GRUB_PCI_H	1
+
+#include <grub/types.h>
+#include <grub/symbol.h>
+
+typedef grub_uint32_t grub_pci_id_t;
+typedef int (*grub_pci_iteratefunc_t) (int bus, int device, int func,
+				       grub_pci_id_t pciid);
+typedef grub_uint32_t grub_pci_address_t;
+
+grub_pci_address_t EXPORT_FUNC(grub_pci_make_address) (int bus, int device,
+						       int function, int reg);
+
+void EXPORT_FUNC(grub_pci_iterate) (grub_pci_iteratefunc_t hook);
+
+#include <grub/machine/pci.h>
+
+#endif /* GRUB_PCI_H */
Index: include/grub/i386/pc/pci.h
===================================================================
RCS file: include/grub/i386/pc/pci.h
diff -N include/grub/i386/pc/pci.h
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ include/grub/i386/pc/pci.h	28 Jan 2008 13:47:01 -0000
@@ -0,0 +1,35 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2008  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef	GRUB_CPU_PCI_H
+#define	GRUB_CPU_PCI_H	1
+
+#include <grub/types.h>
+#include <grub/i386/io.h>
+
+#define GRUB_PCI_ADDR_REG	0xcf8
+#define GRUB_PCI_DATA_REG	0xcfc
+
+static inline grub_uint32_t
+grub_pci_read (grub_pci_address_t addr)
+{
+  grub_outl (addr, GRUB_PCI_ADDR_REG);
+  return grub_inl (GRUB_PCI_DATA_REG);
+}
+
+#endif /* GRUB_CPU_PCI_H */

Re: PCI support

[Robert Millan]

On Mon, Jan 28, 2008 at 03:03:33PM +0100, Marco Gerards wrote:
> 
> I wanted to wait with this patch until the ATA driver is adapted.  But
> I won't have time for that this week.  So I can better get this
> committed and people working on this ;-).  There is some code for ATA,
> but it was not tested yet.  The main problem here is qemu.
> 
> Does someone know if it is possible, at all, to have ATA devices
> showing up as non-legacy PCI devices in Qemu?  IDE interfaces are
> placed (and locked) in Legacy mode, meaning default IRQs and IO ports
> are used.  This means just our old ISA code will be used.  To support
> non-legacy modes, it would be nice if I could do some testing.  Does
> someone have suggestions?

Try:

--- qemu-0.9.0+20070816/hw/pc.c~        2007-06-06 18:26:13.000000000 +0200
+++ qemu-0.9.0+20070816/hw/pc.c 2008-01-28 18:25:00.000000000 +0100
@@ -676,6 +676,8 @@
     qemu_irq *cpu_irq;
     qemu_irq *i8259;

+    pci_enabled = 1;
+
     linux_boot = (kernel_filename != NULL);

     /* init CPUs */

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)

Re: PCI support

[Marco Gerards]

Robert Millan <rmh@aybabtu.com> writes:

> On Mon, Jan 28, 2008 at 03:03:33PM +0100, Marco Gerards wrote:
>> 
>> I wanted to wait with this patch until the ATA driver is adapted.  But
>> I won't have time for that this week.  So I can better get this
>> committed and people working on this ;-).  There is some code for ATA,
>> but it was not tested yet.  The main problem here is qemu.
>> 
>> Does someone know if it is possible, at all, to have ATA devices
>> showing up as non-legacy PCI devices in Qemu?  IDE interfaces are
>> placed (and locked) in Legacy mode, meaning default IRQs and IO ports
>> are used.  This means just our old ISA code will be used.  To support
>> non-legacy modes, it would be nice if I could do some testing.  Does
>> someone have suggestions?
>
> Try:
>
> --- qemu-0.9.0+20070816/hw/pc.c~        2007-06-06 18:26:13.000000000 +0200
> +++ qemu-0.9.0+20070816/hw/pc.c 2008-01-28 18:25:00.000000000 +0100
> @@ -676,6 +676,8 @@
>      qemu_irq *cpu_irq;
>      qemu_irq *i8259;
>
> +    pci_enabled = 1;
> +
>      linux_boot = (kernel_filename != NULL);
>
>      /* init CPUs */

The problem isn't that PCI isn't enabled.  The problem is that IDE
devices are in legacy mode...

So you do see the IDE interface using lspci.  One bit can be used to
check if the device is in legacy mode or not.  If it indicates legacy
mode, you have to use some fixed ports that are already present in
ata.c.  Otherwise, you can query the port ranges from the PCI device.
Qemu only supports the latter mode, as it seems.

--
Marco

Re: PCI support

[Robert Millan]

On Mon, Jan 28, 2008 at 07:32:33PM +0100, Marco Gerards wrote:
> > --- qemu-0.9.0+20070816/hw/pc.c~        2007-06-06 18:26:13.000000000 +0200
> > +++ qemu-0.9.0+20070816/hw/pc.c 2008-01-28 18:25:00.000000000 +0100
> > @@ -676,6 +676,8 @@
> >      qemu_irq *cpu_irq;
> >      qemu_irq *i8259;
> >
> > +    pci_enabled = 1;
> > +
> >      linux_boot = (kernel_filename != NULL);
> >
> >      /* init CPUs */
> 
> The problem isn't that PCI isn't enabled.  The problem is that IDE
> devices are in legacy mode...
> 
> So you do see the IDE interface using lspci.  One bit can be used to
> check if the device is in legacy mode or not.  If it indicates legacy
> mode, you have to use some fixed ports that are already present in
> ata.c.  Otherwise, you can query the port ranges from the PCI device.
> Qemu only supports the latter mode, as it seems.

You're right.  Even when PCI is enabled, you still get the same, although it
doesn't look like it at first glance:

    if (pci_enabled) {
        pci_piix3_ide_init(pci_bus, bs_table, piix3_devfn + 1, i8259);
    } else {
        for(i = 0; i < 2; i++) {
            isa_ide_init(ide_iobase[i], ide_iobase2[i], i8259[ide_irq[i]],
                         bs_table[2 * i], bs_table[2 * i + 1]);
        }
    }

I think what you want is to change the hardcoded port numbers in
hw/ide.c:pci_piix3_ide_init():

    ide_init_ioport(&d->ide_if[0], 0x1f0, 0x3f6);
    ide_init_ioport(&d->ide_if[2], 0x170, 0x376);

could that be it?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)

Re: PCI support

[Marco Gerards]

Robert Millan <rmh@aybabtu.com> writes:

> On Mon, Jan 28, 2008 at 07:32:33PM +0100, Marco Gerards wrote:
>> > --- qemu-0.9.0+20070816/hw/pc.c~        2007-06-06 18:26:13.000000000 +0200
>> > +++ qemu-0.9.0+20070816/hw/pc.c 2008-01-28 18:25:00.000000000 +0100
>> > @@ -676,6 +676,8 @@
>> >      qemu_irq *cpu_irq;
>> >      qemu_irq *i8259;
>> >
>> > +    pci_enabled = 1;
>> > +
>> >      linux_boot = (kernel_filename != NULL);
>> >
>> >      /* init CPUs */
>> 
>> The problem isn't that PCI isn't enabled.  The problem is that IDE
>> devices are in legacy mode...
>> 
>> So you do see the IDE interface using lspci.  One bit can be used to
>> check if the device is in legacy mode or not.  If it indicates legacy
>> mode, you have to use some fixed ports that are already present in
>> ata.c.  Otherwise, you can query the port ranges from the PCI device.
>> Qemu only supports the latter mode, as it seems.
>
> You're right.  Even when PCI is enabled, you still get the same, although it
> doesn't look like it at first glance:
>
>     if (pci_enabled) {
>         pci_piix3_ide_init(pci_bus, bs_table, piix3_devfn + 1, i8259);
>     } else {
>         for(i = 0; i < 2; i++) {
>             isa_ide_init(ide_iobase[i], ide_iobase2[i], i8259[ide_irq[i]],
>                          bs_table[2 * i], bs_table[2 * i + 1]);
>         }
>     }
>
> I think what you want is to change the hardcoded port numbers in
> hw/ide.c:pci_piix3_ide_init():
>
>     ide_init_ioport(&d->ide_if[0], 0x1f0, 0x3f6);
>     ide_init_ioport(&d->ide_if[2], 0x170, 0x376);
>
> could that be it?

Perhaps...  But it is still in legacy mode I guess... ;-)

--
Marco

Re: PCI support

[Marco Gerards]

Marco Gerards <mgerards@xs4all.nl> writes:

> 2009-01-28  Marco Gerards  <marco@gnu.org>
>
> 	* bus/pci.c: New file.
>
> 	* include/grub/pci.h: Likewise.
>
> 	* include/grub/i386/pc/pci.h: Likewise.
>
> 	* commands/lspci.c: Likewise.
>
> 	* conf/i386-pc.rmk (pkglib_MODULES): Add `pci.mod' and
> 	`lspci.mod'.
> 	(pci_mod_SOURCES): New variable.
> 	(pci_mod_CFLAGS): Likewise.
> 	(pci_mod_LDFLAGS): Likewise.
> 	(lspci_mod_SOURCES): Likewise.
> 	(lspci_mod_CFLAGS): Likewise.
> 	(lspci_mod_LDFLAGS): Likewise.	

No objections?  Did everyone have a (quick) look at the interfaces?

If I hear nothing, I will commit this patch Friday.

--
Marco

Re: PCI support

[Robert Millan]

On Wed, Jan 30, 2008 at 06:57:38PM +0100, Marco Gerards wrote:
> Marco Gerards <mgerards@xs4all.nl> writes:
> 
> > 2009-01-28  Marco Gerards  <marco@gnu.org>
> >
> > 	* bus/pci.c: New file.
> >
> > 	* include/grub/pci.h: Likewise.
> >
> > 	* include/grub/i386/pc/pci.h: Likewise.
> >
> > 	* commands/lspci.c: Likewise.
> >
> > 	* conf/i386-pc.rmk (pkglib_MODULES): Add `pci.mod' and
> > 	`lspci.mod'.
> > 	(pci_mod_SOURCES): New variable.
> > 	(pci_mod_CFLAGS): Likewise.
> > 	(pci_mod_LDFLAGS): Likewise.
> > 	(lspci_mod_SOURCES): Likewise.
> > 	(lspci_mod_CFLAGS): Likewise.
> > 	(lspci_mod_LDFLAGS): Likewise.	
> 
> No objections?  Did everyone have a (quick) look at the interfaces?

You put grub_pci_read() in an arch-specific file;  is that function really
arch-specific, or only its IO addresses are?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)

Re: PCI support

[Marco Gerards]

Robert Millan <rmh@aybabtu.com> writes:

> On Wed, Jan 30, 2008 at 06:57:38PM +0100, Marco Gerards wrote:
>> Marco Gerards <mgerards@xs4all.nl> writes:
>> 
>> > 2009-01-28  Marco Gerards  <marco@gnu.org>
>> >
>> > 	* bus/pci.c: New file.
>> >
>> > 	* include/grub/pci.h: Likewise.
>> >
>> > 	* include/grub/i386/pc/pci.h: Likewise.
>> >
>> > 	* commands/lspci.c: Likewise.
>> >
>> > 	* conf/i386-pc.rmk (pkglib_MODULES): Add `pci.mod' and
>> > 	`lspci.mod'.
>> > 	(pci_mod_SOURCES): New variable.
>> > 	(pci_mod_CFLAGS): Likewise.
>> > 	(pci_mod_LDFLAGS): Likewise.
>> > 	(lspci_mod_SOURCES): Likewise.
>> > 	(lspci_mod_CFLAGS): Likewise.
>> > 	(lspci_mod_LDFLAGS): Likewise.	
>> 
>> No objections?  Did everyone have a (quick) look at the interfaces?
>
> You put grub_pci_read() in an arch-specific file;  is that function really
> arch-specific, or only its IO addresses are?

IO addresses are Intel only, AFAIK.  Almost all architectures have
mmapped IO.  It's really arch specific.

--
Marco

Re: PCI support

[Robert Millan]

On Wed, Jan 30, 2008 at 09:08:34PM +0100, Marco Gerards wrote:
> Robert Millan <rmh@aybabtu.com> writes:
> 
> > On Wed, Jan 30, 2008 at 06:57:38PM +0100, Marco Gerards wrote:
> >> Marco Gerards <mgerards@xs4all.nl> writes:
> >> 
> >> > 2009-01-28  Marco Gerards  <marco@gnu.org>
> >> >
> >> > 	* bus/pci.c: New file.
> >> >
> >> > 	* include/grub/pci.h: Likewise.
> >> >
> >> > 	* include/grub/i386/pc/pci.h: Likewise.
> >> >
> >> > 	* commands/lspci.c: Likewise.
> >> >
> >> > 	* conf/i386-pc.rmk (pkglib_MODULES): Add `pci.mod' and
> >> > 	`lspci.mod'.
> >> > 	(pci_mod_SOURCES): New variable.
> >> > 	(pci_mod_CFLAGS): Likewise.
> >> > 	(pci_mod_LDFLAGS): Likewise.
> >> > 	(lspci_mod_SOURCES): Likewise.
> >> > 	(lspci_mod_CFLAGS): Likewise.
> >> > 	(lspci_mod_LDFLAGS): Likewise.	
> >> 
> >> No objections?  Did everyone have a (quick) look at the interfaces?
> >
> > You put grub_pci_read() in an arch-specific file;  is that function really
> > arch-specific, or only its IO addresses are?
> 
> IO addresses are Intel only, AFAIK.  Almost all architectures have
> mmapped IO.  It's really arch specific.

Are you sure that makes grub_inl / grub_outl arch-specific ?  They can't be
implemented as wrappers for direct memory access?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)

Re: PCI support

[Marco Gerards]

Robert Millan <rmh@aybabtu.com> writes:

> On Wed, Jan 30, 2008 at 09:08:34PM +0100, Marco Gerards wrote:
>> Robert Millan <rmh@aybabtu.com> writes:
>> 
>> > On Wed, Jan 30, 2008 at 06:57:38PM +0100, Marco Gerards wrote:
>> >> Marco Gerards <mgerards@xs4all.nl> writes:
>> >> 
>> >> > 2009-01-28  Marco Gerards  <marco@gnu.org>
>> >> >
>> >> > 	* bus/pci.c: New file.
>> >> >
>> >> > 	* include/grub/pci.h: Likewise.
>> >> >
>> >> > 	* include/grub/i386/pc/pci.h: Likewise.
>> >> >
>> >> > 	* commands/lspci.c: Likewise.
>> >> >
>> >> > 	* conf/i386-pc.rmk (pkglib_MODULES): Add `pci.mod' and
>> >> > 	`lspci.mod'.
>> >> > 	(pci_mod_SOURCES): New variable.
>> >> > 	(pci_mod_CFLAGS): Likewise.
>> >> > 	(pci_mod_LDFLAGS): Likewise.
>> >> > 	(lspci_mod_SOURCES): Likewise.
>> >> > 	(lspci_mod_CFLAGS): Likewise.
>> >> > 	(lspci_mod_LDFLAGS): Likewise.	
>> >> 
>> >> No objections?  Did everyone have a (quick) look at the interfaces?
>> >
>> > You put grub_pci_read() in an arch-specific file;  is that function really
>> > arch-specific, or only its IO addresses are?
>> 
>> IO addresses are Intel only, AFAIK.  Almost all architectures have
>> mmapped IO.  It's really arch specific.
>
> Are you sure that makes grub_inl / grub_outl arch-specific ?  They can't be
> implemented as wrappers for direct memory access?

No, AFAIK that is not possible.  However, PCI gives you the mmapped IO
addresses we can use, for example for the ATA driver.

--
Marco

Re: PCI support

[Robert Millan]

On Wed, Jan 30, 2008 at 11:17:49PM +0100, Marco Gerards wrote:
> >> IO addresses are Intel only, AFAIK.  Almost all architectures have
> >> mmapped IO.  It's really arch specific.
> >
> > Are you sure that makes grub_inl / grub_outl arch-specific ?  They can't be
> > implemented as wrappers for direct memory access?
> 
> No, AFAIK that is not possible.  However, PCI gives you the mmapped IO
> addresses we can use, for example for the ATA driver.

Why not?

What's wrong with:

grub_uint32_t
grub_inl (grub_uint32_t *addr)
{
  return *addr;
}

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)

Re: PCI support

[Marco Gerards]

Robert Millan <rmh@aybabtu.com> writes:

> On Wed, Jan 30, 2008 at 11:17:49PM +0100, Marco Gerards wrote:
>> >> IO addresses are Intel only, AFAIK.  Almost all architectures have
>> >> mmapped IO.  It's really arch specific.
>> >
>> > Are you sure that makes grub_inl / grub_outl arch-specific ?  They can't be
>> > implemented as wrappers for direct memory access?
>> 
>> No, AFAIK that is not possible.  However, PCI gives you the mmapped IO
>> addresses we can use, for example for the ATA driver.
>
> Why not?
>
> What's wrong with:
>
> grub_uint32_t
> grub_inl (grub_uint32_t *addr)
> {
>   return *addr;
> }

Nothing, except the missing volatile I guess.  This just isn't an IO
port.  So you can't use IO port 0x60 to access the keyboard or so.
But sure, we need an abstraction.


--
Marco

Re: PCI support

[Robert Millan]

On Thu, Jan 31, 2008 at 09:51:38AM +0100, Marco Gerards wrote:
> >
> > grub_uint32_t
> > grub_inl (grub_uint32_t *addr)
> > {
> >   return *addr;
> > }
> 
> Nothing, except the missing volatile I guess.  This just isn't an IO
> port.  So you can't use IO port 0x60 to access the keyboard or so.
> But sure, we need an abstraction.

AT keyboard is too arch-specific, but ATA and PCI aren't.  Anyway, I suppose
it's no big deal as we can always move the code later.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)

Re: PCI support

[Marco Gerards]

Robert Millan <rmh@aybabtu.com> writes:

> On Thu, Jan 31, 2008 at 09:51:38AM +0100, Marco Gerards wrote:
>> >
>> > grub_uint32_t
>> > grub_inl (grub_uint32_t *addr)
>> > {
>> >   return *addr;
>> > }
>> 
>> Nothing, except the missing volatile I guess.  This just isn't an IO
>> port.  So you can't use IO port 0x60 to access the keyboard or so.
>> But sure, we need an abstraction.
>
> AT keyboard is too arch-specific, but ATA and PCI aren't.  Anyway, I suppose
> it's no big deal as we can always move the code later.

Right.  Committed.

--
Marco

Re: PCI support

[Yoshinori K. Okuji]

On Wednesday 30 January 2008 18:57, Marco Gerards wrote:
> No objections?  Did everyone have a (quick) look at the interfaces?
>
> If I hear nothing, I will commit this patch Friday.

You didn't check the return value from a hook. Besides that, okay for me.

Thanks,
Okuji

Re: PCI support

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Wednesday 30 January 2008 18:57, Marco Gerards wrote:
>> No objections?  Did everyone have a (quick) look at the interfaces?
>>
>> If I hear nothing, I will commit this patch Friday.
>
> You didn't check the return value from a hook. Besides that, okay for me.

Right, I should do that.  Before I commit :-)

--
Marco

PCI support

[Kevin Fry]

I'm trying to setup a PCI bridge on our 8260 board here, and was
wondering if a driver exists for the Tundra Powerspan. We're using Hard
Hat Linux 2.0 JE

If I write my own drivers, where would the board-specific PCI routines
go in the kernel code? I found the function prototypes in linux/pci.h,
but couldn't find any pci code itself.  Does HHL 2.0 JE support PCI?

Thanks!
Kevin Fry


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: PCI support

[Dan Taylor]

The code would have to be added in one or two places.  First, update
the PCI code in .../linux/arch/ppc/kernel; your hardware may be like
a sandpoint, but could be chrp.  If, as I suspect, the PowerSPAN is
NOT a transparent PCI-PCI bridge, you will also need to modify the
.../linux/drivers/pci/pci.c code that handles child busses.  I usually
put an "else if" inside the "for" loop after "pcibios_fixup_bus()".
That way the existing code handles any transparent bridges, then I can
specify an implementation-dependent bridge, either by bus & device, by
checking checking the vendor and device IDs, or both.  You have to do
all of the same things that the transparent bridge does, so just copy,
paste, and edit the code inside that "if".  You need to have the kernel
code done first, since that will have the config cycle handling and
memory/io space mapping.

Kevin Fry wrote:
>
> I'm trying to setup a PCI bridge on our 8260 board here, and was
> wondering if a driver exists for the Tundra Powerspan. We're using Hard
> Hat Linux 2.0 JE
>
> If I write my own drivers, where would the board-specific PCI routines
> go in the kernel code? I found the function prototypes in linux/pci.h,
> but couldn't find any pci code itself.  Does HHL 2.0 JE support PCI?
>
> Thanks!
> Kevin Fry
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/