Tag Archives: coreboot

Meraki MS350 hardware overview

2 Replies

The Meraki MS350 (MS350-24 and MS350-48) series switches offer 24 or 48 ports of Gigabit Ethernet. The MS350-24X offers 16 ports of Gigabit Ethernet, and 8 ports of multi-Gigabit (1/2.5/5/10G) Ethernet. All models have four SFP/SFP+ uplink ports, a dedicated remote management port, and stacking capabilities via QSFP. Today we will be looking at the MS350-48 and MS350-24X models specifically.

MS350-48LP from Meraki’s datasheet

Here is a quick summary of the MS350 specs:

  • Intel Atom C2358 CPU (2C/2T, 1.74GHz)
  • 2GB DDR3 ECC RAM (SODIMM, Unigen U25U7210N8FD-BDD-CCHF1)
  • 16MB SPI flash, 2GB NAND flash (TSOP48 NAND on motherboard, USB via Phison)
  • MS350-24X: 30 Network interfaces (16 Gigabit Ethernet, 8 mGig Ethernet, 4 SFP+, 2 QSFP stacking)
  • MS350-48: 54 Network interfaces (48 Gigabit Ethernet, 4 SFP+, 2 QSFP stacking)
  • MS350-24X: MA-PWR-1025WAC
  • MS350-48: MA-PWR-250WAC (identical to PWR-C2-250WAC)

The MS350 RAM can be upgraded: the 4GB (HMT351A7CFR8C) and 8GB (HMT41GA7MFR8C) PC3-12800E SODIMMs have been confirmed to work. Non-ECC SODIMMs are not compatible.

Model Codename Part number
MS350-24 (P) BigPony 600-36010 (P: 600-36020)
MS350-48 (LP/FP) BigPony 600-36030 (LP: 600-36040, FP: 600-36050)
MS350-24X Clydesdale 600-48010

The MS350-48 uses the Broadcom BCM56547 (A0) ASIC, with BCM84740 PHYs. The MS350-24X uses the Broadcom BCM56546 (B0) ASIC, with BCM82578 and Aquantia AQR405 PHYs. PoE versions of the switch use the Broadcom BCM59121 PSE controller.

MS350-48:

00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC Transaction Router (rev 02)
00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 1 (rev 02)
00:03.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 3 (rev 02)
00:0b.0 Co-processor: Intel Corporation Atom processor C2000 QAT (rev 02)
00:0e.0 Host bridge: Intel Corporation Atom processor C2000 RAS (rev 02)
00:0f.0 IOMMU: Intel Corporation Atom processor C2000 RCEC (rev 02)
00:13.0 System peripheral: Intel Corporation Atom processor C2000 SMBus 2.0 (rev 02)
00:14.0 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:14.1 Ethernet controller: Intel Corporation Ethernet Connection I354 1.0 GbE Backplane (rev 03)
00:14.2 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:14.3 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:1f.0 ISA bridge: Intel Corporation Atom processor C2000 PCU (rev 02)
00:1f.3 SMBus: Intel Corporation Atom processor C2000 PCU SMBus (rev 02)
01:00.0 Ethernet controller: Broadcom Inc. and subsidiaries Device b547 (rev 01)
01:00.1 Ethernet controller: Broadcom Inc. and subsidiaries Device b547 (rev 01)

MS350-24X:

00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC Transaction Router (rev 02)
00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 1 (rev 02)
00:03.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 3 (rev 02)
00:0b.0 Co-processor: Intel Corporation Atom processor C2000 QAT (rev 02)
00:0e.0 Host bridge: Intel Corporation Atom processor C2000 RAS (rev 02)
00:0f.0 IOMMU: Intel Corporation Atom processor C2000 RCEC (rev 02)
00:13.0 System peripheral: Intel Corporation Atom processor C2000 SMBus 2.0 (rev 02)
00:14.0 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:14.1 Ethernet controller: Intel Corporation Ethernet Connection I354 1.0 GbE Backplane (rev 03)
00:14.2 Ethernet controller: Intel Corporation Ethernet Connection I354 1.0 GbE Backplane (rev 03)
00:14.3 Ethernet controller: Intel Corporation Ethernet Connection I354 1.0 GbE Backplane (rev 03)
00:1f.0 ISA bridge: Intel Corporation Atom processor C2000 PCU (rev 02)
00:1f.3 SMBus: Intel Corporation Atom processor C2000 PCU SMBus (rev 02)
01:00.0 Ethernet controller: Broadcom Inc. and subsidiaries Device b546 (rev 11)

