16-Core HoneyComb LX2K ARM Workstation Looks To Offer A Decent Performance Oomph

[linux4kix]

How goes SBSA/SBBR stuff? Virtualization? m.2 bandwidth/speed?

We are still working with ARM and NXP on SBSA certification. Virtualization is functional and we are in contact with VMWare regarding ESXi support. m.2 bandwidth is x4 PCIe3 so will do the expected 3GBps

[linux4kix]

Also would be nice to see it compared to other AArch64 systems. APM Mustang, 96borads DeveloperBox, ThunderX(2).

Well those machines are not really easy to just get access to. I have run some earlier comparison benchmarks against some benchmark runs that were already posted to openbenchmarking.org. This was the earlier board that was clocked at 1.9GHz but they are still interesting. Just search for LX2160A on openbenchmarking.org and you can look at them.

Overall I find it a bit pointless to compare to these boards. They are generally 3-10 times the price of our board and are all rated at a TDP that is 3-6 times more than our board. They are also not widely deployed. Most developers use x86_64 as their main workstation, and you generally get the argument that ARM is good for low power and can never be used for "real" work on the desktop. Of course with single core boost modern x86_64 chips have a benefit for single-threaded workloads, but I wanted to draw a comparison showing that for multi-threaded workloads the performance is quite comparable.

[haerwu]

And still - there are developers using APM Mustang or 96borads Devbox machines as their development machines. It does not matter what TDP machine has if it works.

My 8 years old desktop runs i7-2600K. Under desk I have Mustang idling and some kind of comparison would make 'to buy or not' decision easier.


openbencharking.org is UX nightmare.

[sykobee]

I could see a nice developer cluster-in-a-box setup using 3 or 5 of these boards in a single case (tbh even 5 mini-itx cases is fine) with a single(+redundant) PSU. Ideal for when you need to test clustered multithreaded applications for not a lot of money (compared to getting the business to allocate you the equivalent hardware in the datacenter, especially if you need bare-metal drive access).

[linux4kix]

And still - there are developers using APM Mustang or 96borads Devbox machines as their development machines. It does not matter what TDP machine has if it works.

My 8 years old desktop runs i7-2600K. Under desk I have Mustang idling and some kind of comparison would make 'to buy or not' decision easier.


openbencharking.org is UX nightmare.

I guess this is the most relevant. This is against a posted benchmark of the Ampere eMAG which is based on the X-Gene. https://openbenchmarking.org/result/...JONA-181009031

I would like to point out, that this is 16-cores vs 32 and 96 cores, and at least the eMAG is clocked at 3GHz vs the 1.9GHz than the developer hardware of our board, the then internal name of ClearFog ITX.

[madscientist159]

Also, this might be the most affordable new workstation in years that does not have Intel's proprietary management engine black box or AMD's PSP. The Talon Blackbird is going to start at abouti a thousand dollars more once you buy a Power9 chip. This device is intriguing from a freedom/price perspective.

Let's check that freedom claim out, shall we?

Hmmm, zero firmware sources. U-boot "coming soon". Even if U-boot materializes, it's an LSI device. You get highly privileged (non-isolated) binary-only MC firmware as a requirement to use network (and possibly PCIe), binary-only memory controller firmware, a mysterious secure boot feature (presumably fuse-based with a built-in, possibly updateable firmware), and zero documentation. I can't even find a proper block diagram with both internal blocks and internal interconnects on LSI's site yet; maybe it's NDA-restricted?

As this device stands *today*, a corebooted Intel device with ME and FSP is actually more open. If U-boot source is released it's probably on par with the Intel device, and the Intel system is cheaper with more performance.

[linux4kix]

Let's check that freedom claim out, shall we?

Hmmm, zero firmware sources. U-boot "coming soon". Even if U-boot materializes, it's an LSI device. You get highly privileged (non-isolated) binary-only MC firmware as a requirement to use network (and possibly PCIe), binary-only memory controller firmware, a mysterious secure boot feature (presumably fuse-based with a built-in, possibly updateable firmware), and zero documentation. I can't even find a proper block diagram with both internal blocks and internal interconnects on LSI's site yet; maybe it's NDA-restricted?

