Pre-Prod HoneyComb LX2K 16-Core Mini ITX Arm Workstation Pre-Order for $550
cnx-software.com
cnx-software.com
> ... as long as everybody does cross-development, the platform won’t be all that stable. Or successful ... If you develop on x86, then you’re going to want to deploy on x86 ... It was literally this “develop at home” issue. Thousands of small companies ended up having random small internal workloads where it was easy to just get a random whitebox PC and run some silly small thing on it yourself. Then as the workload expanded, it became a “real server”. And then once that thing expanded, suddenly it made a whole lot of sense to let somebody else manage the hardware and hosting, and the cloud took over.
> The pre-production developer board is fitted with NXP LX2160A pre-production silicon which explains some of the limitations. [...] software features will be limited with the lack of SBSA compliance, UEFI and mainline Linux support. It will support Linux 4.14.x only.
BTW, would be nice if the production board had Coreboot support, whether or not it has UEFI by default.
Mainline support for the SOC is already making it into mainline and we can boot a mainline kernel with limited functionality. Getting anything into mainline is a process, but we hope to have everything supported by the end of the year.
For a management interface we have integrated what we call a micro-BMC. It is an STM MC, that is wired up to power up/down, thermals, and can reflash the SPI-NOR chip for recover and firmware updates out of band. This is a technology we are working on so the BMC can act more as an IoT gateway to handle many boards, vs each board needing to manage security individually. This chip is fully unlocked and open for developers to play around with.
That's very interesting. Why did they build it like that? Do you have more information on this?
I'd love to hear about other alternatives if you know any.
Now, coreboot+tianocore uefi for somewhat open firmware...
Basically an ACPI system is a lot easier to bootstrap because you don't need to support all of the little subcomponents of the board explicitly, but once you supprt devoce tree, you support the board in a much more complete and meaningful way, and it's truly your kernel running the show.
As a word of note, though, the chips in the Tegra machines are, IME, extremely powerful -- but you're stuck with Linux 4 Tegra and Nvidia's Ubuntu-based distro. At least for the TX1 there was some success getting other distros working (without GPU) but I remember several people running into trouble with the TX2. That may or may not be a dealbreaker for some people (it's a sort of franken-Ubuntu and your only hope for problems are the Nvidia forums)
The Solid Run LX2K machine however should (eventually) run any standard AArch64 distro. They also have 16 cores and expandable SATA, as well as an open PCIe 4x slot on these boards, so you can install whatever GPU you like onto it. Not to mention you can plug in a bunch of RAM. You can even buy a slightly different variant of this board with a 100GigE cage on it, still under $1000 USD, which puts it in a very unique position vs any other I've seen.
I think the LX2K boards are (now, at this point in time!) a much better sell if you want an actual "arm workstation" as a developer. But the Xavier will be vastly superior if you want a lower power profile (mobile) or if you're doing something like DL inference.
As for Xavier it is a good platform, but you in many benchmarks the HoneyComb LX2K is way out in front. Then adding in the 10Gbps networking and storage.
Also, Franken-Ubuntu I suppose isn't really my complaint, though I still don't like it. It goes beyond that, though -- the Tegra boards have very custom design that means some things are a huge pain in the ass if you want to even remotely treat them like "normal" computers (for example, want to test that fancy driver you wrote on your AArch64 Tegra machine for that M.2 peripherial? well first you gotta reconfigure the BSP firmware to turn off the power rails to various subcomponents so you can reroute them to things like the M.2 E key slots in the TX2. Gotta disable that USB controller via BSP flash if you want a chip in there, etc etc). It also means I am basically stuck on older kernel versions which may mean features I want to use or develop with are basically off limits (eBPF enhancements, io_uring, etc.) I don't just want to test SIMD; I also need to test actual memory/disk/peripherials, etc. These constraints make perfect sense for Tegra devices -- they are still annoying, for me.
I'm not saying the Tegra machines are not nice, or they are not high quality. They absolutely are. If you are just writing code to give the CPUs some work to do, they are great! Flash the default BSP, plug in HDMI, run 'gcc'. They're the highest performing ARM machines for their power profile and size, IME. But the moment you treat them like an "ordinary" computer, all bets are off. These LX2K machines act substantially more like "ordinary" desktop computers, and IMO that's a significant benefit.
Now, if you want to do DL inference or GPU programming, I think CUDA is vastly better (for a number of technical reasons). And the Tegra machines would be a good choice! But if you're just writing ARM code and need a desktop, these machines seem perfectly sufficient and can host open source drivers just fine, and will be far more usable in a number of ways vs a Tegra machine.
(And also: Nvidia also released some press notes last month that they would be bringing the full CUDA stack to ARM for data-center computing, presumably, including the host driver. So it's possible you may be able to stick a Quadro into these things soon enough and use CUDA to your hearts content!)
That I do agree with. I wanted to buy an ARM machine to do CI for one of my clients, and currently the only real option for that seems to be Cavium ThunderX. And pricing is way out there in the stratosphere for what you get. Instead I could see them deploying a few of these for a fraction of the cost.
Also 99.999% of people want to "use" software, very often proprietary one, not re-invent the wheel. No matter what, this kind of product will be a niche, by an overwhelmingly large margin.
Desktop isn’t even the hot new thing anymore, mobile is (or, at least, was.) Ans as fate would have it, mobile platforms are dominated by ARM already. Many modern developers already deal with ARM as it is.
Going further down the rabbit hole, I’d argue that most applications aren’t even nearly CPU bound and would run just fine with emulation, and nobody will bat an eye. This isn’t really theoretical, considering there exists x86 emulation in ARM Windows 10.
And finally, most open source software already runs on many architectures, just look at how many architectures Debian supports.
It does increase load on developers, but not to a degree that would make the benefits to competition unworthy. I think a good amount of developers are capable enough to figure out how to cross compile.
Architectural splits are not new. Apple did it twice already with Mac, and while there’s no evidence of a third one on the horizon yet, it’s certainly not beyond them.
And hell, maybe in the future, developers largely won’t ship architecture-dependent binaries. It is yet to be seen what might happen with WebAssembly and similar technology.
How do you address the problem caused by the combinatorial explosion of adding a whole new ISA to the OS*distribution combination of platforms that need to be targetted, tested for, and debugged?
This is a pretty theoretical problem and wreaks of slippery slope fallacy. How many CPU architectures have even come close to desktop usability in the past 10 years? Even prospect wise I basically only see ARM and RISC-V on the horizon. A combinatoric explosion is unlikely, very unlikely.
I already kind of went over this, but I’ll reiterate:
WebAssembly is a good example of a technology that has the potential to kill two birds with one stone and unify both architectures and OSes. Web browsers are Not the only environment WebAssembly runs in.
Folks writing software in .NET, Python, Java, JS already don’t have to worry about this. They already aren’t dealing with architectures, mostly.
A lot can be done with emulation when performance is not a primary concern. Windows 10 already has x86 emulation for ARM. On Linux Qemu user mode is pretty mature (and is already used for things like setting up ARM chroots on x86 boxes.)
If you are working in a higher level language it's a total non-issue. You will not notice.
My workstation requires 4 4k output, both HDMI 2,0 and display-port, and decent OpenGL & other hardware accelelation support. There is no way I'm ever going to get this working out of the box with a fancy architecture. Yes, I'm using proprietary binary-only software, but I my line of work involve CAD+CAM, not re-invent the wheel.
Even industrial system I'm working on right now will use standard off-the shelf part (read x86 or rasppi-like sbc) and STANDARD interfaces, because I don't want to lock myself with a vendor. If the main system crash, I can replace it within 12h with a crappy old system and limit downtime.
> Brandishing "diversity" as the epitome of progress is close to nonsensical.
Man, it really sounds like you have some things you might want to talk about with a therapist. I haven’t even used the word “diversity” that I can find.
All I’m suggesting is maybe an instruction set design that has cruft going back decades might actually not be the global maximum of ISA design, and that there might be real gains by trying to apply modern high-performance processor engineering to a different application ISA.
That’s it. The market gets to decide if another ISA will hit critical mass. This is not especially likely for the most part, but I definitely support the research.
I’m sorry for all of the snark but really, I am blown away at some of the responses this has garnered. I hope you all realize that this machines existence is not a threat to basically anyone.
>Do we need 16-core PIC16 Mini ATX workstation too?
Now this is just garbage. I doubt you are really ignorant enough to believe modern ARM cores are effectively in the same class as PIC16.
But honestly, unless you have a vested interest in the failure of non-Intel-based architectures, then what do you care? Why the intellectual hostility? Why are we asking “why” instead of “why not?”
I like ARM. I would buy this machine.
If it were usable for my workloads (running *nix, basically), I would absolutely love that. ...I admit, I'm struggling to think how to scale PIC up that much, and IIRC doesn't it use Harvard architecture? That'd be a struggle. But anyways, yes, if we could make it work then that would be beautiful.
Indeed it does. PIC32, on the other hand, doesn't.