PCI howto?

17 posts / 0 new
Last post
billt
billt's picture
Offline
Last seen: 1 year 5 months ago
Joined: 2011-02-04 18:54
PCI howto?

Hi All, it's been quite a while, and I need reminded on how to get access to a PCI card hardware for trying to write a driver.

I'm working on getting my XE up and running again after a handful of years in storage, and do not yet have my OS all up to date and the SDK installed. I think I may have botched the 4.1u2 stage and want to go back and redo the OS instal to make sure it's good before I go very far with anything else.

But I would like to know where to look for this kind of info once that's ready and running.

(2013/06/14added '?' to thread title in case there is confusion that I was posting a tutorial not asking for one)

hypex
hypex's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 2011-09-09 16:20
You need to use the PCI

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. :-)

  1. // VIA USB2 Fix
  2.  
  3. #include <stdio.h>
  4. #include <proto/exec.h>
  5. #include <proto/dos.h>
  6. #include <proto/expansion.h>
  7. #include <expansion/pci.h>
  8.  
  9. struct PCIDevice *USB2 = NULL;
  10. struct Library *ExpansionBase;
  11. struct PCIIFace *IPCI;
  12.  
  13. void clean_up()
  14. {
  15. if (USB2) IPCI ->FreeDevice(USB2);
  16. IExec->DropInterface((struct Interface *)IPCI);
  17. IExec->CloseLibrary(ExpansionBase);
  18. }
  19.  
  20. int main(int argc, char *argv[])
  21. {
  22. UBYTE Data;
  23.  
  24. printf("VIA USB2:\n");
  25.  
  26. /* Open required OS resources, get handle to specified PCI device. */
  27. ExpansionBase = IExec->OpenLibrary("expansion.library", 50L);
  28. if (!ExpansionBase)
  29. {
  30. printf("\nCould not open expansion.library.\n\n");
  31. return 20;
  32. }
  33.  
  34. IPCI = (struct PCIIFace *)IExec->GetInterface(ExpansionBase, "pci", 1, NULL);
  35. if (!IPCI)
  36. {
  37. printf("\nUnable to obtain PCI interface.\n\n");
  38. IExec->CloseLibrary(ExpansionBase);
  39. return 20;
  40. }
  41.  
  42. USB2 = IPCI->FindDeviceTags(
  43. FDT_VendorID, 0x1106,
  44. FDT_DeviceID, 0x3104,
  45. TAG_DONE);
  46.  
  47. if (!USB2)
  48. {
  49. printf("\nCannot find VIA USB2 device.\n\n");
  50. clean_up();
  51. return 5;
  52. }
  53.  
  54. if ((USB2->ReadConfigByte(PCI_REVISION_ID) & 0xF0) == 0x60)
  55. {
  56. printf("Found VT6212\n");
  57.  
  58. Data = USB2->ReadConfigByte(0x4B);
  59. printf("Data: %2x\n",Data);
  60. if (Data & 0x20)
  61. {
  62. printf("Timer set\n");
  63. }
  64. else
  65. {
  66. printf("Timer clear\n");
  67. USB2->WriteConfigByte(0x4B, Data | 0x20);
  68. Data = USB2->ReadConfigByte(0x4B);
  69. }
  70.  
  71. Data = USB2->ReadConfigByte(0x49);
  72. printf("Data: %2x\n",Data);
  73. if (Data & 0x20)
  74. {
  75. printf("Data set\n");
  76. USB2->WriteConfigByte(0x4B, Data & (~0x20));
  77. Data = USB2->ReadConfigByte(0x4B);
  78. }
  79. else
  80. {
  81. printf("Data clear\n");
  82. }
  83. }
  84.  
  85. Data = USB2->ReadConfigByte(0x6E);
  86. printf("Data: %2x\n",Data);
  87. if (Data & 0x08)
  88. {
  89. printf("Data set\n");
  90. }
  91. else
  92. {
  93. printf("Data clear\n");
  94. USB2->WriteConfigByte(0x6E, Data | 0x08);
  95. Data = USB2->ReadConfigByte(0x6E);
  96. }
  97.  
  98. clean_up();
  99. return 0;
  100. }
