13 Replies Latest reply on Sep 25, 2010 12:22 AM by BIOS_PROJECT

    SPI Programming and the DX58SO.


      I've started developing a custom BIOS for the DX58SO, while I have been able to simulate and test the BIOS I am ready to flash it to the board for real-time testing.


      I have looked the board over and have been unable to find the physical SPI header, I do find a references on the silk-screen that says XU3LB SPI Socket but I cannot locate the physical header or any material that explains what is needed to perform this task.


      What specific hardware do I need to program my BIOS in this board?


      Intel, please have some decency and courtesy to respond to my inquiry with the requested information, I really can't afford to through away another $50k as occurred in our previous issue that your negligence caused.


      Thank you.

        • 1. Re: SPI Programming and the DX58SO.

          I see other people are looking to do similar BIOS work and being met with total frustration by the lack of input or response from Intel and I find this unacceptable behavior.


          From past experience Intel cost me over $50K and fourteen months of my customers down-time only to End-Of-Life the product and then tell my customer they could no longer look at resolving the issue due to the EOL.


          I refuse to further tolerate this type of behavior or any further lies to questions I pose and I fully expect Intel to provide the necessary information or the contact information of a person who can provide me with the information I need.


          Furthermore, I expect some kind of response from Intel stating they are at least looking into my request and I expect this in the near future.

          • 2. Re: SPI Programming and the DX58SO.

            If I'm not mistakin the socket is the onboard chip where your BIOS is stored. The header is where the chip is soldered into.

            1 of 1 people found this helpful
            • 3. Re: SPI Programming and the DX58SO.

              One would think this however, so far, Intel has refused to provide any information on how to program the SPI ROM, the schematics show MOSFET protection circuitry however I suspect this has been removed in the production boards.


              Claiming this board is capable of ICSP programming (and that seems to be about as much as they are willing to admit) and failing to provide the details is nothing more than a lie regarding the capability.


              Intel claims that this board supports ICSP and because of this claim my customer purchased 500 of this specific board for their project so now I have to wait for intel to provide details so I can work on the project but I fear my customer has wasted funds because Intel isn't going to deliver again.


              My issues are the following.


              Intel promotes and encourages independent BIOS/Firmware development.


              Intel claims this board is capable of ICSP programming.


              I am developing BIOS/Firmware for my customer to use in this board.


              I need to perform ICSP programming to install the developed BIOS/Firmware.



              Now, this should not be rocket science and it certainly should not be that difficult to be provided the information that allows me to perform ICSP programming.


              This time I did not purchase the boards on behalf of my customers project because of Intels previous behavior.


              It is a project I am hoping to undertake but at this time I am not financially vested in the project.


              Furthermore, Intel's failure to provide the information leaves my customer experimenting with SPI chip removal which is the only other alternative since intel wont provide the required information for ICSP programming.


              Two out of ten boards are working after the R & R and the non-functional boards are being sent back under warranty to Intel as DOA.


              My customer doesn't want to tell Intel why the boards don't work in fear of the warranty being refused and I agree with the principle, if Intel wont provide the information to perform ICSP programming then they are effectively giving permission to my customer to perform the R & R since that is the only other option.



              Myself I'm seeing a pattern, Intel makes claims and does not substantiate the claims.


              I have a history of Intel lying to me about a board's capabilities and the last incident cost me over $50K and a more than 1.5 years of development time.


              I'm getting to the point that anything that requires board modifications of any kind, Intel products are not suitable and currently I do not promote the use of Intel products to my customers because Intel is not supporting the products they sell by the claims they make and I certainly don't want to waste another $50K and time so they can drag out the issue until the product is EOL'd where they then can claim that they can no longer provide support for it.

              • 4. Re: SPI Programming and the DX58SO.


                My boss is in possession of proprietary Intel information and software without an NDA which were obtain by unknown means because Intel refuses to be honest in discussions.


                After the last failed project incident, their failure to provide the tools and information under an NDA did not prevent the completion of a recent project.


                Actually he didn't even bother to ask this time because he just wanted to get it done and Intel drags things out for months which was not available and also probably because of the $50K.


                I also suspect that if Intel continues with this type of behavior he might dump everything onto the web for anyone to access and it would be impossible to determine the source of such material.


                I know he has stuff first hand because he has a version of iAssist and Integrator Toolkit that I used and they works on OEM (non-retail) Intel boards where the ones you download from the Intel website don't.


                I'm just an employee, I pose no real threat but since Intel did not tell my boss that an NDA was required for some of the tools he obtained he's not bound by any terms, dumb on their part not to get one from him.


                I highly doubt that the ISCP programming information wont become public if he figures it out before Intel steps up to the plate and gets an NDA when they  provide the information to him but I also doubt they will do this since they aren't too concerned with keeping proprietary information from the general public and for me, it doesn't matter how the information is obtained, I'll get it eventually, I would just prefer now over later.

                • 5. Re: SPI Programming and the DX58SO.

                  I'm just a small builder , But I'm just courious what in the BIOS is it that you need to change So Bad.

                  • 6. Re: SPI Programming and the DX58SO.

                    We're not changing a portion of the BIOS we are replacing it completely with an EFI based BIOS that was created for a specific purpose.


                    In the past I've had the need to replace portions of the BIOS and the Intel provided tools do not permit this.


                    Claiming that it is an AMI based BIOS leads one to believe that the AMI BIOS tools would work on it and they don't, claiming that this board supports ICSP without details is a false claim and more likely an outright lie by Intel again.


                    In other boards like the DX48BT2 and the D975XBX2 it's very easy to perform ICSP programming but in the case of the D975XBX2 Intel outright lied to my boss and the customer about certain capabilities, wasted more than 1.5 years dragging it out (like they really worked on a solution for that long) till they EOL'd the product then refused to resolve the issue because the product was EOL'd and it cost my boss personally over $50K in capital not including man-hours spent on the project which could not be charged to the customer and all because Intel lied so all I expect from intel now is honesty.


                    They need to provide the information required to allow ICSP programming which they claim this board is capable of or publicly state that they lied and the board is not capable of ICSP programming.


                    Personally we wouldn't be having this issue if the customer would accept a non intel X58 based product, I feel loyalty to a company that treats it's customers so poorly a sad matter.


                    This time around my boss refused to buy the hardware so the customer did, intel refused to help them and so far has not provided any help to us and I think the results are going to be obtaining Intel tools and software by any means and then making it all public.


                    It's not like Intel wasn't approached on this matter where they could have taken steps to protect things, but rather have taken the approach of F.U. so while they have not provided any tools or information under an NDA so there is nothing to violate.


                    This is the path Intel has taken so if my boss figures it out with the help of his taiwan friends before Intel does stop dicking him around and does something under an NDA I can almost bet that the tools and information will become publicly available to anyone who wants them and you wont need an NDA to get the stuff so Intel will be the only losing party in this matter and it will be because this is what they have decided.

                    • 7. Re: SPI Programming and the DX58SO.

                      Why would Intel provide a Proprietary Binary Key to anyone , If you need custom boards maybe you and your customer should try Petragon or another board Mfg. Rather than waisting your time and money fighting with Intel for something they are not going to give you?

                      • 8. Re: SPI Programming and the DX58SO.

                        Interestingly enough the solution will be had, how the matter is handled is entirely up to Intel.


                        The customer specifically want to use genuine Intel products, we currently discourage this becuase it take far too long to accomplish anything due to their ******** and stupidity but the customer has their mind made up.


                        As I previously stated, it's not that it's not going to happen, it's now a matter of Intel giving up control of the matter and in my opinion Intel doesn't care if anything becomes public cause if they did they would do things in the manner that was outlined.


                        Intel promotes BIOS development, provides the tools upon request (so they say) so it's time for them to make good on their claims and statements.

                        • 9. Re: SPI Programming and the DX58SO.

                          What the hell????


                          Does intel make a habit out of lying to it's customers???


                          I see that some Intel proprietary BIOS tools are now being seeded in torrents, wonder how long it will take before all of them become public?

                          • 10. Re: SPI Programming and the DX58SO.

                            Oh where to begin.

                            • 11. Re: SPI Programming and the DX58SO.

                              Oh were to begin indeed.


                              Intel tells me that it's possible to flash this board but refuses to provide the information or required component part numbers to achieve the flash after telling me they would provide the information.


                              This all started because my customer wants to use an EFI software solution and has chosen the DX58SO motherboard.


                              First, I have completely gone through all of the BIOS modules for the currently available BIOSes for the DX58SO motherboard and what is missing is HID drivers.


                              For those running windows, waiting for the OS to load keyboard and mouse drivers before these devices function seems to be an acceptable solution.


                              Once UEFI is enabled you cannot enter the BIOS without moving the jumper on the board or use the F10 key to select the device you wish to boot from  and this is due to the lack of a HID driver in the BIOS.


                              This means that if your OS provides a bootx64.efi file to boot the OS or provides some kind of GUI or TUI you cannot use the keyboard/mouse if there is no HID driver in it's code and form those I have examined they do not provide the HID drivers and expect them to come form the BIOS.


                              This also means that enabling UEFI breaks your systems ability to use EFI as a booting mechanism unless you do not require access to a HID device prior to the OS loading so how can intel claim that this is working.


                              Furthermore, how cna intel claim that a keyboard works when UEFI is enabled when there is no HID driver in the BIOS, of course the tech on the phone didn't appear to bright in his responses to questions and couldn't answer why the keyboard doesn't work cause his manul claims it does.


                              I also found that EFIVAR is not fully or properly implemented and that the use of EFINVRAM cannot be relied upon because the data is not saved and is no longer available if you restart or shutdown.


                              So to solve any problems which are related to intel's faulty BIOSes, schematics are available for this board and you must request them from intel cause no BIOS vendor will provide you with code if you cannot provide them with the schematics (both IRCONA and Insyde made the same statements about it's requirement) but even this process takes considerable time to acquire so if you have a project that is mission critical with a deadline, the use of intel products is not an option you should consider.


                              So after intel informs me that they have refused to provide details and information, I passed this along to my customer and he now has 500 DX58SO motherboards he can't use because Intel told him he could and would provide the information only later to recant and refuse to provide the information.


                              IRCONA (AMI based BIOSes) tools are available to take the intel BIOS apart, swap, add and remove modules or make any changes you want providing you with a BIOS that you can flash to this board but they are not cheap to work with $45k including license fees for option roms for a small number of boards.


                              Insyde has similar options for BIOS development and are priced competitively but I think the only real option left is to beg, borrow or steal the intel tools an do the work yourself.


                              As mentioned previously, someone has already started seeding some of the intel tools and more tools are becoming available on a weekly basis so if you look in the right places you can find the underground BIOS network and get the tools without an NDA.


                              At this time I have taken the BIOSes apart and have confirmed that no HID drivers exist and with some config files missing I am unable to add the missing modules but I am working on obtaining them.


                              I'm thinking I might use the information from some of these tools to generate a single application that will work on these BIOSes without the need for all these project/config files based on the information extracted from the BIOS itself in the same way that mmtools.exe does it now for the aptio8 based BIOSes.


                              So intel has lied again, no surprise there and my customer is now stuck with 500 boards he can't use or return and intel claims that there is nothing wrong with the BIOS provided in these boards which we all know to be incorrect.


                              Intel promoting independent BIOS development with their EDK software is also a lie, there is insufficient code in the EDK to generate a BIOS and they do not do anything more than suggest you can create one, no sample BIOS or code base to work from and the lack of code means it's nothing more than an idea which has not been validated by anyone.


                              Furthermore, any attempt to develop a BIOS is shut down by intel because they don't want you to do this despite their claims of promoting independent BIOS development so if you think intel will help you in any way to develop a BIOS by providing you with information or resources be warned that intel's position is to not give you anything.


                              At least this time I didn't let intel screw me, I didn't shell out money based on their claims that I could do anything, I learned my lesson the first time when they screwed me for over $100K in hardware expenditures because I bought hardware based on their recommendation that it would do what I needed and when it didn't they dragged it out for more than 1.5 years so they could EOL the product and then tell me they could no longer help me the product was EOL'd.


                              So intel tells me the schematics are available for this board and they are required by IRCONA and Insyde to select the appropriate modules to give you a BIOS code base to work from so we will now see if this is another lie by intel.


                              My only reason to obtain the schematics at this time is to verify that intel can tell the truth but I'm not holding my breathe, they have not told me the truth one time so far, hell they can't even return a call when they say, they told me I would receive a call within 24 hours and it took 29 days and I called on a weekly basis trying to get an update.


                              So a quick recap, intel tools are available, I have no NDA so I have nothing restricting me from doing anything with the tools I have recently acquired, I fail to see the downside.


                              Am I worried about being sued, no, intel already told me the tools and resources are available so I acquired them, changing their mind after the fact is too late and they have not provided me a detailed list of the software I am not permitted to use and I see no reason to ask if I can use any of the specific software I have.


                              Also, the ITK FE being publicly distributed is missing some software which enables additional features like the ability to edit the flex modules, getting this software increases the usefulness of the ITK FE so I suggest if you are interested in fixing an intel BIOS because they wont just find the missing pieces and this makes it possible.


                              So it seems that intel can't be trusted to be honest and their hardware is incapable of the claims that they make about it, furthermore, this seems to be their preferred modus operandi and everyone seems to accept this type of behavior from them.


                              Supporting a CPU and listing it in the supported CPU list only later to remove it and refuse to offer warranty support because it's no longer listed is another one of their fabulous traits.


                              Intel products have proven to be garbage for use in any real application due to the lack of actual support for the product when it doesn't live up to the expectations or claims and anyone in their right mind would chose a different vendor to purchase their products from.


                              To say that the EFI is complete and fully functional in this board is an outright lie, the issues with the provided BIOSes incorrectly configuring the onboard hardware is sufficient reason to avoid using the hardware whenever possible because you cannot get it fixed and they refuse to allow you to fix it in any legal manner leaving you the only option to steal their tools and fix it yourself.


                              This is why I no longer endorse the use of intel products, it's wasteful to spend money on products from intel that wont do what they claim they are capable of and until intel decides to provide the tools and information they initially stated they would provide I see no reason to keep any information they might consider to be trade secrets confidential.


                              Conclusion, intel has outright lied and this cannot be disputed.


                              I would be interested to know if anyone has been refused the schematics by intel since they were very clear that they are available through their channel partners but I suspect that they would come up with some lie to prevent you from obtaining them but I will try just to see if they lied about this as well.


                              Currently I am under no obligations to intel, this was their choice and since I have no list of any specific information that might be considered confidential I am doing nothing wrong by discussing it or divulging the information at my discretion.

                              • 12. Re: SPI Programming and the DX58SO.

                                FURTHER UPDATE:


                                I see that the information regarding the manufacturer's plug on the motherboard is now available in the underground BIOS network.


                                I also see that 1:1 DIAZO prints are available so that you can create the programming port for this motherbroard (and probably any other LGA1366 board), the print bear the intel name and logo so I don't recommend you have them made professionally and distribute them but I see no harm if you make it for personal use, who's going to know you have it any way.

                                • 13. Re: SPI Programming and the DX58SO.

                                  In response to Roberts query, missing modules and improperly configured hardware is what is wrong with all the BIOSes for this motherboard.