Category Archives: Hardware

Asus PN50 4700U review

6 Replies

The Asus PN50 is a NUC-sized mini PC based on AMD’s Renoir mobile platform. The PN50 is available in four configurations ranging from a Ryzen 3 4300U (4C/4T) to Ryzen 7 4800U (8C/16T).

I am not made of money and the 4800U commands an extreme premium for less than extreme additional performance over the 4700U (8C/8T), so I ordered the 4700U. I pre-ordered the 4700U in August for 370£ (408€) from Amazon UK (EU prices were 🤪).

Due to reasons which were never well communicated by Asus or Amazon, the release date of the product was delayed several times from early September 2020 until mid-October 2020.

tl;dr – The PN50 with the Ryzen 7 4700U offers a lot of computing power for the size and power budget, and offers a healthy amount of IO. If you are in the market for a NUC-sized PC, you would be remiss if you did not consider the PN50. The 4700U offers impressive performance, beating an i9-8950HK at one third the power.

The PN50 is sold as a barebones system, although some retailers offer it as a bundle with RAM and an SSD if you prefer overpaying for someone else installing 3 socketed components.

In the box:

  • Asus PN50
  • 19V power supply (65W for 4300/4500U, 90W for 4700/4800U)
  • IEC 60320 “mickey mouse” power cable
  • VESA mount
  • Screws for mounting the 2.5″ hard drive, M.2 SSD, and VESA mount
  • User’s guide and driver CDROM

Typical reviews are full of benchmarks (both CPU and GPU), but I want to provide my own perspective on the system so the benchmark section will be brief.

Renoir eats Intel’s mobile offers for lunch. The newest Intel system I have access to is an XPS 15 (9570) laptop with an Intel Core i9-8950HK.

Ryzen 7 4700U (Asus PN50) versus Intel Core i9-8950HK (XPS 15″ 9570)

The PN50 with Ryzen 7 4700U scores 10% higher in single-threaded performance and 12% higher in multi-core performance. The 8950HK is not the latest from Intel, but it’s still incredibly impressive that the Ryzen 7 4700U delivers superior performance at one third the power (i9-8950HK: 45W TDP; Ryzen 7 4700U: 15W TDP).

Looking at the internals of the Asus PN50, it seems that the configurable port that Asus offers on the rear is achieved by the use of a ribbon cable to a daughterboard:

DisplayPort daughterboard in the Asus PN50

On all retail units that I have seen for sale thus far, the port is configured as a full size DisplayPort. The Asus website shows DisplayPort, RS-232, VGA, and RJ-45 options under the configurable port. I don’t know if Asus ever plans to sell the FPC and daughterboards separately or if they will only be available as BTO options.

There is an FPC connector present for the secondary network (or RS-232) interface, as well as another FPC connector present for an M.2 carrier (though it isn’t clear what interface the M.2 card would use):

Unused FPC connectors for secondary LAN and M.2 card

Removing the metal guide for the bottom of the internal chassis is simple, only 4 Philips screws, and two cables (one for 2.5″ SATA connector and one for the micro SD reader):

Removing the bottom of the internal chassis is straightforward

Removing the plastic rear IO shield is also easily accomplished, as there are only 6 plastic retention clips and only 3 need to be released to remove it:

Clips to remove the plastic rear IO shield
Rear view of the PN50 with plastic IO shield removed

Unfortunately, I was unable to determine how you remove the motherboard from the chassis.

Here is the output of lspci with an NVMe SSD installed:

