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