Is there something inherently complicated in adding a SATA/M.2 port to board like this?
The RaspberryPi is also "disk-less", which to me is one of the major limitations.
It's a super interesting little board, and I love that it's a RISC-V, that could really help getting the CPU in the hands of people. I just don't know enough about these things to understand why there are no storage connectors (other than an SD card slot).
On the systems I can control, I do all work "disk-less". I strongly prefer it. I like to keep programs and data segregated. The basic setup on NetBSD is as follows, with endless variations possible therefrom. The kernel(s) and userland(s), along with bootloader(s), are on external media, like an SD card or USB stick, marked read-only. There's a RAM-disk in the kernel with a multi-call binary-based userland (custom-made using BusyBox or crunchgen). After boot, a full userland from external media or the network is mounted on tmpfs-based or mfs-based overlay and then we chroot into the full userland. From there, the work space is all tmpfs (RAM).^1 I can experiment to heart's content without jeopardising the ability to reboot into a clean slate. The "user experience" is also much faster than with disk-based. Any new "data" that is to be retained for future use across reboots is periodically saved to some USB or Ethernet connected storage media. I do not use "cloud" for personal data. Sorry. This forces me to think carefully about what needs to be saved and what is just temporary. It helps prevent the accumulation of cruft. The number one benefit of this for me though is that I can recover from a crash instantly and without an internet connection. No dependencies on any corporation.
This BeagleV looks like it would work well for me as it has Ethernet and USB ports.
1. With NetBSD, I can run out of memory with no major problems. With Linux, this has not been the case. I have to be more careful.
> 1. With NetBSD, I can run out of memory with no major problems.
Could you elaborate a bit more on that, please ?
It's been a while since I last touched NetBSD, but I don't remember anything special regarding that aspect.
The OOM killer makes running out of memory on Linux not fun. I've found that turning of overcommit avoids this problem.
Then again, I've seen BSDs handle it even worse.
I disable swap. If I run out of RAM, thrashing may occur but it is not fatal. Some process that needs to write to "disk" might fail, but the system does not. I just delete some file(s) to free up the needed RAM, restart the process and continue working. I don't think NetBSD has anything like "OOM killer".
Note that one drawback with "disk-less" via read-only SD card or USB stick is how to have a good source of entropy at boot time.
This is interesting setup. Do you know a good guide for such setup?
I actually came up with this myself just playing around with NetBSD. You will probably not find anyone advocating disabling swap. I do not run X11 anymore. I stay in VGA textmode. Doubt anyone would want to do exactly what I do. NetBSD users tend toward DIY and each has their own preferences. If you study how NetBSD's install media are created that will teach you almost everything you need to know. Happy to walk you through it though if you want to try NetBSD.
PCIe, 16 GB DDR4, two M.2 (one for storage, one WIFI), quad core 1.5 GHz (same cores as this board, but twice as many)
Sensible spec. The price isn’t outlandish for what is basically a desktop with a relatively exotic CPU. 16GB ram is minimum for development in my view even though you can do a lot in 8GB.
I'm sure people would start comparing it pricewise to a i7 or something made at significant economies of scale. I think that is an unfair comparison due to the exotic CPU. Exotic in the sense that these aren't commodity CPUs.
That's a little costly, but I guess development of a board like that isn't cheap.
Existing is the first step. Prices will reduce in time -- probably quite rapidly.
The board has 16GB DDR4 memory on board, that's probably one of the most costly components.
You would have to integrate a storage controller into your design and verify that it works. It's not insurmountable, but it's engineering time that has to go toward something that a lot of people aren't ever going to use, along with an increase in BOM cost.
My pet peeve about all these small single board computers is that none of them have multiple ethernet ports, which severely limits their usefulness as networking hardware. They'd otherwise be very well suited to being various kinds of packet routing appliances.
You can sometimes hang a usb ethernet dongle off them but performance on those tend to be somewhat limited.
Check out solidrun, they have a variety of boards with multiple Ethernet ports.
I used to wonder why embedded boards didn’t have multiple Ethernet boards and why it’s not common to use ethernet to connect to peripherals instead of “old interfaces”. Until I tried it for a project. It turns out Ethernet uses roughly 0.5 to 2W per port depending on speed (that’s 1-4W per connection).
Several of the boards from Friendly ELEC have dual ethernet: https://www.friendlyarm.com
I use consumer (Netgear) switches with VLAN support to enforce network separation.
The actual routing is done as a router-on-a-stick. It’s not perfect but it’s simple, scalable, and reliable.
Perhaps what you want is a range of boards with many combinations of features. Some with 4xethernet, some with 2xethernet, some with PCIE and 1xethernet, some with M.2 and PCIE, some with M.2 and 2xethernet, etc. to fill out that big matrix of combinations. But is the market big enough for such a huge range to be economical?
Some of them have PCIE which you could connect a network card to. That seems like a more practical way to allow flexibility than having a lot of special purpose boards.
I've been unable to use Beagle boards in the past as they ship with an old kernel and uboot without the sources to update or config them (this was specifically with the black variant). It probably had something to do with vendor NDAs with chipsets or something but it made them entirely unusable to me and more expensive than competitors by almost 2x to boot.
I would love a RISC-V board to play with that is a bit more stable and about the size of a Raspberry Pi within a reasonable price range. The SiFive development boards are pretty pricey, definitely showcase hardware (look at all these peripherals or this is basically a desktop computer!).
I'm hoping with the explicit call out of open hardware and open software that this board won't have the same issues as the Beaglebone Black...
The ubuntu on bbb team keeps up to date with the latest LTS kernels. There is 5.4 support and 5.10 support is in progress.
The price wasn't so bad if you're in for the feature set (mainly the IO features). Using the embedded PRU controllers can replace the arduinos ones typically connects to their RPi.
However, BBB is very old now. A single core cortex-A8 is abysmally slow.
Getting the GPU working was always a pain. But I always used them headless so it wasn't an issue for me.
The rk3328 board I have has been great. Quad Cortex A53, up to 4 GB of RAM, Mali GPU.
Robert C. Nelson has been doing a stellar job of maintaining the omap-image-builder repo:
It's pretty easy to use to build an image for Debian Buster/Stretch or Ubuntu Bionic Beaver, he has various configurations that cover IoT, console only/headless, GUI and a few other combos. It's pretty easy to create your own config with the Kernel and packages that you want.
The images can be used for flashing to the eMMC via an SD card (or via USB).
I've found images built this way to up very up to date and absolutely rock solid thanks to Robert's curation.
Robert is the best. Looks like he'll be involved with this project too.
I've never had this problem with Beagle Boards and sources. Sure the kernel or u-boot that ship with them might be slightly older but sources have always been available.
And TI are quite decent at contributing to the upstream kernel and u-boot trees. Generally only a few months after a new TI SoC is announced there's enough support in the upstream u-boot and kernel to boot the board and do some useful things. Generally by the time silicon is buyable by mere mortals mainline is in pretty decent shape.
The biggest reason I used them in production devices (and still use them at home) was the eMMC. Which made it well worth the price, even with the slow processor.
We had to work with the Balena.io (formerly resin.io) team to get full hardware support on the BealgeBone Green Wireless (wifi drivers were the biggest hangup, iirc) a few years, but they were incredibly responsive and have done a fantastic job maintaining a stable distro for these boards.
If you want a straightforward out-of-the-box experience, I highly recommend Balena.io.
Arstechnica coverage: https://arstechnica.com/gadgets/2021/01/seeed-and-beagleboar...
> Although the first hardware run will be entirely $140 / 8GiB systems, lower-cost variants with less RAM are expected in following releases.
> The initial pilot run of BeagleV will use the Vision DSP hardware as a graphics processor, allowing a full graphical desktop environment under Fedora. Following hardware runs will include an unspecified model of Imagine GPU as well.
Sounds like a direct competitor to the Raspberry Pi. I don't know if the Imagine GPU planned for the next iteration is playing catch-up or leapfrog. The Arstechnica article links to SiFive creates global network of RISC-V startups  which I think demonstrates that SiFive is strategically leveraging or responding to the geopolitics surrounding Chinese technology.
Imagination GPU :( Notorious for being hard to support in open source. I'm not even sure there was a single free driver for those.
That likely means those devices are going to be stuck on an outdated kernel, unless Imagination steps in and provides ongoing binary support for newer kernels for their GPUs like x86 GPU manufacturers do. However, this being RISC-V with 2 existing devices total, I don't count on it.
So close, yet so far.
Imagination have said they're open-sourcing the drivers for the GPU on another RISC-V board that's supposed to be coming soon (PicoRio).
Probably those work here too.
Is it me or does it really feel obnoxious for vendors to then be claiming their hardware to be "TRULY OPEN SOURCE"?
Except for cost... which has been a problem for the BeagleBoard line of SBC's since the beginning. They actually predated the original Raspberry Pi by a couple of years but when the Pi came in at ~25% of the cost, they caught up and overtook the BeagleBoard in popularity fast. The BeagleV looks interesting from an early adopter standpoint but the hobbyist market will probably standardize around whatever decent RISC-V board comes in at sub-$50 first.
To me, they seem to serve different markets. The various BeagleBoards have more industrial specs like a wider operating temperature range, on-board EMMC, etc. Also, the pair of PRU's make them useful for things where more precise timing is important.
> Sounds like a direct competitor to the Raspberry Pi.
I would consider the Black and Green to be competitors too.
Would be really interested to get a good analysis of the Raspberry Pi, BB Black, and this new board.
Regarding the BBB/BBG, in the last 3-5 years the RPis have gotten significantly faster (RPi3 & 4) and gone 64-bit whereas the BBB & BBG haven't changed much (aside from a bit more eMMC and a very minor CPU bump) since they were launched. These days the 1GHZ 32-bit AM3358 (BBB RevC) is comparatively much slower and with only 512MB RAM, that's a lot less than a stock RPi 4.
Having said that, the BBBs are a great device! They're rock solid and have far better I/O options than the RPi: 4 UARTS, multiple I2C, SPI & CAN buses, EHRPWM, a ton of GPIO, 2x PRU processors, LCD driver, both USB and USB Gadget, oh and of course, the onboard eMMC is great compared to booting from an SD.
So I'm psyched about the Beagle-V.
>>*SiFive is strategically leveraging or responding to the geopolitics surrounding Chinese technology.*
We should all be debating HW WRT the fact that you can't name a single device (aside from weapons) that does not contain a single-non-chinese-manufactured component...
every phone or machine is almost 100% chinese built.
"designed by apple in cupertino california" (but made with slave labor from congo, china and other countries)
And we already know about all the backdoors both China and the US do...
FFS we have known about Eschelon since the 70s - the carnivor, room 641A, etc... etc....
Indeed, the geopolitics works both ways. I think the Chinese are looking at RISC-V as a safe-guard against American embargoes of the kind that killed/maimed HiSilicon, the non-Chinese nation-states are looking for full transparency of silicon design, and the manufacturers want full access to a truly global market that includes China. I'm not sure that SiFive RISC-V designs can be competitive with ARM/x64 in the short-term but the geopolitics creates a potential niche.
I think you are conflating assembly and manufacturing. TSMC is Taiwanese and Samsung is South Korean. Personally I'd prefer that all nation-states and their security organizations followed the Golden Rule and promoted free trade rather than protectionism.
> made with slave labor from congo, china and other countries
I don't equate low-wage manufacturing/assembly with exploitation and certainly not slavery but I understand that this is a common metaphor. Contemporary slavery  is a real thing and, until I see contrary evidence, I'm assuming it makes zero contribution to high-tech assembly or manufacturing.
There's something wrong with that page in Firefox. It pegs a whole CPU core and eats tons of memory.
Does anyone have informed opinion about the usability / value / relevance / quality of the Neural network support on this chip ?
Their page mentions spec with :
So this board seems to have some great support for neural net / robotics processing ?
• SiFive U74 RISC-V Dual core with 2MB L2 cache @ 1.5GHz • Vision DSP Tensilica-VP6 for computing vision • NVDLA Engine (configuration 2048 MACs@800MHz ) • Neural Network Engine (1024MACs@500MHz)
I have just noticed the recent trend of neural hardware support on mainstream chips... Apples M1, this chip.
Wondering what the implications are for software and user-space .. what kind of devices / apps will this enable ?
One area Im interested in is turning lidar scanner point data into 3D geometry on the device, thus solving a big data management issue.
I suspect an NVIDIA Jetson would be a better choice for this kind of application.
If it has driver/firmware blobs, I'll say no thanks and stick to my ARM Rockchips. If they deliver this on linux with full source code, I will definitely buy their boards.
New Rockchip boards are coming with neural processing units.
What kind of performance is expected from this compared to say the RPi 4B? Any noteworthy changes in performance characteristics (e.g better/worse I/O or something)?
Highly unlikely to be very competitive. At this stage it's about getting RISC-V hardware into developers' hands, and previous boards either cost $1000 or were limited in ways where they could not run Linux well. (I am one of the Fedora/RISC-V maintainers.)
Just saw this SiFive board HiFive is retailing for $679, can you please comment if this is any good for toying around ? Specs look more than decent - almost desktop class computing.
I have a couple on order, and I've talked to one of the developers. It looks nice - PCIe, NVRAM SSDs, mini ITX format, 16GB RAM, more cores, etc - but not in the same price point or market segment as an SBC. We will likely buy a pile of them to do Fedora builds.
Looks like you can get it from Mouser for $665 as well:
Found that link from this SiFive page:
This looks great, thanks!
The Rpi4B has a Quad-core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5 GHz with 1MB L2 cache. The A72 claims 4.7 DMIPS/MHz.
This board has a Dual-core U74 (RV64GC) 64-bit SoC @ 1.5 GHz with 2MB L2 cache. The U74 claims 2.5 DMIPS/MHz.
So, roughly 1/4 as fast as a RPIi 4B given the roughly half DMIPS/MHz and half the cores?
That, of course, is a really rough guess, ignoring lots of potential variables.
The CPU cores are comparable to the ARM A55, rather than the A72.
It's more MHz and a better uarch than the cores in a Pi 3, so should outperform even the newer Pi 3+ on tasks that don't use NEON and don't use more than 2 cores.
Would this have any sort of meaningful impact on sound/music related processing? E.g I am thinking of vst applications running inside DAWs
> All GPIOs can be configured to different functions including but not limited to SDIO, Audio, SPI, I2C, UART and PWM
Does supporting audio mean that these GPIOs can be used as analog-to-digital converters? There are home automation applications where reading a voltage in an ethernet connected device is a good fit but from what I've seen in a raspberry that requires extra hardware connected to the IO ports.
As an aside, I really wish that these boards would include more than two PWM outputs. The Raspberry Pi has two as well, and it feels really limiting. Analog control instead gets farmed out to microcontrollers, when you could probably make it work with a single board if there were more pins to work with.
I used to love the beaglebone for that. Run application logic on the main arm core, farm the microcontroller stuff out to the embedded PRU microcontrollers (which could access all the IO functions). Still a single board solution.
I agree-as far as I know, the BBB had something like 8 PWM channels. I'm not saying you need all of them, but at least 4 seems somewhat reasonable.
I'm curious, what do you do with so many PWM outputs?
I just play with electronics for side projects but stick to digital for everything, so I'm wondering what I'm missing out on.
Honestly, I'm still mostly getting started in the area as well, but I'm looking to use them for motor control. An example of this would be this paper , which I'm hoping to replicate to some degree, but requires at least 4 PWM outputs. I'm currently planning on using an Odroid-C4, which has 6 PWM outputs.
But the work I've needed to put into that in order to get a motor controller working was way more than I needed than for a RPi4b, since libraries for it already exist for the Pi vs needing to re-write them for the Odroid board. It would have been cool to try it with an open-hardware board as well. But it's not just quadcopters--a lot of other projects like rovers or position control with multiple stepper on different axes benefit from extra PWM, and doing it in software can lead to too much jitter, so the hardware timers are necessary.
It probably means I2S.
Makes sense. Just another digital bus. Bummer.
Eh, a decent audio DAC pretty much requires another chip since it takes up a ton of die space, so you'd be an absolute fool to use the same process node as your logic. Since this looks to be beagleboard compatible, you should be able to use an audio cape like this https://www.element14.com/community/docs/DOC-67906/l/beagleb...
If you don't care about it being decent, you can just use the PWM channels like the RPi does.
Is the SiFive U74 open source?
I know the RISC-V ISA is, but I thought the SiFive designs were proprietary.
Looks like their Hard IP is proprietary but based on open high-level designs such as Rocket and BOOM. The peripherals situation is mixed, but they've stated in the past that they're quite OK with using open designs whenever feasible.
The high-level design is proprietary too.
As I said elsewhere, SiFive CPUs are just as closed as Arm ones, you just pay a royalty to SiFive instead of Arm.
> The high-level design is proprietary too.
They have source code files for their 'Freedom' core designs up on GitHub under an Apache 2.x license. These can be directly used to evaluate their designs as FPGA soft-cores.
This is not correct. Anyone can design and build a RISC-V CPU without ever getting permission from anyone.
Anything that uses the ARM ISA on the other hand requires a (costly) licence from ARM.
SiFive has its own proprietary *implementation" buty that's not required, and there are many free open source implementations.
They aren't for the customers of SiFive. What is your greater point with this comment? That SiFive isn't Open Source or that they are equivalent to Arm?
This video from SiFive clearly explains the RISC-V ecosystem and how SiFive is involved.
Open source refers solely to the software side of things in these groups and types of projects. Thus, all of the drivers and software you need to use the SiFive is open source and thus you can say it is an open source design. However, it is not an "open hardware" design in that the IP used to design the chip is not released.
> However, it is not an "open hardware" design in that the IP used to design the chip is not released.
The marketing page for the BeagleV specifically says "Open Hardware Design", but I agree that they probably didn't mean Open Hardware beyond just the PCB layout or something similar.
It would be very surprising if they released the detailed schematics for the SiFive cores. Until there's some kind of common micro-fab standard where every major university can have a legit semiconductor fab for small scale operations, giving people the design doesn't really do much.
I really wish that someone would work on the problem of making affordable, small-scale semiconductor fabrication possible on a reasonably modern node (<= 32nm). It's a hard problem... but everyone in the world being dependent on a few large fabs is also a hard problem.
Correct. This is open at the ISA, PCB and software level, not the chip RTL.
Still, it is a step forward.
For something more open at the RTL level, I'd look at Precuror (https://www.crowdsupply.com/sutajio-kosagi/precursor) right now.
Speaking as someone at Beagle, we see this board as an important step to more openness in the ecosystem, especially helping software developers improve the state of open source for RISC-V. It is also just a really cool board. Beagle will do more to try to get more openness at the RTL-level moving forward, perhaps even with FPGA boards at an interim step. The shuttle services are starting to make releasing a new chip design in reasonably modern nodes more possible.
The processor maybe, but what about the e.g. USB3 controller, WIFI, etc, that can also freely snoop around your memory. Are there even open USB3 implementations?
> that can also freely snoop around your memory.
Can them? Even with IOMMU?
EDIT: I don't think so.
Is there an IOMMU specification standardized on RISC-V yet? I think it's just some early proposals.
Or proprietary designs that achieve similar functionality such as Hex Five and WorldGuard.
Am I right?
Does it have an GPU? I can't quite decipher the specs.
Random googling suggests that SiFive have partnered with PowerVR for GPU, which might even enable vulkan support, but I suppose this SoC is not one of those?
As per the Ars link;
> The initial pilot run of BeagleV will use the Vision DSP hardware as a graphics processor, allowing a full graphical desktop environment under Fedora. Following hardware runs will include an unspecified model of Imagine GPU as well.
Also, ImgTec are planning on writing and upstreaming open drivers for Linux and mesa for another RISC-V based board, so probably those drivers will work here too.
I don't think that necessarily says that ImgTec will be upstreaming the open drivers, more that they don't have a better option at the moment and will be replacing closed source components with each revision.
I hope they will, but I'll believe it when I see it. They've been extremely allergic to open source in the past.
Anybody know what changed their mind? As I recall, they've always been pretty hostile to open source.
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.