OSDev.org

Hello all,

This is my first post on OSDev.org. If this community is not the best place for this post, could someone please suggest a better-suited forum?

My colleagues and I are developing a PCIe (legacy endpoint), FPGA-based, custom expansion ROM, IDE controller. We have implemented our expansion ROM based upon the BIOS Enhanced Disk Drive Specification-4 (EDD-4). We have confirmed that our expansion ROM INT 0x13 responses are similar to those returned by a commercial IDE controller.

Our expansion ROM is setup with a Boot Connection Vector (BCV). The BCV hooks INT 0x13 so that we can implement the functions specific to our controller. During boot, BIOS makes INT 0x13 calls and we handle them per EDD-4. BIOS loads the MBR and jumps into it, passing control to the bootloader and then the kernel. Linux makes a variety of calls using our INT 0x13 function, all of them complete successfully. It is not until the kernel modules begin to load and initialize that boot fails.


We are testing on Ubuntu 12.04 LTS (kernel 3.2.24). We have three scenarios to present, with the hard drives defined as follows:
Disk A has Ubuntu installed behind GRUB (installed using mobo controller).
Disk B is formatted as ext4, has no OS installed, and has a few test files on it.

Scenario 1: (Please see attached: dmesg.txt and lspci.txt.)
For this scenario, we have Disk A connected to the mobo controller and Disk B connected to our controller. Disk A is set as the primary boot device in BIOS. Disk A will successfully boot, but Disk B is not accessible within Linux. Our controller is connected to PCI bus 1 and is represented as the Xilinx IDE Interface in lspci.txt. From dmesg.txt, it is apparent that the Linux driver, pata_acpi, disables our PCI interrupt (time index: 1.980056) and lspci.txt indicates that bus mastering (which is supported: prog-if 0x85) is being disabled. One other thing to note, the proper driver for our controller is ata_piix, not pata_acpi.

Scenario 2:
For this scenario, we have Disk A connected to the mobo controller and Disk B connected to our controller. Disk A is set as the primary boot device in BIOS. Where scenario 2 differs from scenario 1 is that we configure our controller to falsely report the status register (0x7F, no drive attached) when BIOS first interrogates our controller (BIOS only seems to interrogate our controller once during POST.); in subsequent calls we accurately return the status register. What we are seeing is that BIOS interrogates the controller within milliseconds after power-on and sees that no drive is attached and then continues to boot Linux from Disk A. Linux is able to successfully setup our controller (using ata_piix) and we are able to access it within Linux. So in essence, advertising initially no drive attached forces BIOS to bypass our controller early on in POST, but allows Linux to interact with the controller once a healthy status has been registered a few seconds later.

Scenario 3:
For this scenario, we have Disk A connected to our controller with no other hard drives connected to the system. Disk A is set as the primary boot device in BIOS. With this setup, the systems gets through BIOS POST, then executes the MBR, which in turn loads GRUB, which then loads the kernel. Boot fails when the kernel tries to mount the root file system with error message: "Gave up waiting for root device. ALERT! /dev/disk/by-uuid/... does not exist".


We are currently searching the Linux sources for any indication as to why the pata_acpi driver is being assigned (as opposed to ata_piix) and why our PCI interrupt is being disabled. If anyone in the community has any hints as to why this is happening we would greatly appreciate it.




Regards,

Eric

Hi,

eb wrote:We are currently searching the Linux sources for any indication as to why the pata_acpi driver is being assigned (as opposed to ata_piix) and why our PCI interrupt is being disabled. If anyone in the community has any hints as to why this is happening we would greatly appreciate it.

I'd assume that it's not using the driver designed specifically for ATA devices built into certain Intel chipsets because your ATA controller is not built into a suitable Intel chipset (and not built into any chipset at all).

As far as I know it should be using either "pata_acpi" or "ata_generic"; but I'm not sure what the difference between these is.


Cheers,

Brendan

Thank you for your reply Brendan.

Re-evaluating that assumption, led me to test a commercial equivalent to what we are trying to emulate: http://www.startech.com/Cards-Adapters/ ... rd~PEX2IDE.

Using the StarTech board, I installed Ubuntu and observed how the controller was setup. The relevant pci and lspci segments are listed below:

[ 0.941911] pci 0000:01:00.0: [197b:2368] type 0 class 0x000101
[ 0.941932] pci 0000:01:00.0: reg 10: [io 0xe040-0xe047]
[ 0.941941] pci 0000:01:00.0: reg 14: [io 0xe030-0xe033]
[ 0.941951] pci 0000:01:00.0: reg 18: [io 0xe020-0xe027]
[ 0.941960] pci 0000:01:00.0: reg 1c: [io 0xe010-0xe013]
[ 0.941970] pci 0000:01:00.0: reg 20: [io 0xe000-0xe00f]
[ 0.941988] pci 0000:01:00.0: reg 30: [mem 0xfe500000-0xfe50ffff pref]
[ 0.942047] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
[ 1.005200] pci_bus 0000:01: resource 0 [io 0xe000-0xefff]
[ 1.005202] pci_bus 0000:01: resource 1 [mem 0xfe500000-0xfe5fffff]
[ 1.375889] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[ 2.139845] pata_acpi 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 2.139860] pata_acpi 0000:01:00.0: setting latency timer to 64
[ 2.139868] pata_acpi 0000:01:00.0: PCI INT A disabled
[ 2.500964] pata_jmicron 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 2.500988] pata_jmicron 0000:01:00.0: setting latency timer to 64

01:00.0 IDE interface: JMicron Technology Corp. JMB368 IDE controller (prog-if 85 [Master SecO PriO])
Subsystem: JMicron Technology Corp. JMB368 IDE controller
Flags: bus master, fast devsel, latency 0, IRQ 16
I/O ports at e040
I/O ports at e030
I/O ports at e020
I/O ports at e010
I/O ports at e000
Expansion ROM at fe500000 [disabled] [size=64K]
Capabilities: [68] Power Management version 2
Capabilities: [50] Express Legacy Endpoint, MSI 01
Capabilities: [70] MSI: Enable- Count=1/1 Maskable- 64bit-
Kernel driver in use: pata_jmicron
Kernel modules: pata_jmicron

The StarTech dmesg sequence seems to match up with our controller's dmesg sequence. The main difference being that the StarTech controller progresses from the pata_acpi driver to a manufacturer specific driver: pata_jmicron (the StarTech board does have a JMicron controller). The pata_acpi driver needs to be disabled before the new driver (pata_jmicron) can be brought online, which explains: "pata_acpi 0000:01:00.0: PCI INT A disabled"

At this point, my guess is that we need to emulate the PCI configuration header of the JMicron controller in order to be assigned the correct kernel driver.

Also, assuming pata_acpi can work without a manufacturer specific driver, I have a better heading into the Linux sources to track down the root cause.


Regards,

Eric

eb wrote:the proper driver for our controller is ata_piix, not pata_acpi

You are stupid..... try reading the first line of Linux/drivers/ata/ata_piix.c ....

ata_piix.c - Intel PATA/SATA controllers

You are not building an Intel IDE Controller.

Linux/drivers/ata/ata_generic.c has the following:

{ PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_IDE << 8, 0xFFFFFF00UL),
.driver_data = ATA_GEN_CLASS_MATCH },

You should be designing your controller to work with ata_generic and pata_acpi.