Both models have the same USB devices present:

Bus 001 Device 002: ID 8087:07db
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 003: ID 13fe:5200

MS350-24X and MS350-48 both use coreboot as the bootloader, although the MS350-24X model has a different build. In both cases, the ROM has the following layout:

00000000:00010000 reserved
00010000:0070ffff bk1
00710000:00dfffff bk2
00e00000:00ffffff coreboot

The cbfs contains the following:

FMAP REGION: COREBOOT
ms350-24x_w25q128.bin: 16384 kB, bootblocksize 1024, romsize 16777216, offset 0xe10000
alignment: 64 bytes, architecture: x86

Name                           Offset     Type           Size   Comp
cmos_layout.bin                0xe10000   cmos_layout      1396 none
fallback/romstage              0xe105c0   (unknown)       21624 none
fallback/ramstage              0xe15a80   (unknown)       49421 none
fallback/payload               0xe21c00   simple elf      23042 none
config                         0xe27640   raw              4676 none
revision                       0xe288c0   raw               566 none
(empty)                        0xe28b40   null          1209432 none
mrc.cache                      0xf4ffc0   mrc_cache       65536 none
cpu_microcode_blob.bin         0xf60000   microcode       84992 none
(empty)                        0xf74c40   null            45912 none
fsp.bin                        0xf7ffc0   fsp            389120 none
(empty)                        0xfdf000   null           134040 none

coreboot was built with an ELF payload (miles) which by default loads and jumps into the bootkernel FIT image located at 0x10000. A secondary bootkernel exists on flash at offset 0x710000.

This is very similar to the MX84 as they are both based on the same Rangeley platform.

The entire MS350 series is based on the Intel Atom C2000 series CPU, which Meraki also used in the MX84. Sadly, the MS350 also suffers from the AVR54 errata, as the C2358 in both the MS350-48 and MS350-24X is the B0 revision.

LPC_CLK is exposed on pin 1 of J35, with R3635 carrying 3.3V (MS350-48 and MS350-24X). Therefore, you can add a 100 Ohm resistor between R3635 and pin 1 to pull up the LPC clock. Just be sure to use an “extended-life” resistor for the modification, you wouldn’t want to compromise the MTBF of your Meraki product with anything sub-par 😉

100 Ohm resistor to pull up LPC clock (MS350-24X)

If you wish to flash your MS350, you will need to remove or socket the SOIC8 SPI flash (SK_U1).

This is because there are other devices powered by the +3.3V voltage rail used by SPI flash, which interferes with your ability to read/write the contents of flash. I prefer the Wieson G6179-10 SOIC8 socket (available from Adafruit). People outside the US will probably find it easier to desolder the flash and use a SOIC8 socket with prototype wires, as the G6179-10 is difficult to obtain for a reasonable price.

The UART header is J31 on both the MS350-48 and MS350-24X and follows the standard Meraki UART pinout (1: VCC, 2: Tx, 3: Rx, 4: GND)

Similar to the MS210/225 series, the Broadcom SDK implements the packet engine in userspace, using the linux_kernel_bde and linux_user_bde kernel modules to interface with the ASIC. In the Meraki firmware, the packet engine is a component of the userspace click daemon, which loads the bcm_click shared object during click router initialisation.

Idle power consumption:

  • MS350-24: 45W
  • MS350-24P: 57W
  • MS350-48: 54W
  • MS350-24X: 96W

