How to get IRQ14 and IRQ15 to work in legacy IDE mode on Bay Trail.

[BBerg7]

Hi,

I have some questions I hope to get help to resolve.

1) SATA in legacy IDE mode does not generate IRQ14/IRQ15 despite niEN bit set in control registers. I have enable the SERIRQ in the pad configuration. The SATA port works 100%, but do not generate any interrupt. Should the SATA registers iEN bit be set as IDE is emulated? I have not set it as I run the SATA controller in legacy IDE mode.

2) The settings recommended to be done before and after the pad configuration on Bay Trail hangs. The recommended settings are for BWG Rev 1.42. If I ignore the pre and post configuration of the PSBCONF registers, the pad configuration seems to succeed as I get pad functionality like speaker etc. Are there any newer documentation available (EDS, BWG) for doing it right or do you have any hint why these settings should hang?

Best regards,

B-O Bergman

Winzent Technologies

[Adolfo_S_Intel]

Hello B-O

We are investigating your issue, and will reply back as soon as possible.

Best regards,

Adolfo

[Natalie_Z_Intel]

B-O, I found your Intel representative and forwarded all of the threads that you have posted in the Embedded Community to him (Mariusz) so that he may better assist you. You should be contacted shortly. LynnZ.

[Adolfo_S_Intel]

Hello B-O

Regarding your first issue:

Are you using I/O APIC or PIC 8259?

Is there any particular reason for you to enable SERIRQ?

About your second issue:

I checked for new versions of the BWG or Addendum but I haven't see newer versions so far, I will notify you if I find newer documentation.

When you refer to the pad configuration, are you talking about the GPIO pad configuration?

Could you give us more details about what is your desired PAD configuration?

What sections of the BWG are you following to configure the PSB_CONF?

[BBerg7]

Hi Adolfo,

Thank you for your fast reply!

Regarding the first issue:

We do legacy BIOS and thus support legacy I/O as expected by PC architecture. As our customers implements the industrial PC architecture, we need to supports the ISA bus and legacy I/O. Thus we need to enable LPC and SERIRQ. We have enabled the SERIRQ, put SATA in legacy mode, unmasked the IRQ14 and IRQ15 bits in 8259 and enabled IRQ by clearing bit 1 in the ATA control register. The ATA commands get executed, but waiting for interrupt that never comes causes our normal handler to timeout. If I follow trough with debugger and ignore the timeout, the correct status is read from the IDE status register and the I/O transfer will succeed with valid data. So the IDE interface works, but the IRQ14/IRQ15 signaling doesn't.

I suspect that these IRQs needs to be enabled in some register not mentioned in the BWG or EDS documents. By the various documents it looks like these IRQs are not serial IRQs and directly driven by chipset like IRQ0, IRQ8, IRQ13. The question is how.

About the second issue:

In section 37.2.3 in the BWG 1.42 it says that a one time configuration with the value 0x01001002 should be written to the PSB_CONF registers before starting pad configuration. It also says that after pads has been configured the value 0x01041002 should be written to the same registers. However, when we do that the SOC hangs. Bypassing the PSB_CONF succeeds to reconfigure the pads, but then it hangs when writing the after value to the PSB_CONF register.

The desired pads configuration is the functionality of the pin names, as they are what the board designer expects when connecting external logic to the chip. Let me give an example.

The name of ball (pin) BH12 is ILB_8254_SPKR. At power on multiplex functions resets to function 0. Thus BH12 pad is connected to GPIO_S0_SC[054]. The board designer has connected the speaker logic to pin BH12, but that pins is a GPIO pin that defaults to input. There are many pins having multiple functions and the ball name does not match the power on configuration. So they all need to be reprogrammed by the BIOS early in the POST process. For example, all the LPC pins are multiplexed and do not default to the LPC function, thus TMP, SIO and other LPC connected stuff will not work without configuration.

However, the problem is that there are some parts that are missing in the documentation. The before and after PSB_CONF settings hangs the chip. The NCORE stuff (North Core) are not documented at all and I have managed to find the offset of these registers, but the register bits are not documented.

For system BIOS the graphics port signals needs to be connected to the ball in order for VBIOS to work. There are 3 - 5 signals of the 6 pins for each DDI port that needs to be connected to the pad in order for the display interface to work. These to default to GPIO and thus are not connected at power on.

Best regards,

B-O

[Adolfo_S_Intel]

Hello B-O

Thanks for your feedback

Please answer the following questions:

1-Did you enable the P_DEVICE_CTROL_nIEN and S_DEVICE_CTROL_nIEN bits in the P_DEVICE_CTRL and S_DEVICE_CTRL registers?

2-Do you observe any change in the PSTS register bit 2 (I), when you receive a FIS with the I bit set?

3-What is the status of the MSIE bit?

