SolidRun ClearFog: A 16-Core ARM ITX Workstation Board Aiming For $500~750 USD

[linux4kix]

I know solidrun is a networking company, but I'm still confused why a board billed as a workstation has so dang many network ports

We are considering this a ready to deploy workstation. The idea is that the same hardware can be developed on as a workstation and the same for factor can be deployed to production. Plus the ports can be used for a plethora of options not just for development, but also for devops, and network administrators. Being able to test 100Gbe equipment from your workstation, or using various interconnect modules that would need an SFP or QSFP port. Additionally these are raw SERDES lanes brought out which allows for interesting test configurations like designating them as PCIe lanes and using an external PCIe cage. This is designed to be as flexible a solution as possible and allow pushing the boundaries of what can be developed for and tested regarding compute on the edge, clustering, data storage, and machine learning.

[linux4kix]

Just a little teaser for those paying attention. We have found that overclocking is an option (although of course not recommended nor supported under warranty) We are currently running benchmarks on board clocked up to 2.4Ghz and the DDR4 running at 3200Mtps. It has been stable over night. The numbers are looking quite nice

[Sonadow]

If you do pull it off, don't forget that software will be the next obstacle to cross.

From what i have read, most applications cannot compile for ARM without significant downstream patches. As a non-developer who compiles my own programs from upstream sources, this is a no-go.

ARM still needs that critical mass to get application developers ensuring that their code builds as-is on both x64 and ARM. And maybe even POWER.

[linux4kix]

If you do pull it off, don't forget that software will be the next obstacle to cross.

From what i have read, most applications cannot compile for ARM without significant downstream patches. As a non-developer who compiles my own programs from upstream sources, this is a no-go.

ARM still needs that critical mass to get application developers ensuring that their code builds as-is on both x64 and ARM. And maybe even POWER.

Actually most major distributions fully support ARM64. There are projects which do not fully support ARM yet, and definitely lots of work to happen on optimizing programs better for ARM vs x86, however ARM software support is quite thorough at this point. This is part of the conversation that is currently happening in the community. ARM will never be a top tier supported platform until there are capable platforms that developers can use as their full time desktop / workstation without compromises. We feel that we finally have access to hardware that will make this a reality, and we are making sure to get developers boards at the best price possible.

[tuxd3v]

You can see the cache layout in the device-tree for the SOC. https://source.codeaurora.org/extern...a27f146439c528

Thanks for the link
Does exist already concrete dates, for this board?
I am interested in red more about it, and possibly buy it

[linux4kix]

Thanks for the link
Does exist already concrete dates, for this board?
I am interested in red more about it, and possibly buy it

Here is a quick status update. The dates are not concrete yet as we actually want to get the board out sooner if possible. Originally we were planning on a September release and now we are hoping to hit August or earlier. Pre-orders will start soon, but we are holding off on them until we finalize the software feature set with NXP. We are working closely with NXP and ARM to verify that everything can be put in place to pass the SBSA compliance tests. The delay in pre-orders is because we don't want to sell something to customers that doesn't reach our intended goal.

The first mini-itx carriers are fabricated and I will start posting more information regarding the bring up and compatibility. Once that is done we have about a dozen boards that will be sent out to industry leaders to bang on and recommend suggestions before the final board run is done. Our intentions is to make this the serious ARM on ARM development board that the community needs.

Thanks for your interest and we will keep you posted.

[Zoop]

Here is a quick status update. The dates are not concrete yet as we actually want to get the board out sooner if possible. Originally we were planning on a September release and now we are hoping to hit August or earlier. Pre-orders will start soon, but we are holding off on them until we finalize the software feature set with NXP. We are working closely with NXP and ARM to verify that everything can be put in place to pass the SBSA compliance tests. The delay in pre-orders is because we don't want to sell something to customers that doesn't reach our intended goal.

The first mini-itx carriers are fabricated and I will start posting more information regarding the bring up and compatibility. Once that is done we have about a dozen boards that will be sent out to industry leaders to bang on and recommend suggestions before the final board run is done. Our intentions is to make this the serious ARM on ARM development board that the community needs.

Thanks for your interest and we will keep you posted.

Thanks for keeping us in the loop!

