Bay Trail E38xx ERRATA

[BBerg7]

First of all, as a background, I have programmed low level hardware for the PC architecture since the birth of the PC. Furthermore I have written expansion BIOS since middle of 1980 and written BIOS since the the middle of 1990. May I add that I have developed these from scratch all by myself and entirely in assembly language.

With that said, lets focus on the problem and understand why these problems are ERRATA.

There are two problems with SATA.

1. The IRQs from the SATA IDE emulator are inverted. When I refer to IRQs below it's from the 8259 interrupt controller perspective, i.e. high level for PCI IRQs and high edge triggered IRQ for legacy IRQs.
2. The alternate status register clears pending interrupts status (negates IRQ) and thus violates the ATA/ATAPI standard.

The IRQ inversion is very severe. In native IDE mode the IRQ level goes low after command. Thus no interrupt is generated. Pending interrupts are negated when reading the IDE status registers. In this case it negates the IRQ even when the alternate status register is read, thus violating the ATA/API standard.

This causes an never ending interrupt storm in native IDE mode, as the normal action of reading the IDE status register, negates the interrupt as it should according to ATA/ATAPI standard. However, as the root of the signal is wrong polarity, the IDE status read causes the IRQ to stay high instead of going low. The result is a never ending loop in the interrupt service routine, as the interrupt are still active when issuing end of interrupt command to the interrupt controller. This eats the CPU stack space until it's exhausted and the CPU hangs.

For the legacy IDE mode it's more harmless. In legacy mode the IDE command will time out and the next command will generate an interrupt for the previous command, due to the reading of the status register as part of the command sequence. See picture below. The top is a normal legacy IDE IRQ generation. The bottom is Bay Trail legacy IDE generation.

You don't need to go to the technical details of this. The bottom line is that the Bay Trail chip when using any boot loader with our without FSP, will not work in neither legacy or native IDE mode. This is severe, as even though we do some work around in the BIOS or boot loader, the OS will not be able to use the SATA interface as it's broken and thus do not work according to the specification (which is a requirement from the OS).

The IDE interface was adopted as a standard in November 1990 and Intel has violated this standard as neither IDE IRQs or alternate status register adhere to the well proven standard. As we have followed BWG, EDS and other documents to the letter and it behaves as stated above, it's indeed a severe ERRATA.

However, this works in the other vendors BIOS. It's a requirement from Intel that the BIOS should be able to revert to legacy IDE mode by a setup option. The problem is that the settings needed for the IRQs to work is not documented and only known by some people in the inner circle of Intel developers and BIOS vendors.

Thus this should be reported as an ERRATA since the chip behave this way and the workaround is not documented. There are 2 solutions to fix this.

1. Fix the problem in hardware (well IDE has worked out of the box since 1990, so it should work on Bay Trail as well).

2. Publish the workaround.

Berth-Olof Bergman

Winzent Technologies

[SZann]

Are you saying that the two irq lines are at a high logic level when nothing is happening, and go low when there is an event to be signaled to the microprocessor ?

In that case they seem to work as normal low level sensitive interrupts (not edge triggered).

Can't you tell the 8259 that the ide irq inputs are level sensitive and not edge triggered ?

Regarding the never ending loop, you should mask the interrupts whose priority is equal or lower than the ide interrupt (or do something equivalent).

[BBerg7]

The IDE IRQs should go from low to high. In native IDE mode it's an PCI IRQ that is active low on the bus, but high when feed to the interrupt controller. In IDE legacy mode there are IRQ14 and IRQ15 that are triggered on the low to high edge.

The read of the IDE status register, negates the IRQ and should normal return the IRQ to low level in both native and legacy IDE modes. In native mode (with right polarity), if you skip reading the IDE status register and writes EOI to the interrupt controller(s), the IRQ will remain high level and thus be active. Thus you will have a new interrupt pending after the EOI, causing in interrupts storm that never ends.

In this case, the polarity is reversed, so reading the interrupt status register negates the IRQ, but because it's low (reversed) it goes high and causes the same result as ignoring to read the IDE status register in the interrupt service routine.

The bottom line, is that the IRQs in IDE mode within the chip are reversed in polarity and thus doesn't work as it's supposed to do.

[Natalie_Z_Intel]

Hi, B-O!

Your questions around Bay Trail have been escalated within Intel and logged in our internal systems. There are updates/tracking in those systems and our engineers will continue to work with you and your customer. Thank you! LynnZ

[BBerg7]

Thank you! I have noticed the escalation! Have a nice weekend!

B-O

[BBerg7]

I have good news, the SATA IRQs works now! The reason why it didn't work was that I was too early in the initialization. The documentation is right and there are probably some chipset features needed to be initialized before the SATA interface. I initialized some of the SATA PCI registers before the DRAM initialization and that was too early. I move that initialization to just before the ISA and PCI bus configuration phase and after that it works!

Thank you all for your help!

Best regards,

B-O

[Natalie_Z_Intel]

Congratulations! Glad it is figured out now! Thanks for choosing Intel. LynnZ