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.
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?
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.
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