Hacker News Reader

Comment by karma_pharmer | Hacker News Reader

Marvell/Armada CN9130 SoC ... public-but-non-upstream code for uboot

Dude, not even close. That repo is for an opaque blob:

https://github.com/SolidRun/cn913x_build/blob/master/binarie...

... which is mashed together-bits of other blobs, including the notorious will-never-be-open-source highly-radioactive "snps blob":

https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/...

and its vile EULA which you have agreed to:

https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/...

That shit contains an ARC core. Never heard of ARC? That's okay, most people haven't. It's an obscure niche architecture used for almost nothing except for ... drum roll ... the Intel Management Engine (up until 2019). Gee I wonder why that's in there.

Don't touch Marvell shit with a ten foot pole, it's blobs all the way down. They're just good at hiding it.

View on HN

Thanks for the analysis.

> That repo is for an opaque blob

Marvell patches have been going to upstream u-boot for a subset of CN-9130 functionality. Some were rejected as unwanted SoC-unique features, but that code is still public and could be consolidated into a public git repo for evaluation. Support for core features was merged, e.g. this thread from 2020 to 2023, https://lore.kernel.org/u-boot/ddd355c2-344e-4fbd-ace9-29d10...

> the notorious will-never-be-open-source highly-radioactive "snps blob" .. ARC core

Thanks for highlighting snps+eula. While we all want blob-free hardware like the expensive Talos OpenPOWER, all modern CPUs from Intel (ME) and AMD (PSP, MS Pluton) have management cores and firmware blobs (Intel FSP, AMD Agesa). AMD has a public roadmap for open firmware with OpenSIL, but PSP code is not public. One mitigation is to keep the device offline.

> Marvell.. good at hiding it

While this obfuscation is undesirable, many Arm vendors don't even bother with a fig leaf of upstream support. Would you recommend any Arm SoCs that have ongoing upstream Linux and u-boot coverage/fixes? Ideally, the SoC would also have OSS code for TrustZone (TF-A) and support for ECC memory. RockChip RK-3588 looks promising, https://www.collabora.com/news-and-blog/blog/2024/02/21/almo...

While we all want blob-free hardware like the Talos Power9

... which is 100% blobless. Or the Cavium MIPS64 chips (100% blobless). Or if you want Arm64, the Rockchip RK3399 (100% blobless). You have plenty of choices.

One mitigation is to keep the device offline.

Here's an even better mitigation: don't buy junk like this chip.

Stop blobwashing junk hardware like this with deceptive misrepresentations.

> Cavium MIPS64

Does that include the Cavium Plus CN5020 in Ubquiti EdgeRouter Lite?

https://openwrt.org/toh/hwdata/ubiquiti/ubiquiti_edgerouter_...

https://www.insidegadgets.com/wp-content/uploads/2015/06/CN5...

I looked into running OpenBSD on ER3-Lite and was told that network routing performance was poor without a binary blob that ships in Ubiquiti router firmware. Cavium is owned by Marvell.

> if you want Arm64, the Rockchip RK3399 (100% blobless). You have plenty of choices.

The challenge is finding existing products that people can buy at retail. We're having this conversation in an HN thread about ECC. The only off-the-shelf Arm NAS (4xSATA, 2xM.2) that I've found with ECC + Debian is the QNAP above.

I will look for an RK3399 SBC that supports ECC memory, 4xSATA and at least one NVME slot, which could be installed into a 1U NAS chassis.

> Stop blobwashing junk hardware like this with deceptive misrepresentations.

ECC is a high priority requirement for an Arm NAS. Would be delighted to find a blobless Arm SBC with ECC support and enough I/O channels for use in a NAS. Otherise, ECC trumps blobs for an offline NAS use case in a 1U chassis, which can be physically secured in a rack against physical tampering.

Reply on news.ycombinator.com