Crucial documentation for Bay Trail missing in EDS.

[BBerg7]

Hi,

The following pins are secondary functions on the Bay Trail SOC and thus not available at power on:

DDI0_BKLTCTL

DDI0_VDDEN

DDI0_DDCDATA

DDI0_BKLTEN

DDI0_DDCCLK

DDI0_HPD

DDI1_BKLTCTL

DDI1_VDDEN

DDI1_DDCDATA

DDI1_BKLTEN

DDI1_DDCCLK

DDI1_HPD

As these pins are are not available at power on, VBIOS can not detect displays connected to the DP or eDP ports. However, Intel has leaved the documentation of these pins out from the EDS PCU iLB GPIO CFIO_SCORE Address Map, so these pins can not be reconfigured to the proper values for the boards.

I don't know the policy behind this, as from a legacy BIOS point of view, the graphics is handled by VBIOS and this is a proprietary product from Intel with reverse engineering forbidden.

In our case this is fine, but as we leave the graphics for the VBIOS and the OS graphics drivers, we should at least be enabled to provide the crucial video signal pins to the pad.

Why is this kind of information leaved out, even though we have all the required NDAs and agreements signed?

We have contracts on Bay Trail BIOS for several board vendors and some of them are major companies with huge volumes. Due to NDA I don't have the rights to mention them by name.

However, they wanted me to send a confirmation of this support matter being handled by Intel so they can follow and help pushing it trough.

Best regards and hope for quick help,

Berth-Olof Bergman

CTO

Winzent Technologies

[Natalie_Z_Intel · Accepted solution]

Hi, B-O! Our team is looking into your post now. In the meantime, would you like for me to have an Intel representative contact you to assist you directly? LynnZ

[Gabriel_T_Intel]

Hello B_O

Welcome to the Intel® Embedded Community.

The display physical interfaces consist of output logic pins that transmit the display data to the associated encoding logic and send data to the display device. These interfaces are digital (MIPI-DSI, DisplayPort, Embedded DisplayPort, DVI and HDMI Interfaces.

These signals are not directly configurable, you configure them through HDMI, DVI, DisplayPort (DP) or Embedded DisplayPort (eDP) ports configuration in the VBIOS.

Please review the document http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z36xxx-z37xxx-datasheet-vol-1.pdf Intel Atom Processor Z3600 and Z3700 Series Datasheet. Table 53 on page 90, Display Physical Interfaces Signal Names, there is more detailed information about these signals.

What tool are you using to configure VBIOS?

What operating system ?

Best Regards

Gabriel Thomas

[BBerg7]

Hi Gabriel Thomas,

Thank you for the quick reply!

In the document you mentioned in your reply, take a look at page 39 and 40 (see pictures). You will see that the signals I mentioned in my request for help is marked with a cross. That means that these signals are multiplexed and may not be available without configuration. In these case they are not available without configuration as they default to the GPIO function at power on. In the EDS documentation the ball listing shows that the DDIO_BKLTCTL signal for example defaults to GPIO_S0_NC[05].

The cross marked signals below are simply not connected to the balls at power on and needs to be reconfigured by the pad configuration registers. However, every multiplex configuration register is mentioned and documented in the EDS, except the configuration registers for these 10 signals.

As these signals are not available, VBIOS are not able to detect the display devices connected to the DDI ports.

We develop the fastest BIOS int the world for embedded systems. It's a legacy BIOS, doing full POST and initializing all the hardware and yet do the POST under 1 second. We focus on the Atoms and support Z5xx/SCH, N270/945GSE/ICH7, CEDARVIEW and now BAYTRAIL. We use the latest BMP tool for configuring VBIOS on a windows hosted system.

Unfortunately, VBIOS is not available in source code, so the interaction between system BIOS and VBIOS is not good. If we had the opportunity to work with the source code we would be able to contribute with a big improvement in interaction between system BIOS and VBIOS. As we don't do UEFI, we would be the perfect partner for Intel to maintain VBIOS. We have also made major contributions to Open Watcom, the tools used for building VBIOS, so a cooperation would be beneficial for both of us.

Okay, I hope you will be able to help me with this one. If the configuration registers for the signals mentioned was documented, we would not have to bother you with these kind of questions. If you think about it, you have the BWG and EDS for the chipset and still can't do the job. As almost all board applications has display connections, I can't understand why this is leaved out from the documentation.

Best regards,

B-O

[BBerg7]

Thank you! Yes, I think that would be necessary to solve the problem.

[BBerg7]

Hi LynnZ,

How are your team doing? No one has contacted me. Is it okay that I send a copy of our communication here to our contractors. They are very driving in this project and want to know how it goes and I have to report the status to them.

The status is that the BIOS works, but many pins used in the design is not connected to the pads. The balls have names with a certain functionality that are connected to various logic on the boards, but the signals are not connected to the balls and needs to be configured.

However, the configuration registers are not documented, so there is no way for me configure the chip to the functionality expected by the board designer.

I ask you what to do, as I think we should solved this together without involving our customer. Or do you think it's better to involve them to get the proper priority for this matter? Our customer are on of the biggest Intel customers in the world and they are very eager on this project. This is a top priority project for this company and there are many peoples involved.

Please, let me know how to proceed.

Sincerely,

B-O Bergman

Winzent Technologies

[Natalie_Z_Intel]

Hello, B-O. Sorry for the delay as we have been on holiday. On Monday, I will get your request into the system and alert the Intel representative to assist you.

They may at that time involve another representative who covers your customer's account as well. LynnZ.

[BBerg7]

Thank you Lynn! Have a nice weekend!

[Natalie_Z_Intel]

Hi, B-O. Information has been sent to the Intel representative and you should be contacted shortly if you haven't already. LynnZ.

[BBerg7]

Thanks!

[BBerg7]

Well, 3 weeks has passed and your team has not coming up with any information in this matter what so ever. However, I have solved it myself (as usual). It would be more effective if Intel had support that worked. After all, you develop the chips and you should know stuff about them. Any decent engineer is expected to have knowledge of what he or she is doing.

Thank you anyway for all your help. Adolfo did all he could, but failed too as he do not have access to right documentation. Kudos to Adolfo for trying!!!!

Sincerely B-O

Winzent Technologies

[Natalie_Z_Intel]

Hello B-O, I have again reached out to the account team in EMEA to further assist you. You should hear directly from them soon. LynnZ.

[BBerg7]

Thank LynnZ! I appreciate your help!

Kind regards,

B-O

[Natalie_Z_Intel]

Learn more about B-O's findings at

[BBerg7]

Regarding the information missing in EDS, the location of the configuration registers for these pins was in the BWG 1.42. The problem was solved by finding out the function number of the signals and thus simply make a bitwise OR as all the bits except the function number in the registers proved to be correct.

The power on (reset) function numbers defaults to 0, so just making an bitwise OR with the correct function number will suffice. In C syntax, *(IOBASE + DDI0_BKLTCTL) |= FUNCTION_NUMBER;

Best regards,

B-O

[Gabriel_T_Intel]

Hello B-O.

We are very glad that this issue is solved.

You have added very valuable information. Thanks for your comments.

Best Regards.

Gabriel Thomas