4-In your original post you mention the iEN bit of the SATA register, but I haven't been able to find this iEN bit in the EDS or the BWG, can you tell me in what document and section is this register mentioned?

5-Can you tell me the IPIN value of the Interrupt Information Register?

6-What is the value of the IR19 register and of the PIRQA-PIRQH registers?

7-Is one of your LPC devices using the SERIRQ15?

8-Is the issue still present if you disable SERIRQ?

I will be awaiting your reply

Best Regards,

Adolfo

[BBerg7]

Hello Adolfo, thank you for your fast reply!

1 - I always enable the nIEN for each access as a part of setting the control bits (i.e. more than 8 heads, normal operation and interrupts enabled). The legacy IDE code is well proven for about 10 years and used on many X86 architectures.

2 - This is the device detection phase of the BIOS and we don't use UDMA at this point. We use identify device commands at this point as they don't support UDMA.

3 - The MSIE is 0 which should be the power on/reset default. According to documentation MSIE is RO and 0 for legacy IDE mode.

4 - There is an interrupt enable bit for each SATA port, but I think they are only used in AHCI mode.

5 - The IPIN value is 01h, i.e. INTA# .

6 - The PIRQ A - H values are 5, 6, 10, 11, 5, 6, 10 and 11. The IR19 register is 4, thus using PIRQE in PIC mode and IRQ20 in APIC mode. We use PIC mode and will be switched to APIC mode by OS (ACPI or MP code).

7 - No LPC devices are using SERIRQ15. This is the same behavior on every board, with and without LPC devices, with and without Super I/O devices.

8 - Yes, the issue is always present with our without SERIRQ enabled. I noticed that the nIEN bits are 0 as power on default. But any interrupt caused by any IDE activity should be cleared by reading the IDE status register, i.e. reading 1F7h clears IRQ14 and reading 177h clears IRQ15. The IDE status are read before issuing any command, thus any pending interrupt should be cleared and the command should case an interrupt.

Best regards,

B-O

[Adolfo_S_Intel]

Hello B-O