GPL source code for the MS350 was requested from Meraki in July 2023. At the time of writing, they have not provided any. I will update this post with links to the source code when it is provided.

Meraki MX84 overview

2 Replies

I became aware of the Meraki MX84 from Lathe Abusaid’s blog post about tearing down the hardware. After setting up an eBay alert and waiting, I finally won a job lot which included an MX84.

Here is a quick summary of the MX84 specs:

  • Intel Atom C2358 CPU (2C/2T, 1.74GHz)
  • 4GB DDR3 ECC RAM (H5TC4G83CFR-PBA)
  • Internal SATA port (1TB Western Digital Green)
  • External USB2.0 port
  • 13 Network interfaces (Vitesse VSC7425: 11 Gigabit Ethernet, 2 SFP)
  • 16MB SPI flash, 1GB NAND flash (Phison PS2251, USB on motherboard)
  • Fanless
  • Open frame 12V 2.5A power supply

The device runs Linux 3.18.131.

00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC Transaction Router (rev 02)
00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 1 (rev 02)
00:03.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 3 (rev 02)
00:0b.0 Co-processor: Intel Corporation Atom processor C2000 QAT (rev 02)
00:0e.0 Host bridge: Intel Corporation Atom processor C2000 RAS (rev 02)
00:0f.0 IOMMU: Intel Corporation Atom processor C2000 RCEC (rev 02)
00:13.0 System peripheral: Intel Corporation Atom processor C2000 SMBus 2.0 (rev 02)
00:14.0 Ethernet controller: Intel Corporation Ethernet Connection I354 1.0 GbE Backplane (rev 03)
00:14.1 Ethernet controller: Intel Corporation Ethernet Connection I354 1.0 GbE Backplane (rev 03)
00:14.2 Ethernet controller: Intel Corporation Ethernet Connection I354 1.0 GbE Backplane (rev 03)
00:14.3 Ethernet controller: Intel Corporation Ethernet Connection I354 1.0 GbE Backplane (rev 03)
00:16.0 USB controller: Intel Corporation Atom processor C2000 USB Enhanced Host Controller (rev 02)
00:17.0 SATA controller: Intel Corporation Atom processor C2000 AHCI SATA2 Controller (rev 02)
00:18.0 SATA controller: Intel Corporation Atom processor C2000 AHCI SATA3 Controller (rev 02)
00:1f.0 ISA bridge: Intel Corporation Atom processor C2000 PCU (rev 02)
00:1f.3 SMBus: Intel Corporation Atom processor C2000 PCU SMBus (rev 02)

The MX84 uses coreboot as the bootloader (coreboot-af6fa06-dirty-Liteon_GRM1001_MFG_v4.0.0; bootlog) and the ROM has the following layout:

00000000:00010000 reserved
00010000:0070ffff bk1
00710000:00dfffff bk2
00e00000:00ffffff coreboot

The cbfs contains the following:

FMAP REGION: COREBOOT
mx84.bin: 16384 kB, bootblocksize 1024, romsize 16777216, offset 0xe00000
alignment: 64 bytes, architecture: x86

Name                           Offset     Type           Size   Comp
cmos_layout.bin                0xe00000   cmos_layout      1352 none
fallback/romstage              0xe00580   (unknown)       25820 none
fallback/ramstage              0xe06ac0   (unknown)       61965 none
fallback/payload               0xe15d40   simple elf      20349 none
config                         0xe1ad00   raw              4310 none
revision                       0xe1be00   raw               712 none
(empty)                        0xe1c100   null          1261208 none
mrc.cache                      0xf4ffc0   mrc_cache       65536 none
cpu_microcode_blob.bin         0xf60000   microcode       84992 none
(empty)                        0xf74c40   null            45912 none
fsp.bin                        0xf7ffc0   spd            389120 none
(empty)                        0xfdf000   null           134040 none

coreboot was built with an ELF payload (miles) which by default loads and jumps into the bootkernel FIT image (dts here) located at 0x10000. A secondary bootkernel exists on flash at offset 0x710000.

