Install Libreboot on Topton X2E N150 / BKHD H30W-N150

Return to index

!!BACKUP everything!! just in case something fails.

Specifications
Manufacturer	Topton / BKHD
Name	X2E N150/H30W-1264NP-4L5G
Released	2025
Chipset	Intel Alder Lake-N
CPU	Intel N150
Graphics	Intel UHD Graphics 24EU
Memory	32GB DDR5 SODIMM (1x32 GB)
Architecture	x86_64
Intel ME/AMD PSP	Present, HAP bit set
Flash chip	SOIC-8 16MiB

W+: Works without vendor firmware; 
N: Doesn't work; 
W*: Works with vendor firmware; 
U: Untested; 
P+: Partially works; 
P*: Partially works with vendor firmware

Features
Internal flashing with original boot firmware	W*
Display (Intel GPU)	W*
Display (PCIe graphics card)	U
Audio	W+
RAM Init	W*

Download from release

If you’re using a release ROM, please ensure that you’ve inserted extra firmware required refer to the guide for that (, failure to adhere to this advice will result in a bricked machine):

• Intel ME (vendor blob)

Build from source

./mk -b coreboot topton_x2e_n150

Software

WARNING: DO NOT internal-flash on first install. Updates between Libreboot versions is fine, but the vendor firmware seems to set PRx registers blocking flashes to 0x600000-0x65ffff (384 KiB area) and AMI NVRAM is still intact. IFD FLMSTRs are all 0xffffffff so this is likely PRx (protected range) registers being set by the factory firmware. THEREFORE: external flashing recommended, on initial Libreboot installation. The fallback/postcar part in CBFS happened to be in that location under testing, so internal flashing on initial installation will likely lead to a brick.

Only follow these internal flashing notes for updating an existing install:

Before internal flashing, Disable /dev/mem protection first.

In short add this kernel parameter: iomem=relaxed(linux distro)/kernel.securelevel=-1(bsd distro)

THEN REMOVE THIS KERNEL PARAMETER TO PREVENT UNAUTHORIZED/MALICIOUS ACCESS TO YOUR SYSTEM AFTER FLASHING LIBREBOOT.

(An important reminder for those who might forget to delete it, even better, replace it with lockdown=integrity / lockdown=confidentiality)

Backup the previous (working) firmware (atleast) twice (to check and compare if reading it gone wrong and backups differs.)

flashprog -p internal -r Backup1.bin

flashprog -p internal -r Backup2.bin

Check and compare those if reading from the flash were successful:

diff Backup1.bin Backup2.bin

For more than 2:

shasum Backup1.bin Backup2.bin Backup3.bin

If those differs, something gone wrong and proceeding further may (DON’T) leave your device unrecoverable (without a reliable backup) if flashing fails as well.

Hardware (external) flashing

This method is recommended, for the initial installation when switching away from the original factory firmware.

For general information, please refer to 25xx NOR flash instructions - that page refers to use of socketed flash.

Backup the previous (working) firmware twice (to check and compare if reading it gone wrong and backups differs.)

flashprog -p serprog:dev=/dev/ttyACM0,spispeed=16M -r Backup1.bin

flashprog -p serprog:dev=/dev/ttyACM0,spispeed=16M -r Backup2.bin

Check and compare those if reading from the flash were successful:

diff Backup1.bin Backup2.bin

For more than 2:

shasum Backup1.bin Backup2.bin Backup3.bin

If those differs, something gone wrong and proceeding further may (DON’T) leave your device unrecoverable (without a reliable backup) if flashing fails as well.

The board has a single 16 MiB SOIC-8 flash chip on the bottom side of the motherboard. To access it, you need to disassemble the case and remove the board, using a Phillips head screwdriver.

The BIOS flash chip is in the bottom left of the photo below. It is silkscreened with text “SPI_ROM”. Do not mix it up with the 4 other similar flash chips marked LANx_ROM, those are for the Ethernet NICs.

• 5G modem slot untested

• USB 3.0 ports, only work at up to 2.0 speeds (480Mbps)

UART at 0x3f8: TX does not complete unless RX activity occurs. Coreboot’s own output works fine, but FreeBSD using uart0 at 0x3f8 as console will stall randomly during boot and only progress while characters are received at the serial port. Perhaps a patch could be put somewhere to keep the line hot to mitigate this?

It will eventually kernel panic, thus:

panic: spin lock held too long
_mtx_lock_indefinite_check() / _mtx_lock_spin_cookie()
uart_cnputc() / cnputc() / cnputsn() / putchar() / kvprintf() / printf()
tc_init() / tsc_calibrate() / cpu_initclocks()

FreeBSD also prints uart: ns8250: UART FCR is broken (0x1) - LSR.THRE is not set (or set late) unless there is RX activity.

Recommended workaround: hint.uart.0.disabled="1"

This is based on the following bug report: https://codeberg.org/libreboot/lbmk/issues/457 - which states also that input is extremely slow on SeaBIOS and GRUB, but please note that this was the bare-metal SeaBIOS/GRUB payloads - modern Libreboot ships with EDK2 instead, and GRUB/SeaBIOS are provided as EFI builds. EDK2 and EFI GRUB/SeaBIOS will need to be re-tested.

Nothing was done for Libreboot 26.10 to remedy this, as this workaround should do nicely; no issues were yet reported on other operating systems.

MADT: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level).

On FreeBSD irq9: acpi0 fires ~130,000-180,000 times/s. DTrace shows AcpiEvSciXruptHandler -> AcpiEvGpeDetect / AcpiEvFixedEventDetect with no GPE and no fixed event ever dispatched. On Linux (Mint 22 live, same firmware) /sys/firmware/acpi/interrupts/sci stays at 0.

Recommended workaround: hw.acpi.sci.trigger="edge"

This does not affect Linux.

Reported here: https://codeberg.org/libreboot/lbmk/issues/457

A user reported that their Intel SSDPEKKF256G8L SSD did not work in the M2 slot (pcie_rp9, 00:1d.0). Not detected. Linux dmesg:

pci 0000:00:1d.0: broken device, retraining non-functional downstream link at 2.5GT/s

A different NVMe SSD (LENSE30256GMSP34MEAT3TA) worked in the same slot, and the Intel one did work in factory firmware. Beware possible issues with SSDs.

Reported here: https://codeberg.org/libreboot/lbmk/issues/457

Nothing for this was done on Libreboot 26.10, but perhaps disabling hotplug in FSP might mitigate it; we had issues with SSDs on some other boards as well, specifically Kabylake desktops.

FreeBSD users should set vm.pmap.pcid_enabled="0" on this board, as per Alder Lake-N PCID erratum.

Reported here: https://codeberg.org/libreboot/lbmk/issues/457

The same person also measured that the logic level on their UART was 9.5V, shunted between TX and RX. This is equivalent to RS-232 logic levels.

SPDX-License-Identifier: GFDL-1.3-or-later

Markdown file for this page: https://libreboot.org/docs/install/x2e-n150.md

Site map

This HTML page was generated by the Libreboot Static Site Generator.