FAQ: change the order of some entries

1 files changed, 14 insertions, 14 deletions

diff --git a/site/faq/index.php b/site/faq/index.php
index cf8e894..6646d39 100644
--- a/site/faq/index.php
+++ b/site/faq/index.php
@@ -47,8 +47,8 @@
 						<a href="#intel">Why is the latest Intel hardware unsupported in libreboot?</a>
 						<ul>
 							<li><a href="#intelme">Intel Management Engine (ME)</a></li>
-							<li><a href="#microcode">CPU microcode updates</a></li>
 							<li><a href="#fsp">Firmware Support Package (FSP)</a></li>
+							<li><a href="#microcode">CPU microcode updates</a></li>
 							<li><a href="#intelbastards">Intel is uncooperative</a></li>
 						</ul>
 					</li>
@@ -151,6 +151,19 @@
 							The libreboot project strongly recommends that you avoid it entirely, and this means avoiding all recent generations of Intel hardware.
 						</i></b>
 					</p>
+				<h3 id="fsp">Firmware Support Package (FSP) <span class="ref">(<a href="#fsp">#fsp</a>)</span></h3>
+					<p>
+						On all recent Intel systems, coreboot support has revolved around integrating a blob (for each system) called
+						the <i>FSP</i> (firmware support package), which handles all of the hardware initialization, including
+						memory initialization. Reverse engineering and replacing this blob is almost impossible, due to how complex it is. Even for the most skilled developer,
+						it would take years to replace. Intel distributes this blob to firmware developers, without source.
+					</p>
+					<p>
+						Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is
+						a special mode that operates below the operating system level. <b>It's possible that rootkits could be implemented there, which could
+						perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at
+						all.</b> In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find them).
+					</p>
 				<h3 id="microcode">CPU microcode updates <span class="ref">(<a href="#microcode">#microcode</a>)</span></h3>
 					<p>
 						All modern x86 CPUs (from Intel and AMD) use what is called <i>microcode</i>. CPUs are extremely complex,
@@ -177,19 +190,6 @@
 						you had the source code. If you try to upload your own modified updates, the CPU will reject them. In other words,
 						the microcode updates are <i><a href="https://www.gnu.org/proprietary/proprietary-tyrants.html">tivoized</a></i>.
 					</p>
-				<h3 id="fsp">Firmware Support Package (FSP) <span class="ref">(<a href="#fsp">#fsp</a>)</span></h3>
-					<p>
-						On all recent Intel systems, coreboot support has revolved around integrating a blob (for each system) called
-						the <i>FSP</i> (firmware support package), which handles all of the hardware initialization, including
-						memory initialization. Reverse engineering and replacing this blob is almost impossible, due to how complex it is. Even for the most skilled developer,
-						it would take years to replace. Intel distributes this blob to firmware developers, without source.
-					</p>
-					<p>
-						Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is
-						a special mode that operates below the operating system level. <b>It's possible that rootkits could be implemented there, which could
-						perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at
-						all.</b> In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find them).
-					</p>
 				<h3 id="intelbastards">Intel is uncooperative <span class="ref">(<a href="#intelbastards">#intelbastards</a>)</span></h3>
 					<p>
 						For years, coreboot has been struggling against Intel. Intel has been shown to be extremely uncooperative in general.