Let us revisit those Intel I354 interfaces. As a networking appliance, the MX84 has a lot of network interfaces.

There are 13 network interfaces on the front (Management, Internet 1 & 2, Ethernet 3-10, and 2 SFP cages) so there should be a switch inside the MX84 or we would expect to see more than four interfaces in lspci.

In this case, the switch is the VSC7425, and even if you use the 3.18.131 kernel from Meraki, you won’t have any connectivity because all four of the I354 interfaces connect directly to the VSC7425

The stock Meraki firmware uses a binary called vtss_poca_d to initialise and configure the VSC7425, which does so using a proprietary Vitesse framework (PDF).

vtss_poca_d is a static binary, so could we use it with a newer kernel such as 5.10.146 found in OpenWrt 22.03?

$ vtss_poca_d
mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:0 failed: Not supported
mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:1 failed: Not supported
mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:2 failed: Not supported
mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:3 failed: Not supported
mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:0 failed: Not supported
mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:1 failed: Not supported
mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:2 failed: Not supported
mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:3 failed: Not supported
mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:0 failed: Not supported
mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:1 failed: Not supported
mdio_read16: SIOCGMIIREG on eth0 phy:0 reg:2 failed: Not supported
mdio_read16: SIOCGMIIREG on eth0 phy:0 reg:3 failed: Not supported
mdio_read16: SIOCGMIIREG on eth0 phy:0 reg:2 failed: Not supported
mdio_read16: SIOCGMIIREG on eth0 phy:0 reg:3 failed: Not supported

Nope! As such, it is very unlikely this device will ever be supported by OpenWrt.

You may have noticed that the MX84 is based on the Atom C2000, a CPU which suffers from the AVR54 errata. When I first received my MX84, there was no output on UART and the power consumption was a suspiciously consistent 6W, all the hallmarks of a device dead from AVR54. There are numerous instructions for how to revive a Synology NAS with a dead Atom, but no such instructions exist for the MX84.

Fortunately for me, there was a photo from Lathe Abusaid’s blog post which provided a crucial hint. It appears that the MX84 unit photographed in their teardown includes a 100 Ohm resistor between pins 1 (LPC clock) and 9 (3.3V) of header J7.

This solution appears to have been chosen because it was the most convenient for Cisco, however note that pin 9 of J7 appears to be a GPIO output which, depending on the coreboot payload, may not always be active high. I would suggest instead soldering to pin 8 of the unpopulated SOIC8 nearby (U47), which will provide 3.3V regardless of the payload GPIO configuration.

That being said, here is a photo of the resistor fix to J7 that I just advised against doing, taken before realizing pin 9 was a GPIO

After soldering the pull-up resistor, the LPC clock is back on pin 1 of J7:

Oscilloscope output of the LPC clock on pin 1 of J7 after adding a 100Ω resistor

There is an unpopulated footprint for a Micro-USB port on the left side of the motherboard. By default the D-/D+ are not connected, as the 0 Ohm resistors are unpopulated (they are instead populated on R467/R468 connecting the Phison ps2303q to the Atom CPU). I believe this port was used during development to easily swap the USB drive connected to the SoC.

One question I had about the MX84 was: why coreboot? It seems that this design is based on Intel’s “Mohon Peak” reference platform. From the Intel customer reference board (CRB) documentation (PDF):

The embedded firmware ecosystem has developed an example boot loader solution
for the CRB that uses the FSP kit. This solution is based on the open source Coreboot
project at coreboot.org. While Intel does not endorse or support boot loader solutions
based on the Coreboot project, the example Coreboot-based boot loader provides a
good teaching model for how to integrate the Intel FSP into a complete boot loader
solution.

Now it is clear why Meraki chose to use coreboot, that is simply the bootloader reference provided by Intel for Mohon Peak. Other manufacturers who made Atom C2000 products also used coreboot (such as the VeloCloud 520-AC).

Meraki provided the coreboot source code in December 2022, after a delay of more than 12 months. The coreboot source code for the MX84 is available on GitHub.

