Through the hardships of PC development
On the eve of Computex 2015, our company has published an article about a new, even more powerful mini-computer . But was it so easy for us, the developers of this product? How many sleepless nights did the engineers cost this development, how many problems did they have to solve and did the pitfalls get around? In this article we would like to talk about the very beginning of this journey, it was 2009, “we survived as we could.” I think, dear reader, it will be interesting for you to read what rakes and with what force we were naughty during the creation of the first board.
In early 2009, the company's management decides to create, or rather, to revive the direction of the development of computer technology. The company's history is quite long; we can only mention that in the 80s the company participated in the development of the Irisha PC. And so, in 2009, the official Taiwan branch of Communication Technology begins a dialogue with Intel and its official distributor in Taiwan. As a result, we receive documents on the Intel PineTrail-M TigerHill platform - this is a duet of the Intel Atom processor N400 / D500 series and the NM10 chipset. To debug the first version of our board, it was decided to dissolve it in the COM Express form factor. This is a 95x95 mm mezzanine module, with a long multi-pin connector. And so that you understand the severity of the situation, the module's circuitry and wiring were made not in some new-fashioned Cadence or Altium, but in the old tube PCAD 2006.
The photo is already the second revision of this module:
')
Just imagine. Soldered 5 modules. Lie down on my desk. It is urgent to run. I am in Taiwan, my boss in Moscow. Documents from Intel - reference diagram, guide for the razvodchika and a couple of datasheets per chipset and processor. Anything more there is nothing.
I want to tell you that my immediate supervisor is Anatoly Viktorovich Sorokin, an excellent and experienced engineer who changed the circuitry for compatibility with COM Express and removed from it the so-called EC - Embedded Controller. This microcircuit is responsible for starting and controlling power supplies, controlling fans, etc. things. Accordingly, the power supply chain has become trivially simple, the power supply just went up one after the other and in the end the common so-called POWER_GOOD was raised, telling the chipset that all the power was ready. In principle, this EC is absolutely not needed on this module, it can be installed on the motherboard, or it may not be installed, it does not play a noticeable role.
The board on the table, the passive board (motherboard) is also ours, simple as a detector receiver. Two power supplies - + 5B for peripherals and + 12V for the COM Express module, the launch of which is controlled by a small microcontroller. The same microcontroller polls the state of the On button, some necessary signals from the chipset are also monitored. It is now I know how this kitchen works, and then it was NOTHING UNDERSTANDING.
Okay, we supply power from a laboratory source, press the power button, the microcontroller raises + 5V and + 12V, pulls the PWRBTN # signal for 100 ms and waits a second from the chipset to raise the SUS_S5 # signal. While he was waiting for this second, one of the tantalum capacitors flew up into the air, mixing the polarity during soldering. Well, solder and check the rest. A couple had to be soldered.
Run again. SUS_S5 # is in the unit, nothing happens, the current consumption is small, it means power. I note that the launch of the power supply is generally the very first step of launching any board, but for such complex clever platforms there are 10-15 separate DC / DC converters that must be run in strict sequence, and some even with delays. In our case, the first step is to convert + 12V to two main power supplies + V5A, + V3.3A. A - this is the main power, which should be started by the iron on the power button, it feeds the chipset.
Yeah, these stuffs are there. PWRBTN # to the chipset comes. The next step is the RSMRST # signal - Resume Reset. We look where it comes from, it comes with a DC / DC converter + V5A / + V3.3A signal POWER_GOOD. It does not rise, infection, aha, since the power is present, it means that it must be pulled. We pull in, RSMRST # rises, after that SLP_S5 #, SLP_S4 # and SLP_S3 # take turns in turn from the chipset. These are so-called slipy, the chipset tells the platform - I entered the S4 state, cut in peripheral power (HDD, USB, memory, etc.), I entered the S3 state - cut in S power for everything else. The sequence is approximately the same - SLP_S4 # -> + V5, + V3.3, + V1.8 for powering DDR. SLP_S3 # -> + V5S, + V3.3S, + V0.9S for DDR, + V1.5S for CPU and chipset blocks. + V1.5S_POWER_GOOD -> + V1.05S for DMI, Analog DDR, GPIO units on the CPU and chipset. Further + V1.05S_POWER_GOOD -> + V0.89 for the graphic block CPU. And in the end, if all the power have risen, all the POWER_GOOD are assembled “AND” by logic into one common, a delay of 99 msec is done, to stabilize all the power supplies, and + VCC_CPU, the main power of the processor, is started. It is waiting for the PWROK and a separate VMPWRGD for + VCC_CPU. Fuuuh ... A couple of weeks, together with Anatoly, fought over these power supplies, as a result, one of the POWER_GOOD needed to be tightened, in the comparator circuit to control the voltage, to change the nominal values, and there was still a lot there, not to remember. As a result - all the power are, but the system is silent.
We understand further. The PWROK and VMPWRGD uplift chipset is required to inform the CPUPWRGOOD processor and raise the PLTRST # - Platform Reset. Those. He says to him - everything, power supply, I release the reset, start it! CPUPWRGOOG is rising, PLTRST # is not. Oops ... Sailed ... It's good that I still have all the captured dumps of the analyzer, here it is, the problem:
For two weeks we struggled with this problem, which we didn’t try. In the end, I found one of the endless potential problems - one of the pins of the chipset should have been pulled to the ground, and here it was hanging in the air! In general, we removed the chipset from the board, installed a thin wire on the contact and soldered a new chipset. And it earned! This is how it looked:
Unfortunately, there are no photos of how the iron looks under debugging, but, for example, the board on the Haswell platform looked on my desk like this:
Great, now it's the BIOS. While on the debug board I see the code 0x00, which means that the BIOS does not boot from the SPI EEPROM. The photo is a replica, the motherboard was different, but just to show how it approximately looked on the table:
We understand further, we get up to SPI_CLK - a clock is present, requests are coming, we get up to SPI_MOSI - the chipset issues packets of requests, we get up to SPI_MISO - zero. Tightening SPI_MISO - and cheers, code 0x87. Finally. Most likely the BIOS requires EC. We get up on the LPC with the analyzer, test and see requests to the address 0x164E and 0x164F, this is definitely EC, it hangs after the BIOS requests. Such:
Posted in AMI, Phoenix and Insyde. Phoenix sent the binary, but it didn’t start, Insyde started asking stupid questions at all, and AMI quickly understood the problem, and their binary started up the first time. Everything, the main iron is started, further only the periphery is checked.
After the launch of the board, some time passed, we made a passivation with the audio codec from Realtek. Nothing foreshadowed troubles, the HDAUDIO interface hooked up the codec, the device saw OSes, even earned the output to the speaker, but some outputs and inputs simply did not work.
They wrote to Realtek, talked, it turned out that the BIOS, at the start, should fill in the audio codec with the so-called VERB Table. In essence, set the internal registers of the codec in accordance with the requirements of use. Those. of the variety of outputs - only one can really be used. This table is generated by a special application from Realtek HDACfg. It shows all the information, up to the location, color and type of connector. Well, they arrived, there are no BIOS sources, AMI did not help us for free. What to do?
I do not even remember how, but I found a program on the network (BIOS Patcher 7.0), which was able to disassemble my BIOS into its component parts. UEFI BIOS is represented as a kind of capsule, inside there is a tree structure of different types of modules. The modules are mostly packed. And some of its cunning compression. Okay, I found a way to unpack all modules, I found a module responsible for initializing devices on the HDAUDIO bus. Very lucky that the table of one of the devices was larger than mine. I replaced it with my own, and, of course, did not forget to fix the length. But it was absolutely unwilling to assemble back. EDK Tianocore helped me a lot, with the help of its utilities, namely genffsfile, gensection, genfvimage, I manually collected all the necessary sections. And it earned!
Now, with some pride or something, I recall these winning moments, because there was nothing, no documentation on launching the platform, no BIOS sources, no sane support from Intel. Only intuition and experience helped.
Now it is somewhat simpler, of course, we have all the sources, you can fix anything in the BIOS quickly enough, the dialogue with AMI is adjusted, I occasionally deliver glitches to them and they correct them. Documents from Intel are already complete, i.e. for you to understand, for example, on the Broadwell platform there are about 130 of them. In Skylake, it’s already under 400. But still, the first revision of the board always ends up being finalized, there’s always something that isn’t attracted, or some other problem.
Now there is a debugger for BIOS, debugging can be viewed, and it has already rescued us many times. There is one person more in our team, a wonderful engineer, a hardware worker who solves a bunch of problems. Now we have our SMD lines, and the mystery of the pilot production takes place literally in the next room. Now Intel integrates chipsets into SoC and fewer problems with wiring. Now we have many partners and contacts around the world. But then there were other times, “we survived as best we could” ...
For the first time, perhaps, everything seemed to be just a couple of paragraphs, but in practice, with all this, they suffered for about two months. If you like it, then in the following articles we will talk about something similar, but for now ask questions in the comments.
PS And, of course, I look that way when I enter the BIOS.
References:
- " Network Technologies "
- “ Communication Technology ”
- Raydget Russia
- Raydget Taiwan
- Pocket desktop
A bit of history
In early 2009, the company's management decides to create, or rather, to revive the direction of the development of computer technology. The company's history is quite long; we can only mention that in the 80s the company participated in the development of the Irisha PC. And so, in 2009, the official Taiwan branch of Communication Technology begins a dialogue with Intel and its official distributor in Taiwan. As a result, we receive documents on the Intel PineTrail-M TigerHill platform - this is a duet of the Intel Atom processor N400 / D500 series and the NM10 chipset. To debug the first version of our board, it was decided to dissolve it in the COM Express form factor. This is a 95x95 mm mezzanine module, with a long multi-pin connector. And so that you understand the severity of the situation, the module's circuitry and wiring were made not in some new-fashioned Cadence or Altium, but in the old tube PCAD 2006.
The photo is already the second revision of this module:
')
The patient is rather alive ...
Just imagine. Soldered 5 modules. Lie down on my desk. It is urgent to run. I am in Taiwan, my boss in Moscow. Documents from Intel - reference diagram, guide for the razvodchika and a couple of datasheets per chipset and processor. Anything more there is nothing.
I want to tell you that my immediate supervisor is Anatoly Viktorovich Sorokin, an excellent and experienced engineer who changed the circuitry for compatibility with COM Express and removed from it the so-called EC - Embedded Controller. This microcircuit is responsible for starting and controlling power supplies, controlling fans, etc. things. Accordingly, the power supply chain has become trivially simple, the power supply just went up one after the other and in the end the common so-called POWER_GOOD was raised, telling the chipset that all the power was ready. In principle, this EC is absolutely not needed on this module, it can be installed on the motherboard, or it may not be installed, it does not play a noticeable role.
The board on the table, the passive board (motherboard) is also ours, simple as a detector receiver. Two power supplies - + 5B for peripherals and + 12V for the COM Express module, the launch of which is controlled by a small microcontroller. The same microcontroller polls the state of the On button, some necessary signals from the chipset are also monitored. It is now I know how this kitchen works, and then it was NOTHING UNDERSTANDING.
Okay, we supply power from a laboratory source, press the power button, the microcontroller raises + 5V and + 12V, pulls the PWRBTN # signal for 100 ms and waits a second from the chipset to raise the SUS_S5 # signal. While he was waiting for this second, one of the tantalum capacitors flew up into the air, mixing the polarity during soldering. Well, solder and check the rest. A couple had to be soldered.
Run again. SUS_S5 # is in the unit, nothing happens, the current consumption is small, it means power. I note that the launch of the power supply is generally the very first step of launching any board, but for such complex clever platforms there are 10-15 separate DC / DC converters that must be run in strict sequence, and some even with delays. In our case, the first step is to convert + 12V to two main power supplies + V5A, + V3.3A. A - this is the main power, which should be started by the iron on the power button, it feeds the chipset.
Yeah, these stuffs are there. PWRBTN # to the chipset comes. The next step is the RSMRST # signal - Resume Reset. We look where it comes from, it comes with a DC / DC converter + V5A / + V3.3A signal POWER_GOOD. It does not rise, infection, aha, since the power is present, it means that it must be pulled. We pull in, RSMRST # rises, after that SLP_S5 #, SLP_S4 # and SLP_S3 # take turns in turn from the chipset. These are so-called slipy, the chipset tells the platform - I entered the S4 state, cut in peripheral power (HDD, USB, memory, etc.), I entered the S3 state - cut in S power for everything else. The sequence is approximately the same - SLP_S4 # -> + V5, + V3.3, + V1.8 for powering DDR. SLP_S3 # -> + V5S, + V3.3S, + V0.9S for DDR, + V1.5S for CPU and chipset blocks. + V1.5S_POWER_GOOD -> + V1.05S for DMI, Analog DDR, GPIO units on the CPU and chipset. Further + V1.05S_POWER_GOOD -> + V0.89 for the graphic block CPU. And in the end, if all the power have risen, all the POWER_GOOD are assembled “AND” by logic into one common, a delay of 99 msec is done, to stabilize all the power supplies, and + VCC_CPU, the main power of the processor, is started. It is waiting for the PWROK and a separate VMPWRGD for + VCC_CPU. Fuuuh ... A couple of weeks, together with Anatoly, fought over these power supplies, as a result, one of the POWER_GOOD needed to be tightened, in the comparator circuit to control the voltage, to change the nominal values, and there was still a lot there, not to remember. As a result - all the power are, but the system is silent.
We understand further. The PWROK and VMPWRGD uplift chipset is required to inform the CPUPWRGOOD processor and raise the PLTRST # - Platform Reset. Those. He says to him - everything, power supply, I release the reset, start it! CPUPWRGOOG is rising, PLTRST # is not. Oops ... Sailed ... It's good that I still have all the captured dumps of the analyzer, here it is, the problem:
For two weeks we struggled with this problem, which we didn’t try. In the end, I found one of the endless potential problems - one of the pins of the chipset should have been pulled to the ground, and here it was hanging in the air! In general, we removed the chipset from the board, installed a thin wire on the contact and soldered a new chipset. And it earned! This is how it looked:
Unfortunately, there are no photos of how the iron looks under debugging, but, for example, the board on the Haswell platform looked on my desk like this:
Great, now it's the BIOS. While on the debug board I see the code 0x00, which means that the BIOS does not boot from the SPI EEPROM. The photo is a replica, the motherboard was different, but just to show how it approximately looked on the table:
We understand further, we get up to SPI_CLK - a clock is present, requests are coming, we get up to SPI_MOSI - the chipset issues packets of requests, we get up to SPI_MISO - zero. Tightening SPI_MISO - and cheers, code 0x87. Finally. Most likely the BIOS requires EC. We get up on the LPC with the analyzer, test and see requests to the address 0x164E and 0x164F, this is definitely EC, it hangs after the BIOS requests. Such:
Posted in AMI, Phoenix and Insyde. Phoenix sent the binary, but it didn’t start, Insyde started asking stupid questions at all, and AMI quickly understood the problem, and their binary started up the first time. Everything, the main iron is started, further only the periphery is checked.
Unexpected Audio Codec Issues
After the launch of the board, some time passed, we made a passivation with the audio codec from Realtek. Nothing foreshadowed troubles, the HDAUDIO interface hooked up the codec, the device saw OSes, even earned the output to the speaker, but some outputs and inputs simply did not work.
They wrote to Realtek, talked, it turned out that the BIOS, at the start, should fill in the audio codec with the so-called VERB Table. In essence, set the internal registers of the codec in accordance with the requirements of use. Those. of the variety of outputs - only one can really be used. This table is generated by a special application from Realtek HDACfg. It shows all the information, up to the location, color and type of connector. Well, they arrived, there are no BIOS sources, AMI did not help us for free. What to do?
I do not even remember how, but I found a program on the network (BIOS Patcher 7.0), which was able to disassemble my BIOS into its component parts. UEFI BIOS is represented as a kind of capsule, inside there is a tree structure of different types of modules. The modules are mostly packed. And some of its cunning compression. Okay, I found a way to unpack all modules, I found a module responsible for initializing devices on the HDAUDIO bus. Very lucky that the table of one of the devices was larger than mine. I replaced it with my own, and, of course, did not forget to fix the length. But it was absolutely unwilling to assemble back. EDK Tianocore helped me a lot, with the help of its utilities, namely genffsfile, gensection, genfvimage, I manually collected all the necessary sections. And it earned!
Total
Now, with some pride or something, I recall these winning moments, because there was nothing, no documentation on launching the platform, no BIOS sources, no sane support from Intel. Only intuition and experience helped.
Now it is somewhat simpler, of course, we have all the sources, you can fix anything in the BIOS quickly enough, the dialogue with AMI is adjusted, I occasionally deliver glitches to them and they correct them. Documents from Intel are already complete, i.e. for you to understand, for example, on the Broadwell platform there are about 130 of them. In Skylake, it’s already under 400. But still, the first revision of the board always ends up being finalized, there’s always something that isn’t attracted, or some other problem.
Now there is a debugger for BIOS, debugging can be viewed, and it has already rescued us many times. There is one person more in our team, a wonderful engineer, a hardware worker who solves a bunch of problems. Now we have our SMD lines, and the mystery of the pilot production takes place literally in the next room. Now Intel integrates chipsets into SoC and fewer problems with wiring. Now we have many partners and contacts around the world. But then there were other times, “we survived as best we could” ...
For the first time, perhaps, everything seemed to be just a couple of paragraphs, but in practice, with all this, they suffered for about two months. If you like it, then in the following articles we will talk about something similar, but for now ask questions in the comments.
PS And, of course, I look that way when I enter the BIOS.
References:
- " Network Technologies "
- “ Communication Technology ”
- Raydget Russia
- Raydget Taiwan
- Pocket desktop
Source: https://habr.com/ru/post/259033/
All Articles