4 Replies Latest reply on Sep 21, 2014 4:23 PM by Andromeda

    Remote Management Unit Binary for Quark SOC

    Andromeda

      I am new at the x86 architecture for embedded systems. I am trying to set up the Quark SoC X1000 installed in the Galileo Board from scratch. I want to develop an operating system. Long term project; also a learning opportunity.

       

      At this point I am trying to understand how to start the processor. My question is this, is the binary code provided by Intel for the Remote Management Unit in the Galileo board as part of the BSP exclusively developed by intel or can the developer write his or her own code for the RMU?

       

      The Binaries provided by Intel come with a proprietary license and there is no detailed mention of the operation of the RMU in the datasheet. There is, however, a detailed description of the registers, and I also understand that the RMU binaries are fetched from the SPI memory device before the processor starts executing any code at all. The first 2KB reads from SPI before reading top of memory - 16.

       

      Here, I want to ask another question: is there a more detailed description of the RMU operation?

       

      Thanks beforehand.

        • 1. Re: Remote Management Unit Binary
          JPMontero_Intel

          Hi Andromeda

           

          I think the information you are looking is in the UEFI Firmware Writer’s Guide https://communities.intel.com/docs/DOC-22477 . More Quark documents can be found at https://communities.intel.com/community/makers/documentation/quarkdocuments. Also the software developer’s manuals for the architectures might be useful https://www-ssl.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html . I hope you find this helpful.

           

          Regards,
          JPMontero_Intel

          • 2. Re: Remote Management Unit Binary
            Andromeda

            JPMontero_Intel

             

            I have read the documentation. As far as I understand, the Remote Management Unit (RMU) is something that is not open for the developer to program or modify. This is my understanding from the lack of information about what it does exactly and by the fact that it works with the binary file provided directly by Intel.

             

            For instance, there is a detailed description of the RMU registers, but there is no description of the operation of the RMU. In other words, as a developer you have access to the registers and through them you access and control the functionality already implemented by Intel in the RMU.bin rather than being able to develop such binary by yourself. This is also why the latest specification review adds an additional control register to the RMU that controls the SPI DMA deactivation after boot. Am I correct on these assumptions or there is a way of programming the behavior of the RMU?

             

            Thanks.

            • 3. Re: Remote Management Unit Binary
              Andromeda

              In some ways, it seems that the RMU is a reduced version of the Intel(r) vPro engine since it provides the Quark SoC with two important services that are inherited from the vPro: system recovery, and security management and protection. It may be for this reason that I can't find any specifications about the RMU; at least none that would allow me to develop my own firmware for it. In any case, I am still not sure if it is possible to develop such a firmware with all the specs made available publicly by Intel.

              • 4. Re: Remote Management Unit Binary
                Andromeda

                It seems that I have been correct about my interpretation of the RMU binaries; the RMU is, as a matter of fact, an engine similar to the vPro engine. The binary provided by Intel that is required by the RMU is what the Intel Architecture Manual Volume 1 describes as the Microcode Update Facilities. The Quark's RMU works in such a way that the firmware programmer doesn't have to worry too much about the process of updating the microcode. The programmer still has to provide the address at which the microcode is placed in RAM after memory initialization, but the RMU takes care of decoding and interpreting this code.

                 

                Read the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, Section 9.11