Meraki hardware commanding the premium that it does, if you are considering buying an MX84: don’t. The VeloCloud 520-AC (C2358) and 540-AC (C2558) are available for ~$30 on eBay and have the C0 revision which doesn’t suffer from AVR54.

If you already own an MX84 and want to poke around, here is a buildroot based firmware that you flash to SPI. The firmware will boot, initialize the switch, DHCP, and start an SSH server (the root password is the device serial without hyphens). Note that it is initramfs based, so no changes are persisted.

Caveat emptor: VeloCloud devices have an issue with the igb/I354 compatibility, meaning that only the two SFP cages are functional. However, that is two more interfaces than you will get from the MX84 (zero) with any other kernel.

coreboot for CompuLab Intense PC

4 Replies

I am very pleased to announce that coreboot now supports the CompuLab Intense PC and MintBox 2! ??

Building coreboot
The instructions for building coreboot yourself can be found on the coreboot Wiki. You will need a Linux system with typical development packages installed such as build-essential.

Select CompuLab and Intense-PC in the Mainboard section of the coreboot menuconfig:

You need to decide at this point whether you wish to use the internal full-height PCI-Express slot for mSATA or as PCI-Express:

If you have not installed an additional mSATA SSD in your Intense PC, then you do not need to select this option. Selecting the mSATA option is only required if you have installed an mSATA SSD and want to use it in the Intense PC:

Because coreboot does not have full support for the embedded controller (EC) in the Intense PC right now, the choice of using mSATA or PCIe cannot be made at runtime. If later you wish to change the function of the slot, you need to rebuild coreboot while selecting the appropriate choice of mSATA or PCIe.

Note that the mSATA port is limited to SATA 3Gbps speeds. This is a hardware limitation of the Intense PC design, and cannot be changed by flashing coreboot.

It is important to include the Firmware Descriptor Table (FDT), ME, and GbE regions of flash. Specify these files in the Chipset section:

You can choose yourself if you want to run me_cleaner on the ME or not. Note that if you choose to run me_cleaner, all SATA ports will cease to function. This is not a coreboot specific bug, the same behaviour occurs on the CompuLab firmware when me_cleaner is run. It may or may not be possible to fix this issue, more research is needed to understand the root cause.

If you want to have video during POST, you also need to include the Intel VGA BIOS in the image. Specify this in the Devices section:

In theory coreboot graphics init is supposed to initialize the Intel HD graphics without the need for the VGA BIOS, however without the VGA BIOS I was unable to get any video output until the Linux kernel started booting. This makes using the bootloader menu or troubleshooting pre-boot issues very difficult.

I would recommend you enable logging to cbmem at a minimum. This will allow you to access the coreboot boot log in Linux using the cbmem utility. If you have trouble booting the Intense PC after flashing coreboot, I would recommend you enable logging to UART, and use the included serial dongle to debug coreboot via RS-232 (115200n8). UART support for the Intense PC should be accepted to coreboot master shortly.

The default boot order of SeaBIOS seems to be SATA HDD if present, then PXE boot (if compiled with iPXE). It is possible and easy to change this, by specifying a bootorder file to include in cbfs when building coreboot.

I have created a boot order file which searches for boot devices in the following order:

  1. USB 2.0 devices
  2. USB 3.0 devices
  3. SATA devices (in order: 2.5″ internal, mSATA, eSATA, FACE module)
  4. iPXE

You can download the bootorder file and include it in cbfs. If you don’t include iPXE as a payload, remove the last line of the bootorder.txt file. If you are not building SeaBIOS as a payload, then you do not require this file.

After building coreboot, but before flashing, we need to split the coreboot.rom file into two 8MB files. This is because the Intense PC has two 8MB NOR flash chips totaling 16MB.

Split the coreboot.rom file into two 8MB files “SC1.bin” and “SC2.bin” using dd:
$ dd if=build/coreboot.rom of=SC1.bin bs=1M count=8
$ dd if=build/coreboot.rom of=SC2.bin bs=1M skip=8

