PCI howto?

Tue, 2013-06-11 19:33

#2

hypex

Offline

Last seen: 4 months 2 weeks ago

Joined: 2011-09-09 16:20

You need to use the PCI interface features of expansion.library. There is an example but it's kinda complicated and uses ASM. Essentually it's programmed in a kind of OOP style. You are returned a function base with which you access read and write functions. Quite neat really. Here's some modified example code I did when attempting to write a USB fix. Didn't work for me but demonstrates how to locate and access a PCI device. :-)

//  VIA USB2 Fix
 
#include <stdio.h>
#include <proto/exec.h>
#include <proto/dos.h>
#include <proto/expansion.h>
#include <expansion/pci.h>
 
struct PCIDevice *USB2 = NULL;
struct Library *ExpansionBase;
struct PCIIFace *IPCI;
 
void clean_up()
{
  if (USB2) IPCI ->FreeDevice(USB2);
  IExec->DropInterface((struct Interface *)IPCI);
  IExec->CloseLibrary(ExpansionBase);
}
 
int main(int argc, char *argv[])
{
  UBYTE Data;
 
  printf("VIA USB2:\n");
 
  /* Open required OS resources, get handle to specified PCI device. */
  ExpansionBase = IExec->OpenLibrary("expansion.library", 50L);
  if (!ExpansionBase)
  {
    printf("\nCould not open expansion.library.\n\n");
    return 20;
  }
 
  IPCI = (struct PCIIFace *)IExec->GetInterface(ExpansionBase, "pci", 1, NULL);
  if (!IPCI)
  {
    printf("\nUnable to obtain PCI interface.\n\n");
    IExec->CloseLibrary(ExpansionBase);
    return 20;
  }
 
  USB2 = IPCI->FindDeviceTags(
      FDT_VendorID, 0x1106,
      FDT_DeviceID, 0x3104,
      TAG_DONE);
 
  if (!USB2)
  {
    printf("\nCannot find VIA USB2 device.\n\n");
    clean_up();
    return 5;
  }
 
  if ((USB2->ReadConfigByte(PCI_REVISION_ID) & 0xF0) == 0x60)
  {
    printf("Found VT6212\n");
 
	Data = USB2->ReadConfigByte(0x4B);
	printf("Data: %2x\n",Data);
	if (Data & 0x20)
	{
	  printf("Timer set\n");
	}
	else
	{
	  printf("Timer clear\n");
	  USB2->WriteConfigByte(0x4B, Data | 0x20);
	  Data = USB2->ReadConfigByte(0x4B);
	}
 
	Data = USB2->ReadConfigByte(0x49);
	printf("Data: %2x\n",Data);
	if (Data & 0x20)
	{
	  printf("Data set\n");
	  USB2->WriteConfigByte(0x4B, Data & (~0x20));
	  Data = USB2->ReadConfigByte(0x4B);
	}
	else
	{
	  printf("Data clear\n");
	}
  }
 
	Data = USB2->ReadConfigByte(0x6E);
	printf("Data: %2x\n",Data);
 	if (Data & 0x08)
	{
	  printf("Data set\n");
	}
	else
	{
	  printf("Data clear\n");
      USB2->WriteConfigByte(0x6E, Data | 0x08);
      Data = USB2->ReadConfigByte(0x6E);
	}
 
  clean_up();
  return 0;
}

Thu, 2013-06-13 18:02

(Reply to #2) #3

billt

Offline

Last seen: 2 years 2 months ago

Joined: 2011-02-04 18:54

Thanks Hypex! One thing I'd

Thanks Hypex!

One thing I'd like to do is to make a "driver" (if that's the right name for this) for PCI to PCI-Express bridges such as PEX8111, PEX8112, Pericom, etc. as there are some riser style slot adapters to allow PCI motherboards like AmigaOneXE to use standard PCI-Express cards, and they are relatively cheap now. What I'd lik ethis "driver" to do is to load up and look to the other side, if any PCI-Express card is there then scan and elaborate that and add it to the AmigaOS device database so that is now known to OS4 and it can then work with a driver for that PCI-Express card. Similar for a PCI_Express switch, PCI-PCI bridge, etc. But first a PCI to PCI-Express bridge as I'd like to play around with some things there.

While I intend to meddle with improving Uboot, that would be Linux only until I have something worthy of talking to Hyperion about Amiga-ifying such a uboot image to run OS4 on top of that, and something like this inside OS4 would most likely let me tinker with PCI-Express sooner than getting an improved uboot running OS4.

So, what functions in Expansion should I read up on for adding devices to the tree?

And once I have something compiled to try and load/run as a driver, how do I do that for somethng not a monitor, not a gfx card, etc? We used to have an Expansion drawer, which I no longer find. Is Kickstart drawer the new place for such things? Is there anything special to compile a kickstart module compared to something else?

Mon, 2013-06-17 19:14

(Reply to #3) #4

hypex

Offline

Last seen: 4 months 2 weeks ago

Joined: 2011-09-09 16:20

Hi again. Okay I see what

Hi again.

Okay I see what you need. So I take it that the adaptor won't work out of the box then? And won't automatically activate any PCI-X card inserted?

The X1000 is known to work with PCI/X bridge cards and AFAIK without any driver needed.

Before you get to update UBoot, if that is at all possible being the lack of interest from any official source, you could actually program the PCI registers via UBoot scripts. This has been done to enable a VIA SATA chipset in UBoot.

Looking at the Expansion API I can't see a way to add any PCI devices to the list; it looks like it was designed to access them from an existing list. I think it would be this way as OS4 would check out the expansions itself and create its own list which is understandable. But if it found a PCI bridge card that should come up in the list and be readable in Ranger for example.

Your right about lack of Expansion. Although OS4 doesn't have a ROM based Kickstart and so really needs Expansion for drivers it has indeed been taken out. I don't know why, how else do we BindDrivers? ;-)