As this device stands *today*, a corebooted Intel device with ME and FSP is actually more open. If U-boot source is released it's probably on par with the Intel device, and the Intel system is cheaper with more performance.

Not sure where you get these impressions from. Here is the link to our current bring up scripts that pull in all freely accessible sources both for u-boot and edk2, everything has been available in the codeaurora repositories for quite a while. https://github.com/SolidRun/lx2160a_build

There is already work from NXP pushing patches to both mainline u-boot, code review requests for tianocore, and patches in mainline. The board was booting mainline as of the 5.2 release and more work has gone in since then. Note that initial u-boot mainline board support was submitted back in Nov of 2018. http://u-boot.10912.n7.nabble.com/PA...1.html#a348335

As for the MC networking layer. Please find me a 10-100Gbps networking interface that does not run with a proprietary firmware.

The documentation is coming, just like NXP has done for all their other SOCs. Remember this an early pre mass-production run of the SOC specifically because NXP wants to get this board in the hands of developers. I don't think you can demand a company to produce final documentation for a product that is not in production yet.

[madscientist159]

Not sure where you get these impressions from. Here is the link to our current bring up scripts that pull in all freely accessible sources both for u-boot and edk2, everything has been available in the codeaurora repositories for quite a while. https://github.com/SolidRun/lx2160a_build

There is already work from NXP pushing patches to both mainline u-boot, code review requests for tianocore, and patches in mainline. The board was booting mainline as of the 5.2 release and more work has gone in since then. Note that initial u-boot mainline board support was submitted back in Nov of 2018. http://u-boot.10912.n7.nabble.com/PA...1.html#a348335

As for the MC networking layer. Please find me a 10-100Gbps networking interface that does not run with a proprietary firmware.

I was looking at the vendor GitHub repositories (full of binary only firmware images) and their official product page. Google did not reveal the source code you mentioned above for whatever reason; my apologies for that.

However, the issues with the MC firmware blob and DDR blobs stand. The internal chip architecture of its predecessor (the 2085a) did not even attempt to separate the blobbed network blocks from the CPU domain, meaning the firmware on the network side could take nearly any malicious action it wanted on the CPU side. This in turn makes the network side of the device useless if the CPU has to handle any type of secure data. Since there is no documentation, I have to assume this architecture has not changed between device generations.

I have also seen other devices where the PCIe side requires firmware too; has anyone tried booting this device with minimal binary blobs (i.e. keeping the presumably required DDR and security processor blobs) to see what works and what doesn't?

[starshipeleven]

Yes. I am currently testing 32GBs of Crucial 2666 MHz ECC memory, and it is properly detected and ECC is enabled.

NOTICE: 32 GB DDR4, 64-bit, CL=19, ECC on, 256B, CS0+CS1

Good, thanks for that.

[linux4kix]

I was looking at the vendor GitHub repositories (full of binary only firmware images) and their official product page. Google did not reveal the source code you mentioned above for whatever reason; my apologies for that.

However, the issues with the MC firmware blob and DDR blobs stand. The internal chip architecture of its predecessor (the 2085a) did not even attempt to separate the blobbed network blocks from the CPU domain, meaning the firmware on the network side could take nearly any malicious action it wanted on the CPU side. This in turn makes the network side of the device useless if the CPU has to handle any type of secure data. Since there is no documentation, I have to assume this architecture has not changed between device generations.

I have also seen other devices where the PCIe side requires firmware too; has anyone tried booting this device with minimal binary blobs (i.e. keeping the presumably required DDR and security processor blobs) to see what works and what doesn't?

Of course the board will boot and run without the MC firmware. The MC firmware is only for their DPAA2 networking layer. Of course without the firmware you will be unable to take advantage of the high speed networking interfaces available on the board, crypto engine or compression engine. PCIe, SATA, and USB are all still functional.

If someone wants to do this they are more than welcome to take the Com Express Type 7 module, and build their own board that only exports the serdes lanes as PCIe.

You can read rational behind the design of the chip in NXPs published paper. https://www.nxp.com/docs/en/supporti...-Multicore.pdf