ternal components Large for minimum operation Lower, both component cost and system Higher cost including external components Boot process and application load A microcontroller boots using a relatively simple process where the boot image is stored in a known location on (internal) flash memory and during boot, the chip points the (primary) pro- cessor Program Counter (PC) to the location of this image. This is relatively simple and straight- forward. In a microprocessor with an os image that is stored in external (flash or drive) memory, the boot process becomes more complex. The initial boot from power-on is done from an on-chip Read Only Memory (ROM) that initializes key peripherals (say, I2C, PCIe, or other). The "real" os is stored on a memory peripheral that is connected over one of these peripherals and is loaded from there. The second stage is loading the bootloader (Universal Bootloader aka U-Boot or UEFI being commonly used standards) which both creates the Ramdisk (that will hold the root file system) and loads the Linux kernel. From there, the Linux kernel boot take over. In case of an x86 (Intel) central processing unit (CPU), the boot process starts from a Baseboard Management Controller (BMC-potentially part of the Platform Control Hub or PCH) which configures the main CPU for it to be able to come out of reset and load its image bootloader from an eSPI connected flash memory, in addition to monitoring hardware state (temperature, power supply voltages, remote management access, and so on). From there onwards, the boot process is identical to that of a microprocessor. BMCs can enable advanced features such as a dedicated management Ethernet interface that is intended not to be connected to the Internet. As a side note: keep in mind that flash storage is limited in the number of times it can be written on-typically somewhere in the range of 10,000 S of times. Using flash storage for continued tracing/logging (as opposed to dumping hopefully rare crash reports) is not recommended for this reason with