According to section 34.3.7 of the EDS (doc # 510858)

Shouldn't PIRQE values be 0xE or 0xF to route to IRQ14 or IRQ15 on PIC mode?

Also just to check it would be possible that IRQ14 and IRQ15 have been left masked in the IMR register?

Best Regards,

Adolfo.

[BBerg7]

Hi Adolfo,

I have not left IRQ14 and IRQ15 masked in the IMR register. As a background I have been doing this, low level in assembly language since the birth of the 8086 PC. I have written entire BIOS and OS in assembly language from scratch. I have made a lot of different BIOS for AMD and Intel architectures. The code for that do the hard disk initialization is well proven and runs without modification in every architecture, except Bay Trail and that's why I'm here.

I have enabled IDE legacy mode in Phoenix and AMI BIOS. There the interrupt works. All the PCI register settings are identical with our BIOS. The PS2 mouse and keyboard works for all of us, so SERIRQ is enabled.

So with identical settings, the IRQ14 and IRQ15 must have an additional control setting, which are not evident in the BWG or EDS. Inside Intel, the chip designer knows how the SATA IRQ14 and IRQ15 are controlled. Unfortunately, that didn't make it to the documentation.

The PIRQ settings are for native and AHCI mode. The legacy IRQs comes from either external SERIRQ or internal functions (IRQ0, IRQ8, IRQ13, IRQ14 and IRQ15). PIRQs are level based IRQs and can be shared. The legacy IDE IRQ14 and IRQ15 are edge trigged signals and thus fixed.

Maybe you should push this as errata? The IRQs doesn't work in IDE legacy mode even though all the documented settings are done. Maybe the settings has to be done in a certain order or they may be some quirks needed to be done.

Another thing that can be connected to the problem. According to the documentation the SC bit in the SATA device register should be set to 0 for IDE operation. I can not clear this bit and I have noticed that this bit is 1 for Phoenix and AMI BIOS as well. Maybe that bit somehow can be cleared causing the chipset to enabled IDE IRQs and then reverted back to 1 when they have been enabled? Then there is a certain sequence that needs to be done. Power on default is SC=1 and legacy IDE mode.

Can you contact the chip designer responsible for the SATA device in BT? He will now for sure!

Best regards,

B-O

[BBerg7]

Adolfo,

In the SATA MAP register the SMS field says that "IDE mode requires LBC01.LBGE=1 (refer to LBC01, LBC23 and LBC45 register in SIR register space);". This may be a hint! Are there any documentation on the LBCXX registers in SIR space?

So IDE mode requires SC (in SATA MAP register) to be 0 and the undocumented register LBC01 LBGE bit is set. I can't set LBGE bit as I don't know where it is. As I mentioned in my previous reply, SC bit refuses to be cleared.

Best regards,

B-O

[Adolfo_S_Intel]

Hello B-O

Thanks for your feedback, I will check for further documentation, and consult this with our engineers from the Intel Division, I will reply back to you with useful information regarding this issue as soon as possible. Thanks for your understanding.

Best regards,

Adolfo.

[BBerg7]

Hello Adolfo,

Good luck digging!

Best regards,

B-O

[BBerg7]

Hi again Adolfo,

Some further hints regarding the Bay Trail IDE issues. I have also tested the hardware using native IDE. The native IDE uses the PIRQ. It does not generate any interrupt in native mode either. When I run in either IDE mode, no IRQ is generated but the I/O transfer succeeds. All IDE commands works in both modes, even though an interrupt is never generated.

Thus it must be the LBGE bit in the LBC01 register located in the SIR register space, where ever this is! See description below. Setting 0 = IDE (legacy and native), both requires LBC01.LBGE=1 and none of them generates IRQs on Bay Trail platform. They generate interrupts on other Atom architectures like POULSBO, DIAMONDVILLE and CEDARVIEW. So the IDE mode requirement stated below must be the cause of the malfunctioning.

Best regards,

B-O

[BBerg7]

Hi Adolfo,

Are you getting anywhere?

B-O

[Adolfo_S_Intel]

Hello B-O

I'm still searching for additional information regarding your issue. I have not find anything regarding your registers in the available documentation. So I'm consulting your case with our engineers from Intel. I appreciate your comprehension.

Best Regards,

Adolfo.

[BBerg7]

Hello Adolfo,

I suspect LBC is a short name for Legacy Buffer Control. I further suspect that LBGE is a short name for Legacy Buffer Gate Enable. Thus the IRQs from the shadow IDE register emulation are disabled by default and in tristate condition behind a buffer. The IDE IRQs thus need to be enabled by the gate bit in order to be present.

That's the easy part. We now know what these undocumented bit in LBC01.LBGE does. The question is, can you find any documentation of it? It's gone more than a week and it's a simple, specific question.

It's rather confusing, that a company making state of the art CPUs, chipsets and logic accidentally or on purpose, leaves out crucial parts for the functionality of their chip. As it's has gone more than two weeks it's hard to believe it's an accident. If the documentation was half as good as the hardware, there would be no problem at all.

I know you struggle with this Adolfo and do your best! Keep on digging!

Best regards,

B-O

[Adolfo_S_Intel]

Hello B-O

I have searched all the documentation that I have access, and unfortunately I haven't been able to find more information about your issue, since this particular issue seems to be getting out of my scope I'm consulting with more knowledge and access that hopefully will be able to help us with this issue.

I apologize for not being able to serve you better with this issue, and I will post as soon as I got more meaningful information or more suggestions for you to try.

Best regards,

Adolfo

[BBerg7]

Hi Adolfo,

Thank you for trying! Did you know that not providing this documentation is unlegal in Europe as it creates an unfair advantage for the other BIOS companies? Intel in Russia, Polen and Israel is working on it. One of the largest board vendors (which are our customer) are helping me to push Intel.

I guess Intel are not keen on helping us due to politics, as our BIOS is superior to the UEFI architecture. With time, they have to give us access to the same documentation that the other BIOS companies get. We are currently working with several major Intel customer with our BT BIOS and Intel refusal to give us the documentation does not look good in their eyes.

Thank you Alfred for all your help!

SIncerely,

B-O Bergman

WInzent Technologies

[Natalie_Z_Intel]

Hi, B-O!

I have reached out to our sales team in EMEA to further assist you for deeper support. Adolfo has provided the documentation and information that is available to him. The sales team should be able to engage with an FAE to provide the deeper support that you need for your project. Thanks! LynnZ.

[BBerg7]

Thank you all for trying!

We are a BIOS company. We have a CNDA and RSNDA with Intel. We don't have access to IPS, even though we should have. We don't have IBV (independent BIOS Vendor) status, even though we should have. We have asked for help with fixing the IPS login, getting the IBV status and been promised being called by Intel represent, but nothing happens.

According to another Intel contact, the IPS should be available to login with the same user name and password as the business portal account. We use to have access to premium support, but we don't have access any more. Is this all a coincident?

We do want to have IBV status and access to the same information that all other BIOS vendors have. Can anyone help us with access to the IPS? We also need IBV status, so we can get access to the same documents as our competitors.

Best regards,

B-O

[BBerg7]

Hi LynnZ,

We are still struggling with the IRQ14 and IRQ15 problem in SATA legacy IDE mode. Is it okay if I share the solution here, so others can avoid the struggle I have. I may be restricted by the CSNDA or RSNDA, but feel this is something that should be official documented for anyone qualified with the proper NDA.

Best regards,

B-O