I'm not sure exactly what a Kickstart module needs but I know that devices are interchangeable. So it looks like it gets opened like any standard library or device that then adds itself to the system. Of course they have to be added to the Kicklayout list which can be a pain. Failing that there is WBStartup or what's left of it and startup scripts which are more messy. :-)

Sat, 2013-06-22 02:44

(Reply to #4) #5

billt

Offline

Last seen: 2 years 2 months ago

Joined: 2011-02-04 18:54

Yea, I have an AmigaOne XE,

Yea, I have an AmigaOne XE, which doesn't scan across bridges. It will tell me the bridge is there, but anything on the other side is absent. I understand this to be a limitation of Uboot for the SE/XE/MicroA1 versions of uboot. And while I'd like to correct that, the uboot update task will be a Linux thing (and is why I want Linux installed parallel on same hard drive per thread at amigaworld with Geri) as I cannot make an OS4 uboot image myself to work with OS4, thus I have added this thread to learn to hack those missing other-side-of-the-bridge devices back into the list in OS4 to enumerate and attach drivers to after OS4 is booted up. Or perhaps in a kickstart module, but I think that is still after the uboot device tree handoff to OS4.

Hrmm. So it's a tricky situation. I want to hack on PCI-Express devices, and all I have is an XE board where OS4 can't see it, and it may not be addable.

As I understand, Hans did something in his Radeon drivers to cross a bridge, but that may be that his driver is assigned for attachment to a PCI-Express bridge with the assumption that there is no tanother choice to be over there, and his driver configures the bridge and then the assumed Radeon on the other side.

I'm going to have to find time to stare at things. And find where I can ask Hans if he has any advice.

Sat, 2013-06-22 18:38

(Reply to #5) #6

hypex

Offline

Last seen: 4 months 2 weeks ago

Joined: 2011-09-09 16:20

Okay, well that is a good

Okay, well that is a good start if the bridge is recognised as a device. You could then locate the bridge in OS4 in your driver and activate it. However I can see that a rescan of the bus would be needed. Or at least PCI Kickstart modules reloaded ro pick up extra devices. Of course they still need to find them on the bus.

Which bring me to my next point, what sort of cards do you want to use? Given you are talking about a limitation of Uboot, in what way? Does the bridge have a ROM that needs to be execuited? And does UBoot only execute the VGA ROM BIOS?

Apart from that my second guess is that you want to add a PCIe card with a drive ot SATA controller to boot off? Then I would understand why you need UBoot to support it. Is this a standard featuture of modern PC mainboards? BTW, does UBoot list only the bridge during a PCI scan?

On X1000 again, IIRC I read about a PCI to PCIe bridge with a network installed. So a non VGA example and going in the opposite direction - PCI to PCIe. Where as you need the other way.

Tue, 2013-06-25 03:37

(Reply to #6) #7

billt

Offline

Last seen: 2 years 2 months ago

Joined: 2011-02-04 18:54

you ask some interesting

you ask some interesting quextions.

From what I understand, uboot for A1XE/SE/microA1 does not enumerate pci or pci-express devices on the other side of a bridge. So they are absent from a device tree, not configured in any way, and effectively completely unknown to the system.

I'm basically thinking of any device in generic sense. with rom, without, sata, audio, SD reader, whatever. I have a few sata cards to play with among other things, an SD reader, and a multifunction device that I hope to put together someday. I think it would be interesting to boot from sata or SD cards. other things won't be actively used or driven by uboot, but it would be nice to have them present in the system device tree, and to be configured to whatever degree that a BIOS does.

I'm also interested in power managment potential further down the road, which would need to be able to read and restore saved device states. While some aspects of this are likely beyond the MAI motherboard capabilities, you gotta start somewhere...

From my point of view, a driver should not be responsible for scanning the entire drvice tree to find bridges, know how to configure bridges and then enumerate everything that may be on the other side, including items unrelated to my device driver. For example, an SD driver should look for the SD device, not look for a bridge and know how to scan across a bridge. It should not need to know about bridges, as there might not be a bridge involved, such as plugging it directly into a pci-express slot of x1000 or sam460... Or, there could be a heirarchy of bridges for some reason, and SD driver should not need to go on a major quest to find its device. This system mapping should be someone else's job.

Sun, 2013-08-18 10:23

(Reply to #7) #8

Belxjander

Offline

Last seen: 9 years 3 days ago

Joined: 2011-02-25 11:53

@BillT: I agree... a driver

@BillT: I agree... a driver for bridge handling seperate from other functional drivers,

My only question would be... is it possible to trigger the driver as a run-once-at-Kickstart-Init-From-Loader since I have been playing around with Kickstart setups a little bit.

I have currently been adding extra FileSystem modules and relocating things from the kickstart Folder into the general System [FileSystems only at this point but it works...]

Apparently the system loader only requires a path where SYS: is prefixed.

As long as the files are on the boot volume it is possible to path and load them from anywhere,

So putting ALL devices in Devs: and mapping them as "Devs/blah.device" instead of "Kickstart/blah.device" would appear to be plausible.

Adding an additional pciebridge.resource into the Kickstart/ tree and having it prepare and then soft-reset with AmigaOS4 running its own enumeration of devices?

Would that then map the devices after the bridge with their own drivers?

Something to consider, I only have access to a sam440ep-flex myself so can't answer any A1XE limitation questions.
I would suggest experimenting with a basic setup that boots and have 2 setups...

One for development and everyday... and a seperate boot option to experiment with.

That is how I am playing around with KickLayout... and finding few if any problems beyond my own mis-spellings

Tue, 2013-08-20 05:31

(Reply to #8) #9