billt
billt's picture
Offline
Last seen: 1 year 5 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?

hypex
hypex's picture
Offline
Last seen: 1 month 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. :-)

billt
billt's picture
Offline
Last seen: 1 year 5 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.

hypex
hypex's picture
Offline
Last seen: 1 month 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.

billt
billt's picture
Offline
Last seen: 1 year 5 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.

Belxjander
Belxjander's picture
Offline
Last seen: 8 years 3 months 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

Hans
Hans's picture
Offline
Last seen: 2 months 3 weeks ago
Joined: 2010-12-09 22:04
@billt The A1-XE PCI-to-PCIe

@billt

The A1-XE PCI-to-PCIe bridge situation is a bit more complicated. UBoot does, in fact, scan for devices behind a PCI-to-PCI(e) bridge, but leaves the bridge in a disabled state. As a result the cards are visible, but aren't usable by drivers since access attempts aren't forwarded to the card itself. Both Picasso96 and the RadeonHD driver check for bridges between a graphics card and the CPU, and enable MMIO and IO access across the bridge. The RadeonHD driver also enables prefetching on PEX8112 bridges, to improve transfer speeds a bit. This is how I managed to start working on the RadeonHD driver before motherboards like the Sam460ex were available.

There are two major problems with the UBoot on the A1-XE:
- It won't configure the IRQ line for cards behind a bridge. The correct line depends upon which PCI slot the bridge is plugged in to, so this is something that UBoot is supposed to handle (the OS doesn't/shouldn't handle motherboard specific stuff)
- It won't scan for devices behind a bridge that's behind another bridge. This means that you can't use PCI-to-PCIe bridges with the 66 MHz PCI slot, as that slot is already behind a bridge. Needless to say, this sucks when it comes to using PCIe graphics cards, as the 66 MHz slot provides double the bandwidth of the 33 MHz ones

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
http://keasigmadelta.co.nz/ - more of my software.

billt
billt's picture
Offline
Last seen: 1 year 5 months ago
Joined: 2011-02-04 18:54
Thank you for your insight,

Thank you for your insight, Hans. I'll add these issues to the uboot project todo list as well.

hypex
hypex's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 2011-09-09 16:20
@billt you ask some

@billt

you ask some interesting quextions.

I have my moments. :-)

I'm also interested in power managment potential further down the road,

Speaking of the A1 lacks proper ACPI circuitry or in the least support from UBoot. AFAIK the best we can achieve is "It's now safe to turn off your comnputer." :-)

The X1000 also shows a lack of support as Linux kernels fail to shut the machine down. Even though OS4 can.

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.

I quite agree. The devuice driver should do it's job as intended. What's needed is another driver that can make sure the infrastructure it is looking for exists in the system. As it stands this is OS4's job. Perhaps it needs some help from UBoot to perform this job. I don't know. But either way we seem to be heading towards a UBoot update project. :-)

hypex
hypex's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 2011-09-09 16:20
@Hans UBoot is supposed to

@Hans

UBoot is supposed to handle (the OS doesn't/shouldn't handle motherboard specific stuff)

Well this is interesting. I thought OS4 took total control over UBoot and kicked it to the kerb, then set up its own map for IRQs and what not?

How does this relate to the IRQ setting in UBoot? I only see four lines or IRQs listed there.

Needless to say, this sucks when it comes to using PCIe graphics cards, as the 66 MHz slot provides double the bandwidth of the 33 MHz ones

So this is why the AGP slot is next to useless? What about that AGP x2 setting? And can the 66Mhz slot still be used in "single" mode?

@All

Regardless of what UBoot supports in the current version, it can be worked around. With limitations. If it's possible that a bridge or other card could be set up by poking into the PCI space then a UBoot script could be written to go through the list and set it up. Depending on how good its conditional support and scanning functions are.