Extracting binary firmware components
You may notice above that several portions of the initial Intense PC firmware are required to successfully build coreboot. The Intel Descriptor file (otherwise known as the Flash Descriptor Table or FDT), Management Engine firmware, Gigabit Ethernet region, and VGA BIOS.

If you have not yet installed the CompuLab firmware update to address CVE-2017-8083, you should be able to dump the entire firmware using flashrom in Linux:
# flashrom -p internal:laptop=force_I_want_a_brick -r intense_pc.bin

If you have already patched your system, then flashrom will be unable to dump the firmware:
Enabling flash write... Warning: SPI Configuration Lockdown activated.
FREG0: Warning: Flash Descriptor region (0x00000000-0x00000fff) is read-only.
FREG2: Warning: Management Engine region (0x00003000-0x00cfffff) is locked.

You will have to use a hardware method to dump the firmware from the chips. As an example, using a ch341 based SPI programmer and flashrom:
# flashrom -p ch341a_spi -r sc1.bin
# flashrom -p ch341a_spi -r sc2.bin

Confirm that sc1.bin contains the start of the flash descriptor:
$ hexdump -C sc1.bin | head -2
00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000010 5a a5 f0 0f 03 01 04 03 06 02 10 12 20 01 21 00 |Z........... .!.|

Do not forget to concatenate the firmware together into a 16MB image before running ifdtool:
$ cat sc1.bin sc2.bin > intense_pc.bin

You can then extract the regions from the firmware using ifdtool (included in coreboot/utils):
$ ifdutil -x intense_pc.bin

The output of ifdtool should appear as follows:
File intense_pc.bin is 16777216 bytes
Flash Region 0 (Flash Descriptor): 00000000 - 00000fff
Flash Region 1 (BIOS): 00d00000 - 00ffffff
Flash Region 2 (Intel ME): 00003000 - 00cfffff
Flash Region 3 (GbE): 00001000 - 00002fff
Flash Region 4 (Platform Data): 00fff000 - 00000fff (unused)

ifdtool will output files for each flash region. For building coreboot, we are interested in the following regions:
flashregion_0_flashdescriptor.bin
flashregion_2_intel_me.bin
flashregion_3_gbe.bin

If ifdtool doesn’t work for some reason, verify that you have concatenated the firmware files in the correct order. Or, if you don’t want to use ifdtool, you can split it manually using dd.

Intel Descriptor file/FDT:
$ dd if=intense_pc.bin of=descriptor.bin bs=4096 count=1

Management Engine:
$ dd if=intense_pc.bin of=me.bin bs=4096 count=1028 skip=3

Gigabit Ethernet region:
$ dd if=intense_pc.bin of=gbe.bin bs=4096 count=2 skip=1

You can extract the VGA BIOS from within Linux. First, verify the PCI ID of the Intel integrated graphics controller. On the Intense PC, this should be 00:02.0:
$ lspci | grep Graphics
00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09)

Once you have confirmed the PCI ID, you can dump the VGA BIOS to a file:
# echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom
# cat /sys/devices/pci0000:00/0000:00:02.0/rom > vgabios.bin
# echo 0 > /sys/devices/pci0000:00/0000:00:02.0/rom

vgabios.bin should be exactly 65536 bytes and begin similar to the following:
$ hexdump -C vgabios.bin | head -2
00000000 55 aa 78 e9 b8 e9 30 30 30 30 30 30 30 30 30 30 |U.x...0000000000|
00000010 30 30 90 24 e9 a9 23 a0 40 00 b0 0a 30 30 49 42 |00.$..#[email protected]|

It is recommended to also dump the video bios table (VBT) to a file to include in cbfs, as the VBT table is expected by Windows:
# cat /sys/kernel/debug/dri/0/i915_vbt > vbt.bin