I cannot speak for any other potential customer, but I fully support your approach of taking your time and getting it done correctly right from the start. As you repeatedly mentioned, we do not really need yet another throw-away ARM SBC - there are already too many of those out there. I would be more than happy to wait 3 more months if that is what it takes to build a solid, standard-compliant board.

jonmasters on Twitter has been making a lot of noise about standardization of ARM systems. If you are serious about SBSA compliance (I have no doubt that you are), he is on your side. Please consider collaborating with him if you are not doing so already. His approval will likely sway lots of people currently sitting on the sidelines due to dissatisfaction with poor standardization in the ARM ecosystem - exactly the people that you want to reach. If, in contrast, his verdict on the final board is unfavorable from the standard compliance perspective, many of us will probably continue to sit on the sidelines and see if the next vendor would do any better.

[linux4kix]

Thanks for keeping us in the loop!

I cannot speak for any other potential customer, but I fully support your approach of taking your time and getting it done correctly right from the start. As you repeatedly mentioned, we do not really need yet another throw-away ARM SBC - there are already too many of those out there. I would be more than happy to wait 3 more months if that is what it takes to build a solid, standard-compliant board.

jonmasters on Twitter has been making a lot of noise about standardization of ARM systems. If you are serious about SBSA compliance (I have no doubt that you are), he is on your side. Please consider collaborating with him if you are not doing so already. His approval will likely sway lots of people currently sitting on the sidelines due to dissatisfaction with poor standardization in the ARM ecosystem - exactly the people that you want to reach. If, in contrast, his verdict on the final board is unfavorable from the standard compliance perspective, many of us will probably continue to sit on the sidelines and see if the next vendor would do any better.

Yep,

I have been going back and forth with Jon Masters on twitter regarding this. He will be in the loop as we progress further, and will most likely get an early release board.

[yaneti]

Hello linux4kix

Would you please elaborate on what level of mainline u-boot/kernel software support should we expect from NXP for this SOC, and from you (SolidRun) for the board itself. Because I just bought a MACCHIATObin (single shot), (which is how many years old now..) only to find out the sorry state of the MVPP2 support in mainline kernel. Given how networking chops is the main appeal for these boards this is most unfortunate.

I'd really like to avoid dealing with silly vendor BSP-s with years old kernels and funky custom hacked drivers in them.

[linux4kix]

Hello linux4kix

Would you please elaborate on what level of mainline u-boot/kernel software support should we expect from NXP for this SOC, and from you (SolidRun) for the board itself. Because I just bought a MACCHIATObin (single shot), (which is how many years old now..) only to find out the sorry state of the MVPP2 support in mainline kernel. Given how networking chops is the main appeal for these boards this is most unfortunate.

I'd really like to avoid dealing with silly vendor BSP-s with years old kernels and funky custom hacked drivers in them.

First I will preface this with a single statement. Getting any full board support into mainline takes time. You can not just drop a full BSPs worth of SOC and driver support patches onto either u-boot or linux mailing lists and just expect it to be merged in the next release. This is just a reality of how the process works. New chipsets and boards need to be spoon fed into mainline piece by piece, reviewed and then merged. With the Macchiatobin this was outsourced by Marvell and this board was made by SoildRun but was a Marvell board and how they managed their software development was between Marvell and those companies. SolidRun has since released our Clearfog GT 8K board and you can see that we are merging patches to mainline for both u-boot and the kernel consistently.

With that being said the development process with NXP on the ClearFog ITX has been very different. We are having consistent meetings with NXP, and NXP is already starting to push patches to be merged into mainline. Will it take time? Yes. However NXP is very aware of the importance of both mainlining support as well as providing documentation to the developer community and they are committed to that. SolidRun is working directly with NXP and ARM regarding SBSA compliance for the UEFI bootloader. This is great but will still require mainline driver support for the SERDES networking interface that the SBSA certification doesn't cover. We are also working with ARM and Russell King that wrote the phylink layer to get ACPI support merged in for this. Will it take time? Of course, but we are doing everything we can to cover all the bases that have been pain points with the Armada 8040 based boards.

Will you need to deal with an LTSI based kernel with non-mainline patches for 6 months?....most likely. Is it a priority for SolidRun and NXP to mainline these patches?....Absolutely. That is the most honest answer I can give.