00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Root Complex
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Renoir IOMMU
00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge
00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge
00:02.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge
00:02.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge
00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus
00:08.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 51)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 0
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 1
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 2
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 3
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 4
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 5
00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 6
00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 7
01:00.0 USB controller: ASMedia Technology Inc. ASM1042A USB 3.0 Host Controller
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0e)
02:00.1 Serial controller: Realtek Semiconductor Co., Ltd. Device 816a (rev 0e)
02:00.2 Serial controller: Realtek Semiconductor Co., Ltd. Device 816b (rev 0e)
02:00.3 IPMI Interface: Realtek Semiconductor Co., Ltd. Device 816c (rev 0e)
02:00.4 USB controller: Realtek Semiconductor Co., Ltd. Device 816d (rev 0e)
03:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983
05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Renoir (rev c2)
05:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device 1637
05:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) Platform Security Processor
05:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Renoir USB 3.1
05:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Renoir USB 3.1
05:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD] Raven/Raven2/FireFlight/Renoir Audio Processor (rev 01)
05:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) HD Audio Controller
05:00.7 Signal processing controller: Advanced Micro Devices, Inc. [AMD] Raven/Raven2/Renoir Sensor Fusion Hub
06:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 81)
06:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 81)

Here is the output of lsusb:

Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 003: ID 8087:0029 Intel Corp. 
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Unfortunately the micro SDXC card reader is only connected via USB 2.0, and the maximum read speed I was able to obtain using a UHS-1 class card was 41MB/s.

This is disappointing as UHS SD cards are frequently capable of read speeds in excess of 100MB/s and Asus appears to have cost-optimized the SDXC card reader here by going with an older USB2.0 design.

I will give a brief overview of the BIOS, but suffice to say it’s pretty basic with no advanced functionality. But first, the pretty Asus splash screen:

Much incredible, so Renoir

The Main summary is quite basic, and seems to have a bug where the M.2 SSD is shown as Not Present even when installed. The bug is present in both 0409 and 0416 releases.

Summary screen of Asus PN50 0416 BIOS

Despite the Main page stating Not Present, an installed NVMe device is visible under Advanced > NVMe Configuration

The Monitor view offers a summary of system temperatures, CPU Vcore, and fan speed. You can select the fan profile as well.

NVMe temperature is present here ¯\_(ツ)_/¯

The included EzFlash utility makes updating firmware easy, simply extract the ZIP archive containing the firmware update and put the CAP file on a FAT formatted USB device.

EzFlash: Select the update file from your USB device
Updating the firmware requires a few minutes but is otherwise painless

There seems to be a bug where you are prompted to save settings before entering the utility, and selecting No prevents you from entering EzFlash.

MCTP Configuration, DASH Configuration, and Serial Port Console Redirection are all options added in BIOS 0416 that were not present in BIOS 0409.

Advanced menu of BIOS 0416

Thus far, it seems there is no option to select a temporary boot device from the main splash screen, you must first enter BIOS and then navigate to the Boot menu. It would be nice if Asus added the option to select a temporary boot device to the splash screen in a future release.

BIOS boot menu

I had no issues with 64GB of Mushkin RAM running at 3200MHz on BIOS 0409 or BIOS 0416. The PN50 ran 4 passes of Memtest86 (BIOS 0409) without any errors.

Sadly Asus offers no option to set the cTDP at 15W or 25W. From what I’ve read, the cTDP should be set to 15W in the PN50, though I am not sure how to verify this is actually the case. It would be nice if Asus offered the option to set the cTDP at 15W or 25W, though perhaps their thermal design would not accommodate that.

I have only had my PN50 for about a week, but initial impressions are quite good. It is not overly loud and performance is quite frankly amazing for the 15W TDP.

I am really excited to use the PN50 to accelerate the time consuming tasks I have now, such as buildroot make clean && make. For someone who has been using a Xeon E3-1220v3 and Xeon E5-2620v2 for compiling, the Ryzen 7 4700U is stupidly fast and sips power. It even embarrasses the Intel i9-8950HK in the XPS 15, which is a top-spec laptop from just 2 years ago.

I am excited and cannot wait to see what Cezanne brings in 2021. Hopefully Asus see fit to update their mini PC offering for future AMD platforms.

Modifying the Cisco Meraki MS220-8P firmware

8 Replies