vbt.bin should be exactly 6144 bytes and look similar to the following:
$ hexdump -C vbt.bin | head -2
00000000 24 56 42 54 20 53 4e 42 2f 49 56 42 2d 4d 4f 42 |$VBT SNB/IVB-MOB|
00000010 49 4c 45 20 64 00 30 00 b8 10 e7 00 30 00 00 00 |ILE d.0.....0...|

Flashing coreboot

The following instructions are provided AS-IS and with no warranty, express or implied. Flashing coreboot can turn your computer into a brick and will void your warranty. By following these instructions you acknowledge these risks and assume all liability.

To flash coreboot onto your Intense PC, you will need an SPI programmer supported by flashrom.

An inexpensive option is a CH341 based SPI programmer (<$2 USD from eBay/AliExpress):

Another useful tool which can also be used for flashing is the Bus Pirate (~$25 USD):

The Raspberry Pi should also work. Here is a detailed post on how to use the Raspberry Pi to flash firmware to a NOR flash.

Unfortunately for us, the NOR flash in the Intense PC is in a WSON package (very very thin small outline no lead package) so a SOIC clip or SOIC socket will not work.

Because the Intense PC uses the chassis as a heat sink, you need to remove the motherboard from the Intense PC chassis to access the NOR flash. To do this, first remove the hard drive and hard drive carrier secured by a single screw:

Next, remove the 4 screws securing the bottom plate to the chassis:

Next, remove the retaining screw of the FACE module:

Next, remove the screw and two stand-offs securing the motherboard to the chassis. The screw is by the Ethernet ports, and the two stand-offs: one near the audio ports and one under the FACE module:

Disconnect the WiFi antennas (if installed) and disconnect the front panel connector near the SODIMM sockets. You should now be able to lift the motherboard out of the chassis.

You will find the two NOR flash modules on the reverse side of the motherboard:

You will need to solder connections to the pads beside each chip to back up the original firmware and to flash coreboot.

If you’re using the ch341 based programmer, then the flashrom commands would be the following:
For the NOR flash near SC1: $ sudo flashrom -p ch341a_spi -w SC1.bin
For the NOR flash near SC2: $ sudo flashrom -p ch341a_spi -w SC2.bin

Conclusion
If you value open-source software and want an alternative to the closed-source and infrequently updated CompuLab firmware, then coreboot is a great choice for the Intense PC/MintBox 2.

However building and flashing coreboot on the Intense PC is not without its risks. You will void your warranty and specialized equipment such as a soldering iron and SPI flashing tool are required.

I was disappointed to find multiple vulnerabilities in CompuLab’s Intense PC firmware. These serious vulnerabilities and CompuLab’s rather lackluster response inspired me to port coreboot to the Intense PC.

I am not an expert on the inner workings of the x86 platform and boot process, so I could not have successfully completed this port without the assistance of the excellent autoport tool.

Coreboot advantages

  • ?Open-source firmware?
  • Better memory (RAM) compatibility than the CompuLab firmware
  • Memtest86+ and iPXE can be included as a payload in flash
  • Verified boot supported via vboot

Limitations

  • VBIOS is required if you want any video output before the kernel framebuffer is initialized
  • VGA hand-off to Windows is still not working
  • ME firmware is still necessary for most users as me_cleaner breaks SATA
  • Currently no easy path to support UEFI
  • No FACE modules except for the included 4 port USB2.0 FACE module (FM-4USB) are supported (due to lack of additional FACE modules to test)

Please note that due to copyright concerns I cannot distribute binary firmware components such as the ME firmware or video BIOS. Additionally, for technical reasons I cannot provide a fully built, flashable coreboot image for your Intense PC. This is the reason for the “Extracting binary firmware components” section of the article.

If you experience issues building or using coreboot, please leave a comment or subscribe to the coreboot mailing list and ask your question there.

The coreboot project and I make no guarantee these instructions and the resulting firmware won’t turn your system into a fancy brick. The instructions produce a bootable firmware on my hardware (MintBox 2) at the time of writing, although this could change at some point in the future.

Please exercise caution and common sense when modifying system firmware and ensure you always have a backup of the original firmware on another device should something go wrong.