billt
billt's picture
Offline
Last seen: 1 year 5 months ago
Joined: 2011-02-04 18:54
But either way we seem to be

But either way we seem to be heading towards a UBoot update project. :-)

http://sourceforge.net/projects/uboot-amigaone/

Just need more time to keep it going :)

Hans
Hans's picture
Offline
Last seen: 2 months 3 weeks ago
Joined: 2010-12-09 22:04
Well this is interesting. I

Well this is interesting. I thought OS4 took total control over UBoot and kicked it to the kerb, then set up its own map for IRQs and what not?

How does this relate to the IRQ setting in UBoot? I only see four lines or IRQs listed there.


OS4 does take over control, but how do you expect OS4 to know which IRQ line is connected to which slot on the motherboard, and which card is in that slot? Figuring that out is hardware (motherboard) specific. It's the firmware's job (a.k.a., UBoot) to detect hardware and do the low-level initialization. The OS gets the list of hardware from UBoot.

Needless to say, this sucks when it comes to using PCIe graphics cards, as the 66 MHz slot provides double the bandwidth of the 33 MHz ones

So this is why the AGP slot is next to useless? What about that AGP x2 setting? And can the 66Mhz slot still be used in "single" mode?

I'm not sure what you mean. The A1-XE's AGP slot runs at 66 MHz, so it's a good step up from plugging a PCI graphics card into one of the 33 MHz slots.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
http://keasigmadelta.co.nz/ - more of my software.

hypex
hypex's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 2011-09-09 16:20
@Hans OS4 does take over

@Hans

OS4 does take over control, but how do you expect OS4 to know which IRQ line is connected to which slot on the motherboard, and which card is in that slot?

I expect it to work that out in the kernel or expansion.library just like a real Amiga. Since Exec knew how to map the interupts to what IRQ. After all, once the Kickstart loads and merged in memory, it would work like any other Amiga.

But what about those UBoot IRQ varablles, do they also affect the lines?

I'm not sure what you mean.

I've read somewhere that the AGP slot didn't exactly run at 2xAGP speed and wasn't much better than PCI. Though it may have been in Linux which seesm to lack competent driver l;ike in OS4.

Hans
Hans's picture
Offline
Last seen: 2 months 3 weeks ago
Joined: 2010-12-09 22:04
OS4 does take over control,

OS4 does take over control, but how do you expect OS4 to know which IRQ line is connected to which slot on the motherboard, and which card is in that slot?

I expect it to work that out in the kernel or expansion.library just like a real Amiga. Since Exec knew how to map the interupts to what IRQ. After all, once the Kickstart loads and merged in memory, it would work like any other Amiga.

Okay, but Exec has absolutely no clue which IRQ line+pin is physically connected to which PCI slot. In fact, the OS doesn't really know (or care) which physical PCI slot a PCI device is plugged in to. Only the BIOS/firmware (UBoot on the A1-XE) knows the routing of the interrupts from devices to the system's interrupt controller. This is why UBoot needs to correctly set each PCI card's interrupt registers, so that the OS knows what's connected to what.

At present, UBoot for the A1-XE doesn't do this for cards behind a PCI-to-PCI(e) bridge.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
http://keasigmadelta.co.nz/ - more of my software.

hypex
hypex's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 2011-09-09 16:20
This is why UBoot needs to

This is why UBoot needs to correctly set each PCI card's interrupt registers, so that the OS knows what's connected to what.

I wonder if this is why certain USB2 cards fail under OS4? As I understand the A1/UBoot is not ACPI compliant and a USB2 card I have needs an ACPI compliant computer to work with. I've also read it really needs a a computer that already has USB2 but that goes against the point of the card in my case. But what is needs most is to have only one single interrupt line dedicated to it. I wonder if this is being violated?

Then again, one card I tried worked in Linux, but not OS4. So I wonder if OS4 is messing up the interrupt assignments? Or the EHCI driver is just buggy still. But I'm off topic now.

Log in or register to post comments