Following the analysis done by Leo Leung of the Cisco Meraki MS220-8P boot process, I wanted to share more information I’ve uncovered about the firmware source code, layout, and modification.

Cisco were not very forthcoming with the source code, and initially tried to claim that because the product was past the End of Sale, they were under no obligation to provide the source code. I am not a lawyer, but my understanding is that this claim is in violation of GPLv2 Section 3b, which states the the vendor must make the source code available for at least 3 years after the last distribution:

Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange

https://opensource.org/licenses/gpl-2.0.php

I am extremely disappointed to see that Cisco is still not forthcoming with GPL source code. They have little to gain by being so difficult, and it is very disappointing to see them claiming they aren’t under obligation to provide the source code due to the product being discontinued.

To save anyone else the trouble of dragging the source code for Meraki Vitesse based switches (MS22, MS42, MS220, MS320) out of Cisco, I have mirrored the source code into 2 repositories on GitHub:

  • Stage 1 (NOR bootloader, kernel 3.18.122, includes RedBoot LinuxLoader)
  • Stage 2 (NAND firmware, kernel 3.18.123)

Please note: the kernel modules used to control the switch ASIC (vtss_core, merakiclick) are not included in the above source code. If you ever plan to build your own kernel and want to use the switch, you will need to extract the kernel modules corresponding to the above kernel versions from your switch.

My initial attempts to modify the firmware followed Leo’s instructions to disassemble the mtd region boot1. I was perplexed by the contents of the boot1-patched-post data that Leo’s script extracted from the image. The data in this region has an extremely high entropy:

The data is quite large too, approximately 200KB or 5% of the boot1 region. That’s a lot of space to give up on an embedded system for no apparent reason!

I decided to zero out the contents of this boot1-patched-post section and see what effect it would have on the boot process of the switch. The result was a kernel panic, cannot open initrd:

[    2.537000] devtmpfs: error mounting -2
[    2.541000] Warning: unable to open an initial console.
[    2.548000] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -2
[    2.556000] Please append a correct "root=" boot option; here are the available partitions:
[    2.564000] 1f00          131072 mtdblock0  (driver?)
...
[    2.674000] 1f15            2670 mtdblock21  (driver?)
[    2.679000] mkp_lg: VFS: Unable to mount root fs on unknown-block(0,0)
[    2.679000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

So the kernel can no longer find the initramfs, even though the XZ archive is still present in the region. This got me thinking that the region must contain information the kernel uses to extract the XZ compressed initrd.

The build instructions I received from Meraki with the source code stated:

To build OpenWRT firmware:

cd meraki-firmware/openwrt
cp config-elemental-3.18 .config
make oldconfig
make -j1 BOARD=elemental-3.18 OPENWRT_EXTRA_BOARD_SUFFIX=_3.18


To build Linux-3.18 kernel:

cd meraki-firmware/linux-3.18
cp ../openwrt/target/linux/elemental-3.18/config .config
make CROSS_COMPILE=../openwrt/staging_dir_mipsel_nofpu_3.18/bin/mipsel-linux-musl- ARCH=mips oldconfig

make CROSS_COMPILE=../openwrt/staging_dir_mipsel_nofpu_3.18/bin/mipsel-linux-musl- ARCH=mips prepare

touch rootlist
make CROSS_COMPILE=../openwrt/staging_dir_mipsel_nofpu_3.18/bin/mipsel-linux-musl- ARCH=mips vmlinux

After following these instructions and ending up with a vmlinux that was far too big to fit into the flash region, I figured out how to build the kernel such that it fits into the boot region. This also clarified what the contents of boot1-patched-post from Leo’s extraction script contains.

To start, if you are building the 3.18.122 kernel for the SPI flash (first stage boot, before kexec) you absolutely need a rootlist file. For the stock Meraki firmware, I have re-created the contents of the rootlist file:

file /bootsh ramdisk/bootsh 755 0 0
slink /init bootsh 777 0 0
file /kexec ramdisk/kexec 755 0 0
file /MERAKI_BUILD ramdisk/MERAKI_BUILD 755 0 0
dir /bootroot 755 0 0
dir /dev 755 0 0
slink /lib bootroot/lib 777 0 0
slink /etc/ bootroot/etc 777 0 0
slink /usr bootroot/usr 777 0 0
slink /sbin bootroot/sbin 777 0 0
slink /bin bootroot/bin 777 0 0

The Meraki provided instructions produce an ELF vmlinux, which is not what at all what the switch is booting. You must use objcopy to strip vmlinux before you can get it to what the switch expects in the firmware:

mipsel-linux-musl-objcopy -O binary -S vmlinux vmlinux.bin

By following the above steps, building the kernel with the above rootlist file contents and stripping vmlinux with objcopy, vmlinux.bin is the data that goes into the boot1 region immediately after the 32 byte header. Pad the header + vmlinux.bin with zeros to ensure it is 3932160 bytes total.

Aside: You’re probably not interested in including the same files in your ramdisk as the stock Meraki firmware. Unless you have modified the NAND image to spawn a console and kill their management daemons, you’ll have the same end result as the stock firmware. However, it is a useful test to ensure that you can build and boot the kernel yourself:

Linux version 3.18.122-meraki-elemental (hmartin@alp) (gcc version 5.4.0 (GCC) ) #4 Sun Mar 1 14:44:24 UTC 2020

The meraki_stock branch of the 3.18.122 repository includes the defconfig and rootlist file you need to build the 3.18.122 kernel.

Now onto more useful matters, modifying the bootloader. I grew tired of having CRC errors when testing my changes, so I patched the CRC check out of the bootloader. Later on, I decided I wanted to try booting 3.18.123 directly from NOR, except the stripped vmlinux is nearly 5MB, too large. So I patched out the boundary check in the bootloader. You can find both versions of the bootloader (without CRC and without CRC/boundary check) in the 3.18.122 repository on GitHub.

Meraki appears to supply a common firmware for all their Vitesse based switches. The MS220-8P is based on the luton26 ASIC, while the larger switches (MS22, MS42, MS220-24/48, and MS320-24/48) appear to be based on the Jaguar-1 ASIC. Since you don’t need the kernel modules for other models in the firmware, you can delete them (and other unnecessary Meraki daemons) and fit the entire firmware in roughly 8MB using XZ compressed squashfs.

With this combination, you can boot Linux 3.18.123 from NOR, with a squashfs on NOR:

[    0.000000] Kernel command line:  console=ttyS0,115200 mtdparts=m25p80:0x40000(loader1),0x4c0000(boot1),0x800000(bootubi),0x300000(jffs2) root=/dev/mtdblock3 rootfstype=squashfs ubi.mtd=gen_nand.0 mem=0x7FF0000 ramoops.mem_address=0x7FF0000 ramoops.mem_size=0x10000 ramoops.block_size=0x10000

Since the kernel version matches the modules shipped by Meraki in their firmware, you can load the modules required to manage the ASIC:

# lsmod
vc_click 251569 0 - Live 0xc35eb000 (PO)                                                                                                                                                   
elts_meraki 4132849 1 vc_click, Live 0xc30ab000 (PO)                                                                                                                                       
merakiclick 1587774 2 vc_click,elts_meraki, Live 0xc2854000 (O)                                                                                                                            
proclikefs 5189 2 merakiclick, Live 0xc007b000 (O)                                                                                                                                         
vtss_core 663855 1 vc_click, Live 0xc13f0000 (PO)

This approach is not without its own problems. The Meraki firmware expects / to be mounted rw, something that isn’t possible with squashfs.

In summary, with the following components you can boot directly from NOR, without touching NAND at all:

Please understand that I have not solved all the issues with this approach, and above resources are intended as a guide to encourage future development. To illustrate, here is a flashable image (see here) for your MS220-8P that illustrates booting entirely from NOR. Although I would like to caution you that this is a proof of concept, not a functional firmware. If you have any improvements please submit your pull request the meraki-builder repository!

The above information is the product of months of reverse engineering, development, and testing on an MS220-8P. It is my hope that by providing the GPL archive, my modifications, build scripts, and documentation that others will find a more elegant way to run the firmware entirely from NOR, which would significantly decrease the complexity to running a custom firmware on the MS220-8P.

That’s all for now. I will continue working on this project in the background and may have more updates in the future.

Powering a Supermicro Micro Cloud node

Leave a reply

You can often find good deals online for blade servers, but the critical question is always: can you power it without an expensive and loud chassis?

Usually blade servers have very little IO onboard, relying on the chassis backplane to provide power and communication. In the case of Supermicro, the Micro Cloud series (such as the Supermicro X10SLE-F) are designed to be used in a chassis providing cooling and power, but they have all other IO onboard. Each node has IPMI, Gigabit Ethernet, VGA/RS-232/USB 2 (SUVI cable), USB 3 (onboard), and SATA connections for up to 5 hard drives.

I previously wrote about resetting the IPMI password on the X10SLE-F, which allows you to reset the IPMI to factory defaults (as most eBay sellers don’t know the credentials and/or don’t reset IPMI before shipping). With functional IPMI, you can install an OS without needing the proprietary KVM/SUVI cable from SuperMicro.

There are a few unique aspects to the X10SLE-F I want to discuss, having had one for several months:

  1. It is quite easy to power
  2. Remarkably low power

The power connector on the motherboard is the same physical connector as the standard ATX 12V EPS (8-pin CPU) connector. Pin 5 must be replaced with 5V stand-by. The easiest method is to buy an EPS extension cable and modify the extension cable, with that you can use a normal ATX power supply with EPS output to power the board.

In addition to 5VSB and 12V, there are two pin headers on the motherboard which must be wired to signal that the blade is connected to the backplane. You will need two “dupont” wires of 2.54mm pitch (Arduino/Raspberry PI GPIO style) to wire the following pins between JP17 & JP18:

  • Purple: JP18 pin 1 (5V) -> JP17 pin 2 (GND)
  • Green: JP18 pin 6 (3.3V) -> JP17 pin 5

Additionally, your board must be running a BMC version older than 3.38 as SuperMicro changed the backplane detection method in newer BMC releases. Updating to BMC 3.38 or newer will result in the board not powering up. BMC firmware versions above 3.00 include an HTML5 iKVM viewer instead of the traditional Java-based iKVM applet. Here is an archive of SuperMicro BMC firmware releases.

In total, with no modification to the motherboard, 2 breadboard cables and an EPS extension cable, you can use the X10SLE-F by itself without the chassis:

Power consumption is very low. I measured 13W idle on a system with the following specs:

  • Intel Xeon E3-1220v3
  • 2x4GB PC3-10600E
  • SATA SSD (OpenWrt x86)

At 13W consumption, the BMC booted and 2 Ethernet connections are active (BMC and one Gigabit Ethernet).

The BMC alone seems to draw ~6W when booted with the dedicated BMC Ethernet connected. With a high efficiency power supply like the Dell DA-2, the idle consumption of the server will be well under 20W. I have never seen an x86 server idle below 20W, with the Dell R210 II only going as low as 23W with all settings to minimum (CPU speed, memory clock, no iDRAC Ethernet).

Using a CPU such as the Intel E3-1220L V3, you could easily power this board with a 12V power source that can supply 40W. For higher TDP CPUs like the E3-1225 V3, I would recommend a 12V power supply of at least 100W.

The X10SLE-F supports Xeon processors and ECC memory, making it a great low-power NAS for up to 5 hard drives. With up to 32GB of DDR3 ECC and a quad-core processor, you can run ZFS or have a low-power hypervisor.

There’s a thread on ServeTheHome about this motherboard if you have any further questions.