[HN Gopher] BeagleV - An affordable RISC-V computer designed to ...
___________________________________________________________________
BeagleV - An affordable RISC-V computer designed to run Linux
Author : pathompong
Score : 452 points
Date : 2021-01-13 13:06 UTC (9 hours ago)
(HTM) web link (beaglev.seeed.cc)
(TXT) w3m dump (beaglev.seeed.cc)
| fctorial wrote:
| Where's the source code?
| rwmj wrote:
| I don't think it's open source. RISC-V is an open ISA, but
| implementations are not required to be open source (although
| there are many implementations which are).
| Pet_Ant wrote:
| I like to think of it as an open-standard like where anyone
| can download the TCK versus something where you need to pay
| for the SPECs from ISO (for example Prolog is
| https://www.iso.org/standard/21413.html which is 185EUR/$250
| USD).
| [deleted]
| my123 wrote:
| SiFive CPUs are just as closed as Arm ones, you just pay a
| royalty to SiFive instead of Arm.
|
| Only the ISA itself is open, (fast) implementations are not.
| (for any commercial-grade one instead of academic projects)
| coder543 wrote:
| The marketing page indicates that the product isn't finished
| yet.
|
| Presumably, they will release schematics and such when the
| device enters manufacturing, if they follow through on actually
| being Open Hardware.
|
| As others mention, the processor core designs probably won't be
| open.
| akmittal wrote:
| Most RISC-V processors use really old node sizes. Even Raspberry
| Pi is on 28nm.
|
| To be more efficient and complete with mainstream processors a
| move to 10/12nm is required.
| rwmj wrote:
| I think everyone is well aware of that, but unless you're
| making and able to sell millions of boards and have hundreds of
| millions in cash flow, there's no real path to using 10nm or
| smaller nodes. FWIW AllWinner are currently manufacturing 5
| million RISC-V chips (with TSMC IIRC). I don't know what node
| they are using.
| akmittal wrote:
| Raspberry Pi is sold in millions but still on 28nm
| tyingq wrote:
| AllWinner's XuanTie 906 RISCV chip is supposedly 22nm.
|
| https://www.cnx-
| software.com/2020/11/09/xuantie-c906-based-a...
| blacksmith_tb wrote:
| With a claimed price of $12USD, too.
| CameronNemo wrote:
| I guess if you can spring for smaller node sizes, you can
| spring for ARM licensing too.
| TrueDuality wrote:
| 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...
| bradstewart wrote:
| 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.
| lsllc wrote:
| Robert C. Nelson has been doing a stellar job of maintaining
| the omap-image-builder repo:
|
| https://github.com/RobertCNelson/omap-image-builder
|
| (and https://elinux.org/BeagleBoardUbuntu)
|
| 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.
| jandrese wrote:
| The board I have has only 4GB of MMC on board which wasn't big
| enough for the later versions of the OS, but you could boot off
| of the SD instead if you held down a button on the board while
| powering it up.
|
| There was a way to tweak it so you didn't have to hold the
| button down, but it was kinda involved IIRC so I never got
| around to it.
| bradfa wrote:
| 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.
| Teknoman117 wrote:
| 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.
| scoopr wrote:
| 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?
| archanox wrote:
| 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.
| pabs3 wrote:
| 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.
|
| https://riscv.org/blog/2020/11/picorio-the-raspberry-pi-
| like...
| monocasa wrote:
| 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.
| stragies wrote:
| They've been delivering that vacuous promise every few
| years. Being bought by Canyon Bridge, a private equity
| fund owned by the Chinese government, a few years ago has
| unfortunately not changed anything.
| Narishma wrote:
| Anybody know what changed their mind? As I recall, they've
| always been pretty hostile to open source.
| CameronNemo wrote:
| Maybe the realization that they are not NVIDIA.
| brucehoult wrote:
| Apple dropping them?
| throwmemoney wrote:
| If the form factor is reduced to something like an NSLU2 you can
| attach a large spinning disk and have a desktop server/NAS
| device. i.e., an unlocked WD MY Cloud with open source community
| android and iphone app for the device
| mikece wrote:
| Which will be generally available first: the BeagleV or the
| Raspberry Pi 5?
| mrweasel wrote:
| 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).
| Rond wrote:
| Check out Khadas VIM3
| 1vuio0pswjnm7 wrote:
| 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.
| znpy wrote:
| > 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.
| brucehoult wrote:
| https://www.crowdsupply.com/sifive/hifive-unmatched
|
| 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)
| mrweasel wrote:
| That's a little costly, but I guess development of a board
| like that isn't cheap.
| edsouza wrote:
| The board has 16GB DDR4 memory on board, that's probably
| one of the most costly components.
| jandrese wrote:
| 16GB DDR4 2400 DIMMs run about $67 retail. So about 1/10
| of the total cost of that board. It's a little apples and
| oranges, but since it seems like they just plucked down
| the same 8 chips you'd find on a DIMM right to the board
| maybe not that much.
|
| I note that it has a PCIe x8 slot, but they don't have
| drivers for a video card (or any card) yet so it's kinda
| useless.
| brucehoult wrote:
| People have been running Radeon graphics cards with Linux
| desktop and the open source driver on the predecessor
| HiFive Unleashed board for literally three years already.
|
| SiFive demonstrates the HiFive Unmatched using a $300
| 150W Radeon RX580.
| https://www.youtube.com/watch?v=HVsnnYuvDXI
|
| You can complain that you don't want to spend that much
| on a graphics card [1] but you can't complain that it's
| not supported.
|
| [1] cheaper ones will work too
| brucehoult wrote:
| Existing is the first step. Prices will reduce in time --
| probably quite rapidly.
| qwerty456127 wrote:
| Why would you need SATA when you have SD, also USB3 and Gigabit
| Ethernet? I have no problem booting from the SD then accessing
| data on my SATA drives using a USB-attached controller, also
| plan to get a NAS.
|
| Sure, it would be great to have connectors for everything and
| support for every cool standard but these guys have to give up
| all what is non-essential to keep it small, cheap and possible
| to engineer by a small team.
| tubularhells wrote:
| Because he wants to run a file server from it. This too was
| my first question.
| EamonnMR wrote:
| I'm running a file server with a pi and a USB enclosure for
| a huge sata drive, and it works fine. Could be neater
| though.
| cogman10 wrote:
| Honestly I just wish there was a faster standard than SD.
| 100MB/s for solid state is just incredibly slow now-a-days.
|
| There's no reason you couldn't kick SD transfer speeds up
| towards SSD speeds other than the protocol doesn't allow for
| it.
| blkbjhjkl wrote:
| I wish folks would stop conflating boot media and root
| media. There's no reason your SD card has to consist of
| anything more than u-boot.
|
| SD is fantastically simple, so that the boot rom can get at
| a bootloader without much effort (generally the bootrom
| just looks at a memory offset on the mmc device). Once you
| start speaking newer faster protocols, this simplicity is
| lost. You're not likely going to find a bootrom that
| implements all the bits needed to get u-boot from a sata
| device.
|
| In a perfect world, once these are no longer developer
| devices, the mmc would be replaced with some spi flash (or
| even an emmc) with just u-boot.
|
| On 90% of embedded dev systems, you're better off thinking
| of the sd card as a "bios chip" then a hard drive. The fact
| you can also use it as a block device to store a rw
| filesystem is almost incidental, and should probably be
| avoided.
| colejohnson66 wrote:
| CFast is CompactFlash, but with a SATA-based interface (up
| to ~600 MByte/sec) instead of IDE. It was designed because
| video cameras were making too much data for CF to handle.
| The downside is its size: 43x36x5 mm vs 15x11x1 mm for
| microSD.
|
| Also, CFast aren't as ubiquitous as microSD. I can go to
| Target or Walmart and get a wide "selection" of microSD,
| but I'd be hard pressed to find a CFast card. So the
| chances of an SBC using CFast over eMMC or microSD is low.
| tenebrisalietum wrote:
| SD cards are fragile.
| mlyle wrote:
| No, not too complicated, though connectors of all kinds take
| lots of space (both physical space and routing). Not to mention
| the amount of power that SATA drives might take.
|
| HardKernel/ODroid has things like the oDroid-HC4.
|
| Also, USB3-to-SATA isn't completely crazy to do.
| TimSchumann wrote:
| If I had to guess, and this is just a guess, so take it with a
| grain of salt. I'd bet most storage devices these days are just
| thin wrappers around PCI-Express lanes, most of the hardware in
| the silicon running that stuff is on die for AMD/Intel CPU's
| and you likely run into cost/power/board space limitations in a
| device like this
| Octoth0rpe wrote:
| FWIW, I believe the IO boards available for the Pi4 CM variants
| have a PCIe slot that could use used for storage:
| https://www.raspberrypi.org/products/compute-module-4-io-boa...
|
| Lack of sata/m.2 port is very frustrating to me.
| mbreese wrote:
| You can certainly use the PCIe support on the RPi 4 CM with a
| SATA controller. Either with a PCIe SATA card on the IO board
| you linked, or by building a custom board.
|
| The Turing Pi project looks to do that with their next
| version: https://turingpi.com/v2/
|
| Should be much more stable than a USB3 connection.
| numpad0 wrote:
| Yes; SATA host controller is an extra if the SoC don't come
| with one, connectors can't be cheap either. Too expensive as a
| nice-to-have item.
| happimess wrote:
| I'm certainly no expert, but I've never been able to run a
| spinning disk HDD off of a raspberry pi without a powered USB
| hub. I imagine the thermals and form factor would be hurt
| pretty badly by including a plausible power supply.
| mceachen wrote:
| Try a higher-quality power supply for your RPi.
| jandrese wrote:
| Honestly even with a high quality supply I'd tend to prefer
| if the drive were externally powered. I have flashbacks to
| the first generation Pis that would brownout and reboot if
| you plugged in a mouse or keyboard while it was running.
| mrweasel wrote:
| It wouldn't need to be a spinning disk, I'm think SSD or NVME
| mbreese wrote:
| I still need to run an SSD off of a powered hub for an RPi
| to use it stably.
| hackmiester wrote:
| Strange. What Pi? I've had a spinning 2.5" HDD connected
| to a Pi 3B+ for a few years now.
| artificialLimbs wrote:
| Running a spinny 2.5" 1TB drive on my pi zerow using a
| Samsung rapid charger to power the pi.
| swebs wrote:
| The Rasperry Pi 4 can power an 2.5 HDD just fine.
| seabird wrote:
| 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.
| lsb wrote:
| You can get an SD card with 0.5TB capacity on it for USD$30,
| what storage needs do you foresee? Also these tend to be used
| where weight is an issue, so, why do you want to lug around a
| huge disk?
| MisterTea wrote:
| SD cards are too slow to be of practical use as a general
| purpose disk. They're fine when you have a very predictable
| workload that does not involve a lot of disk IO.
| cjbconnor wrote:
| Nearly all SD cards that I've used in Pis and other SBCs have
| died unpredictably in the past, so I've pretty much given up
| on using them
| megous wrote:
| Using f2fs and setting up the SW on my SBCs to not write
| data needlessly to SD card all the time (some programs are
| really bad at this), and having a very high quality power
| supply and cabling was enough to make my boards work for
| years on a single SD card. Some are at 4 years currently
| and still work fine. I'm using Sandisk only, since a few
| years ago, because it's the only manufacturer that allows
| me to verify online whether the card I bought is genuine
| and provides A1 rated cards at the same time. Experience
| with about 20 boards.
| adrianstoll wrote:
| Samsung provides authentication software for their sd
| cards too.
| novok wrote:
| We shouldn't have to do that or special USB boot things
| that don't integrate well with extra cables sticking out
| of the form factor.
| Drdrdrq wrote:
| Same here. I now run them read only.
| moftz wrote:
| I have a special SD card made up that has all of the
| correct boot configs set and a small script to update
| everything and set up the Pi for PXE boot. After everything
| is configured, I take out the SD card and let it just pull
| boot images over the network. My main home server serves
| everything up over tftp. The only downside is that you
| can't get this to work over wifi. The wifi Pis get read
| only SD cards that are all configured the same so it's easy
| to reimage a new one if the card dies.
| btreecat wrote:
| How about _reliable_ storage needs?
| numpad0 wrote:
| SD in itself isn't technically unreliable. Lots of
| smartphones do just fine with eMMC, which is same thing as
| microSD card except in nonstandard IC chip form thus can't
| carry SD branding.
| monocasa wrote:
| Practically they end up being really different. SD Cards
| end up being bottom of the barrel flash chips (even from
| the 'good' brands), whereas eMMC uses flash good enough
| that you can count on it being non replaceable.
|
| You want "industrial" cards from a vendor tailored to the
| space. I wouldn't trust even those new industrial sandisk
| cards.
| jschwartzi wrote:
| Yeah as someone who has deployed SD-based and eMMC-based
| systems in industrial spaces, SD cards are hot garbage
| compared to eMMC and I would strongly recommend not using
| them in anything that needs to be reliable.
| jandrese wrote:
| There should be a market for people who will pay extra
| for SD cards that:
|
| 1. Absolutely don't lie about their capacity
|
| 2. Have a reasonable MTBF
|
| 3. Are reliably fast
|
| But instead we're all dealing with an industry that raced
| to the bottom years ago.
|
| I'm concerned that the same mentality will infect the
| eMMC market eventually and it will become impossible to
| find quality parts after a couple of years.
| jwandborg wrote:
| An M.2 SSD is not huge. In my experience, SD cards are way
| slower than SSDs for random access operations.
| stjohnswarts wrote:
| compiling on SSD is so slow. I once compiled an rpi kernel
| on rpi just for fun and it took forever. Cross compiling is
| the only way to go for now, unless you only have a small
| project.
| jandrese wrote:
| Raspberry Pis tend to be skimpy on memory. If it starts
| swapping it's going to be slow even on a fast SSD.
| hajile wrote:
| I suspect they don't necessarily mean spinning platters. A
| SATA port also allows the connection of an SSD which is
| almost always a huge boost in usability over SD slots. The
| fact that you can add a large platter for a small NAS
| solution is just a nice option.
|
| I'd far rather see a 2x PCIe port that could be used for
| whatever you wanted.
| mrweasel wrote:
| I would love to see a Micro-ATX og Mini-ITX board with an
| ARM or RISC-V CPU, with PCIe ports and storage connectors.
| There are ARM boards, but they're a little pricy.
| brucehoult wrote:
| https://www.crowdsupply.com/sifive/hifive-unmatched
|
| 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)
| unwind wrote:
| At $679, that's more than "a little pricey" to me at
| least.
| vhodges wrote:
| https://turingpi.com/v2/ is coming (soon?!?). Uses 1-4 Pi
| compute modules.
| tachyonbeam wrote:
| I think it's just that most people want to use the
| Raspberry Pi for toy projects. They're trying to keep the
| cost down, and to keep the board small. If you want
| something like micro ATX ARM motherboard, that's a
| different use case. The large majority of Raspberry Pi
| users are fine with USB 3.0 ports for I/O.
| tjoff wrote:
| Most that are complaining about this just want something
| reliable.
|
| Raspberry pis are very popular as audio streamers, media
| centers that streams of the network, home automations
| etc.
|
| But all or them greatly suffer from the fact that it can
| randomly die on you. Which is quite frustrating.
|
| The only sensible solution (imho) to this currently is
| netbooting but it can be a hassle to setup in some cases.
|
| An integrated 16GB emmc would do wonders for everything
| mentioned above.
| bsder wrote:
| We have an alternative to the RPi that has an eMMC. It's
| called a Beaglebone.
|
| And everybody bitches that the board is too expensive.
| hajile wrote:
| A PI4 compute unit with 8GB of RAM instead of 1GB
| (faster, DDR4 instead of DDR3 too) and 32GB eMMC and a
| quad-core 64-bit CPU with much higher IPC while only
| costing $90 which is around $50 cheaper than a
| BeagleBoard AI (the same comparison exists for the Black
| too). You also get direct PCIe access to do what you
| want.
|
| Beagle just doesn't offer anywhere near the same value.
| bsder wrote:
| The Black compared with the older RPi3. And everybody was
| always "The RPi3 is cheaper".
|
| The conversations always went like this:
|
| "Cheaper? So, did you count the SD card you need for the
| RPi?"
|
| "But it's cheaper."
|
| "And the special power supply because the RPi power
| systems suck?"
|
| "But it's cheaper."
|
| "And the keyboard and monitor because it doesn't run
| headless over USB?"
|
| "But it's cheaper."
|
| "... Okay, boss, it's cheaper. Go have fun."
|
| And that's before we even start talking about the lousy
| documentation of the RPi CPU chips. And the fact that the
| Ethernet was installed over the USB. etc.
|
| But the RPi was cheaper. Shrug. The guys at TI learned
| their lesson. Throw everything off the board and make it
| cheap--the hackers don't give a shit about anything else.
| greyhair wrote:
| Two different targets, I have used both. I have so many
| 5V power supplies sitting around, they git in the way.
| Including 12v/5v buck converters for auto stuff. You can
| configure for headless when you set up the SD card before
| you ever boot. I have never booted a Pi with attached
| display/keyboard.
|
| The Pi is cheap, for a reason, but it is still more
| powerful than anything I use it for. But the same goes
| for the Beagle Board.
|
| Choose the board you want, for the project you are doing.
|
| Note: For every RPi project I have done, I have done two
| or three ESP8266/ESP32 projects along with five or six
| AVR/M0/M2 Arduino projects.
| tjoff wrote:
| It doesn't have the same ecosystem. Which is half the
| point of the rpi to start with.
|
| But if you vouch for it I'll take a closer look.
| bsder wrote:
| > It doesn't have the same ecosystem. Which is half the
| point of the rpi to start with.
|
| Now _that 's_ a valid argument. And I would argue it's
| way more than half.
|
| If you want a one-off _mumblesomething_ and can stay at
| the Linux OS level (ie. Web application, USB peripherals
| or maybe the most basic of GPIOs), the RPi ecosystem is
| going to let you get there _much faster_ even though it
| will crash and burn occasionally. If that 's "good
| enough" ... Douzou! ... Ganbatte! ... get moving and get
| going.
|
| I have the same comment about Arduino. It ain't real
| reliable (but, to be fair, it's quite a bit more reliable
| than the RPis), but the ecosystem is awesome.
|
| However, when you start asking something like "Gee, how
| do I send a single address byte over the I2C subsystem?"
| or "That signal needs a response in 50 nanoseconds, can I
| make that work?" you will thank the TI folks for
| producing that 5000 page (not joking or exaggerating)
| Technical Reference Manual.
|
| One other thing that people who live in the RPi system
| always overlook in the Beagle ecosystem are the PRU
| cores. You can do _HARD_ real-time work on those and
| still live in the Linux world. That 's something that the
| RPi series just simply cannot do no matter how much you
| hack at them. And it often means the difference between a
| design which needs an FPGA and one that doesn't.
|
| However, yes, you are going to live in that Technical
| Reference Manual for the Beagle series. If you're not
| comfortable doing that, then the Beagle stuff probably
| isn't for you.
|
| There are really good reasons to use and love RPi's--ease
| of use is huge. But the whole "It's cheaper" thing just
| chaps my hide.
| tjoff wrote:
| I'll take your word for it, but it sounds like a very
| different use-case than most use the pis for though.
|
| When you spend that much time with your device cost isn't
| a factor (imho). But the pi is cheap enough that I can
| gift one if I know the end result will work well. And it
| is quite nice to just have one lying around for when you
| get an itch.
|
| Using netboot I have never had an issue with the pi. All
| reliability problems I've experienced can be tracked down
| bad power and SD-cards (note: I have not used any IO
| other than USB). Both are annoying enough to look for
| alternatives but both are also fixable (netbooting likely
| disqualifies it for many usecases though).
|
| Minimizing reads on the sd card usually means that they
| work at least several years untouched (in my experience,
| obviously limited sample size), which is likely good
| enough for many (a true read-only system might work even
| better). But when the audio streamer in the vacation
| cabin dies when you aren't around to fix it is still
| frustrating. So I'm in the moment of figuring out how to
| move the last of them to be netbooted. Which has some
| very nice side-effects as well, such as trivial remote
| system backup+restores.
|
| It also comes down to time. I know the pi and the
| pitfalls. Researching an alternative would take many
| hours and I'd still have to experience some of them. If
| the goal of the project isn't to learn a new sbc then
| that alone is a dealbreaker.
|
| That said, PocketBeagle seems to support wifi netboot
| (which neither the pi and pi zero w do). Might be able to
| find a project for that!
| mrweasel wrote:
| The SD card on the Raspberry Pi is 50 MBps max, if I recall.
| That's a little slow if you want to use it as a small
| desktop.
|
| I don't want to lug around anything, I want it to sit behind
| my monitor. Also an M.2 drive isn't that big, it could fit in
| many existing cases.
| adamc wrote:
| SD cards are kind of slow, though.
| jug wrote:
| Cheap, slow (as an operating system medium at least), and
| unreliable. They're the modern day floppy disk. The one
| upside is that the space is cheap and quite plentiful.
| jacquesm wrote:
| Mount a fileserver via NFS?
| vhodges wrote:
| You might be interested in the RockPro64 which comes with a
| PCIe 2.0x4 slot for all your HBA needs.
|
| https://wiki.pine64.org/wiki/ROCKPro64
|
| https://pine64.com/product/rockpro64-4gb-single-board-comput...
| rjsw wrote:
| If you already have an SD card controller then an eMMC slot is
| probably the easiest upgrade.
| karakanb wrote:
| The website is super slow. It downloads 7.66MB of files, and it
| took 1.05min to load for me on a 2020 MBP with 150Mbps bandwidth
| and ~15ms latency.
| brucehoult wrote:
| I didn't measure the size, but it loaded in 4 seconds here in
| Chrome on Ubuntu, via VDSL.
| zwirbl wrote:
| From the Guidelines: Please don't complain about website
| formatting, back-button breakage, and similar annoyances.
| They're too common to be interesting. Exception: when the
| author is present. Then friendly feedback might be helpful.
|
| Still, the page loads in ~3secs on my 2012 i7-3770K with
| 100Mbps...
| stragies wrote:
| The page is horrific though. 2 meters of scrolling for 7
| sentences and 3 pics.
| trollied wrote:
| Welcome to the modern web :(
| pizzazzaro wrote:
| Noscript + ublock origin fixed that for me.
| qalmakka wrote:
| There's something wrong at your end, 1 minute to download 7.66
| MBs is abysmally slow for a > 100 Mbps connection.
| [deleted]
| cmrdporcupine wrote:
| Interesting, I might get myself one of these to play with.
|
| But the board has an HDMI output, however the description doesn't
| describe the specifications on display processor / GPU
| functionality, or even if it's just a simple framebuffer, etc.
| There's specifications on Video processing, but I get the
| impression this is for camera / video input, not output.
| Narishma wrote:
| According to [0] the first revision will just have a
| framebuffer, later ones an unspecified Imagination GPU.
|
| 0 - https://www.cnx-software.com/2021/01/13/beaglev-powerful-
| ope...
| stragies wrote:
| That means PowerVR, most likely. Bad news, no useable drivers
| ever existed for mainline linux kernel for any PowerVR CPU
| pabs3 wrote:
| 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.
|
| https://riscv.org/blog/2020/11/picorio-the-raspberry-pi-
| like...
| stragies wrote:
| Haven't they been promising that since about 3 years? As
| far as I know, that never materialized.
| tyingq wrote:
| Arstechnica says this:
|
| _" 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."_
|
| https://arstechnica.com/gadgets/2021/01/seeed-and-beagleboar...
| joshlk wrote:
| What features makes it "designed for Linux"?
| vhodges wrote:
| Most risc-v cores to date have been more on the micro-
| controller side of things (ie without an MMU). The cpu on this
| board has one so it can run Linux.
| nickwanninger wrote:
| Likely that it supports the Supervisor execution environment
| from the riscv spec [1]. This means it can run the typical ring
| 0 and ring 3 for kernelspace and userspace respectively, and
| importantly the board supports virtual memory.
|
| [1] https://riscv.org/wp-content/uploads/2017/05/riscv-
| privilege...
| wheybags wrote:
| This looks really awesome. It's been a longstanding desire of
| mine to build a custom laptop with one of these powerful small
| SOCs (originally thought of something like the lattepanda, which
| is similar to an Intel macbook air, but as a slightly bigger tan
| pi soc).
|
| Would be super awesome to do it with riscv
| filleokus wrote:
| 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)?
| rwmj wrote:
| 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.)
| deepGem wrote:
| 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.
|
| https://www.crowdsupply.com/sifive/hifive-unmatched
| rwmj wrote:
| 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.
| giantrobot wrote:
| Why would you want use these as build machines? It seems
| more efficient to just cross-compile on your fastest
| build machines. You get much faster CI feedback that way.
| Obviously you want to validate RISC-V code on native
| devices but using them as builders seems wasteful.
|
| I'm genuinely curious why that's desirable. Maybe I just
| misunderstand your comment and you want the RISC-V boards
| for validation i.e. make sure you can self-host the
| distro even if in general releases are cross-compiled on
| your (I assume AMD64) build fleet.
| FullyFunctional wrote:
| I'm sure the Fedora builds aren't designed for cross
| compilation (which is far from trivial for most packages
| not designed for it). Also, man-power is the most
| precious resource so it would be a waste to spend time
| trying to cross-compile what could be built natively.
| giantrobot wrote:
| As long as you've got the target toolchain on the host,
| the code has no idea it's being cross compiled. If you've
| got the tooling set up it's a lot of setting of envars.
| It's not trivial but it's also not super difficult. A
| compiler running native on an architecture doesn't
| produce any different output than the same compiler doing
| a cross compilation.
|
| Even if you wanted to run a native RISC-V build process,
| running it in QEMU on a much more powerful AMD64 system
| will get you the same results in a fraction of the time.
| This gets much faster feedback in the CI system.
| eclipseo76 wrote:
| > We will likely buy a pile of them to do Fedora builds.
|
| Do you expect a lot of things to break on RISCV?
| anderspitman wrote:
| Looks like you can get it from Mouser for $665 as well:
|
| https://www.mouser.com/ProductDetail/SiFive/HF105-000?qs=zW
| 3...
|
| Found that link from this SiFive page:
|
| https://www.sifive.com/boards/hifive-unmatched
| caeril wrote:
| This looks great, thanks!
| tyingq wrote:
| 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.
| brucehoult wrote:
| 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.
| jgjot-singh wrote:
| Would this have any sort of meaningful impact on
| sound/music related processing? E.g I am thinking of vst
| applications running inside DAWs
| asd4 wrote:
| On the list of features: "Dedicated Audio Processing DSP
| and sub-system".
|
| The hardware might be there to do some good audio
| processing, but how it integrates with the OS is
| something I'm not experienced with.
| miohtama wrote:
| Is video hardware also open source like RISC V CPU?
| WatchDog wrote:
| Is the SiFive U74 open source?
|
| I know the RISC-V ISA is, but I thought the SiFive designs were
| proprietary.
| stragies wrote:
| 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?
| joana035 wrote:
| > that can also freely snoop around your memory.
|
| Can them? Even with IOMMU?
|
| EDIT: I don't think so.
| chem83 wrote:
| 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?
| gjsman-1000 wrote:
| 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.
| coder543 wrote:
| > 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.
| jdkticom wrote:
| 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.
| ipodopt wrote:
| Some of them are open source: https://github.com/sifive/freedom
|
| So this board has an open source CPU:
| https://www.sifive.com/boards/hifive1-rev-b
|
| This does not: https://www.sifive.com/boards/hifive-unmatched
|
| Although, I get the feeling they will open source design on a
| rolling basis. Pure speculation.
| zozbot234 wrote:
| 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.
| my123 wrote:
| 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.
| dkjaudyeqooe wrote:
| 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.
| sitkack wrote:
| 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.
|
| https://www.youtube.com/watch?v=CmGIJMYwWNw
| my123 wrote:
| Arm provides Verilog source code of their CPU cores for
| their customers. It's an industry standard practice.
| sitkack wrote:
| You haven't said anything about SiFive.
| zozbot234 wrote:
| > 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.
| my123 wrote:
| The SoC, with the Rocket core used. This is very
| different from SiFive's own U series cores, which are
| proprietary.
| zozbot234 wrote:
| SiFive has E-series (aka "Freedom Everywhere") and
| U-series (aka "Freedom Unleashed") cores, both of which
| seem to be based on Rocket. And they do provide high-
| level designs for both on their GitHub, under a free
| license.
| my123 wrote:
| High-level designs of the SoC, not of those cores
| themselves is public for some platforms.
|
| Based on whatever for the core doesn't matter, as the
| cores themselves in any case diverge quite a lot from
| Rocket.
| basher wrote:
| Arstechnica coverage:
| https://arstechnica.com/gadgets/2021/01/seeed-and-beagleboar...
| Narishma wrote:
| There's something wrong with that page in Firefox. It pegs a
| whole CPU core and eats tons of memory.
| sradman wrote:
| > 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_ [1] which I
| think demonstrates that SiFive is strategically leveraging or
| responding to the geopolitics surrounding Chinese technology.
|
| [1] https://www.eenewsanalog.com/news/sifive-creates-global-
| netw...
| wiremine wrote:
| > Sounds like a direct competitor to the Raspberry Pi.
|
| I would consider the Black and Green to be competitors too.
|
| https://beagleboard.org/
|
| Would be really interested to get a good analysis of the
| Raspberry Pi, BB Black, and this new board.
| lsllc wrote:
| 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.
| samstave wrote:
| >>* _SiFive is strategically leveraging or responding to the
| geopolitics surrounding Chinese technology.*_
|
| interesting subtext.
|
| 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....
| sradman wrote:
| 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_ [1]
| is a real thing and, until I see contrary evidence, I 'm
| assuming it makes zero contribution to high-tech assembly
| or manufacturing.
|
| [1]
| https://en.wikipedia.org/wiki/Slavery#Contemporary_slavery
| samstave wrote:
| You have my upvote, but not my agreement;
|
| We have min wage in the US, and even that is not equal
| across all states - we do not have UBI or universal
| health care, we have shitty industries, such as insurance
| (forced hedge funds) and in general, we have brainwashing
| people to accept it as normal.
|
| fuck that.
|
| YC even wants you to think that all VC is all-truistic
| NOPE.
| rhn_mk1 wrote:
| 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.
| blihp wrote:
| 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.
| tyingq wrote:
| 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.
| farseer wrote:
| Can't find any cost information
| bahorn wrote:
| The google form lists the prices in an image:
|
| * $119 for 4GB of RAM
|
| * $149 for 8GB of RAM
|
| But the early version apparently is only the 8GB variant.
| michielr wrote:
| I just got an email from Seeed Studio
|
| > BeagleV(tm) is the first affordable RISC-V board designed to
| run Linux. Based on the RISC-V architecture, BeagleV(tm) pushes
| open-source to the next level and gives developers more freedom
| and power to innovate and design industry-leading solutions
| with an affordable introductory price at $149.
| ARandomerDude wrote:
| The type of questions in the application questionnaire ("Click to
| Apply") is encouraging -- it makes me think they anticipate some
| real professional interest in this.
| chiffre01 wrote:
| Is there a list of RISC-V CPUs in production someplace?
| coder543 wrote:
| I'm not sure if this is comprehensive, but it lists a good
| number of companies implementing RISC-V.
|
| https://en.wikipedia.org/wiki/RISC-V#Implementations
| ashleysmithgpu wrote:
| "Open source" with nvidia hardware? Good luck with that
| orbifold wrote:
| nvdla is actually open source including (most?) of the low
| level software: https://github.com/nvdla
| jdkticom wrote:
| correct, no NVIDIA hardware, just their NVDLA project which
| is open source. http://nvdla.org.
| [deleted]
| spurdoman77 wrote:
| Why the linux boards are always designed to be cheap? What about
| those who have little more dough and are willing to put some cash
| to get extra? Just create some expensiver premium models, not
| only cheap stuff, damn it.
| yiyus wrote:
| Because, obviously, everyone wants to be the RISC raspberry.
| Becoming the expensive-alternative-to-raspberry-nobody-knows-
| about is not so attractive.
|
| Moreover, it looks to me like these cheap boards are not
| lacking features. What would you want in a premium version that
| is not present in the current models?
| Teknoman117 wrote:
| A few suggestions there:
|
| - hardkernel boards
|
| - Nvidia Jetson AGX Xavier (8 core + 512 CUDA core volta GPU,
| PCIe 4.0)
|
| - Honeycomb LX2 (16 core, quad SFP+ (for 10G optics), PCIe 4.0)
|
| I purchased an AGX Xavier for doing some self driving robot
| projects.
| ansible wrote:
| HiFive Unmatched has up to 16GB of RAM:
|
| https://www.sifive.com/boards/hifive-unmatched
|
| But it is a little pricey.
| jandrese wrote:
| Because the expensive stuff doesn't sell.
|
| At the end of the day most of these are just toys and it's hard
| to justify spending $850 on a device that is less capable than
| a $500 mini form factor OEM box if you're doing something
| serious.
| pantalaimon wrote:
| What does affordable mean in that context? There is no price on
| the website.
|
| edit: CNX Software has some more info [0] - it's $119, still a
| far cry from a Raspberry Pi or Orange Pi
|
| [0] https://www.cnx-software.com/2021/01/13/beaglev-powerful-
| ope...
| messe wrote:
| $149 for 8GB of RAM on a RISC-V board is _very_ affordable
| compared to the previous options.
| StreamBright wrote:
| For that price you can get a decent SOC with ARM64 too.
| pjc50 wrote:
| You pay more to have something Free. Software people have
| yet to realise this reality of the hardware market.
| patrec wrote:
| That's not the point. Risc-V machines are not yet price
| competitive, but presumably will be at some point. This is
| for people who are interested enough in Risc-V to spend
| some time and a ~$100 on it, but not thousands of of
| dollars. And the main reason many people are interested in
| Risc-V over Arm is that it's open and license free.
| brucehoult wrote:
| Raspberry Pi 4 with 8 GB RAM is $75, and that's not counting a
| power supply, SD card, or HDMI cable. Adding those at pishop.us
| (16 GB card) takes the price to $95.85.
|
| We don't know whether the BeagleV price includes those
| necessary items or not but either way coming within a factor of
| 2 of Raspberry Pi price is pretty impressive at this stage. Up
| until now you've paid $3000 for a 1.5 GHz RISC-V setup with
| HDMI and USB etc, if you've got one actually in your hands
| (HiFive Unleashed plus MicroSemi HiFive Expansion board), or
| $665 for one that will start delivery in March (HiFive
| Unmatched). There is also the $499 Icicle which is quad core
| but only single-issue (like the HiFive Unleashed) and only 600
| MHz.
|
| Prices are plummeting.
| pedrocr wrote:
| > 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.
| monocasa wrote:
| It probably means I2S.
| pedrocr wrote:
| Makes sense. Just another digital bus. Bummer.
|
| https://en.wikipedia.org/wiki/I%C2%B2S
| monocasa wrote:
| 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.element1
| 4.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.
| pedrocr wrote:
| I don't really want audio. What I'm looking for is to
| read 3.3V or 5V analog levels, with really low frequency,
| once a second or less would be fine.
| jononor wrote:
| Many cheap and easy to interface I2C and SPI chips for
| that, which is the way the industry is going generally.
| Or throw in a tiny Arduino with stock Firmata firmware,
| and use that as an I/O extender.
| pedrocr wrote:
| That's the extra hardware I mentioned. I guess I wish the
| RPi just included one of those chips and had say 4 to 8
| pins for ADC. It would make things simpler versus having
| to find something already well integrated or building it.
| monocasa wrote:
| In that case you can probably hook up the GPIOs to a
| resistor ladder if you know the shape of the analog
| signal you're trying to sample.
| qchris wrote:
| 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.
| Youden wrote:
| 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.
| Teknoman117 wrote:
| 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.
| qchris wrote:
| 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.
| alkonaut wrote:
| Can someone explain the technical benefits of this architecture
| over the competition? That is should I be excited if I _don 't_
| care about e.g. openness? Or is it simply an effort to create
| something that is a half-decent cpu alternative but open?
|
| Is there anything about RISC-V that is "better" simply because it
| is a later design than others? Is it likely to evolve faster
| because it is open or more modern?
| tyingq wrote:
| I think in the real world _" No percentage of each sale
| payments to ARM"_ is what will drive RISC-V. An "open" ISA
| doesn't force anything else to be open.
|
| So, use cases like Western Digital, where they can quit paying
| ARM a percentage of every hard drive they sell, for example.
|
| As for technical advantages, each RISCV vendor has their own
| choice of how to implement, so it's hard to say anything broad
| that applies to all RISCV implementations. The Berkeley BOOM
| project is hitting really good DMIPS/MHz numbers. LowRISC has
| some interesting memory tagging and "minion core" ideas, etc.
|
| Edit: I left out perhaps the most important reason RISCV has a
| lot of hype. They've been successful getting first class
| support from the Linux kernel maintainers.
| pjc50 wrote:
| > quit paying ARM a percentage
|
| The percentage is very small, though. So this argument only
| works for very high volume use cases, which is why the RISC-V
| eval boards are currently far more expensive than comparable
| ARMs.
|
| Do WD do their own silicon yet, or do they just buy the
| parts?
| nickik wrote:
| WD has their own cores and they are OpenSource. Very nice
| designs. They also spend a lot of money on the open source
| ecosystem for chip development.
|
| See:
|
| - https://www.westerndigital.com/company/innovations/risc-v
|
| - https://chipsalliance.org/
|
| - https://github.com/chipsalliance/Cores-SweRV
| blihp wrote:
| Hasn't WD been doing their own silicon (at least from a
| design standpoint, they still use someone else's fab)
| precisely because the 'small percentage' ARM charges
| matters for their margins? In a world where we have ESP-01
| boards which _retail_ for $2, even a couple of percent
| matters.
| reportingsjr wrote:
| How many ARM microcontrollers are low volume? Pretty much
| all of the examples I can think of are incredibly high
| volume. STM32, SAMD21/51, i.MX, etc.
|
| WD said they were finishing taping out their first
| production design about a year and a half ago, so I assume
| they have started shipping them at this point, but it's
| hard to find info.
| Narishma wrote:
| They design them. I don't know if they make them or not.
| ansible wrote:
| > _Is there anything about RISC-V that is "better" simply
| because it is a later design than others?_
|
| A lot of it is because it is newer, and the designers have
| learned from previous architectures. It is a relatively clean
| and straightforward instruction set, designed to be easily and
| efficiently implemented.
|
| There's not anything that is super crazy revolutionary, in
| contrast to the (still vaporware) Mill CPU architecture.
|
| > _Is it likely to evolve faster because it is open or more
| modern?_
|
| They have a good extension mechanism that allows relatively
| clean additions to the instruction set. Some of the recent ones
| like the vector extension aren't finalized yet. Anyone can
| propose their own extension. Historically, ARM might work with
| their most important customers to implement an extension, but
| good luck getting their attention if you're not already paying
| them millions per year.
| drewm1980 wrote:
| The mill has been in development for... 18 ~years now! Soon
| they will be able to hire engineers who are actually younger
| than the company. I wonder if there has ever been a tech
| company that survived so long without bringing a product to
| market. Duke Nukem Forever took ~14 years.
| CyberDildonics wrote:
| Their product is hardware patents.
| ansible wrote:
| I would be happy if they just released a instruction-
| level simulator to play around with.
|
| It would also be super-nice if they released at least a
| Copper or Tin core (low-end) that can be synthesized to
| an FPGA for people to try out.
| acehreli wrote:
| That's patently wrong. :) I worked for the Mill for a
| while The Mill is as real as it gets. EDIT: No, there is
| no actual CPU but the software, the compiler, the
| simulator, etc. exist.
| CyberDildonics wrote:
| Where does their income come from? When is the CPU going
| to be released?
| ansible wrote:
| From what I understand, all the developers have day jobs or
| are independently wealthy and can afford to work on it
| without (much?) pay. They haven't accepted VC money, even
| though that would likely have sped up development
| considerably.
| mhh__ wrote:
| According to Ivan on their forums (so take this with a
| grain of salt as it's from the horses mouth rather than an
| external assessment) they were apparently supposed to be
| levelling-up in the summer of 2020.
|
| They have at least secured a decent patent portfolio,
| particularly on the belt.
| jdkticom wrote:
| One of the other replies points to the RISC-V extensions
| feature. I think for someone who "doesn't care about openness"
| would at least benefit from that in the architecture. It means
| the same compiler can be used to bootstrap things and simple
| steps can be added to greatly optimize specific types of code,
| like AI stuff. This board really stands out in AI performance.
|
| Also, having things open means that the supply-chain can be
| more stable, with less chances of a single glitch in the system
| halting deliveries for any time. This is driving a lot of
| interest in RISC-V right now.
| IshKebab wrote:
| Compared to ARM, nothing significant. They're very similar
| load-store architectures.
|
| Here's a RISC-V quick reference:
| https://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/files/docs/...
|
| And ARM:
| http://users.ece.utexas.edu/~valvano/Volume1/QuickReferenceC...
|
| The main difference is that RISC-V is a lot more modular, so
| it's going to be difficult to distribute binaries for but more
| flexible if you're doing something completely vertical. Also a
| lot of the modules have bundle relatively common/easy
| instructions with niche/difficult ones. E.g. multiply with
| divide.
| hajile wrote:
| > The main difference is that RISC-V is a lot more modular,
| so it's going to be difficult to distribute binaries for but
| more flexible if you're doing something completely vertical.
| Also a lot of the modules have bundle relatively common/easy
| instructions with niche/difficult ones. E.g. multiply with
| divide.
|
| I don't think it'll be worse than ARM and it's decidedly
| better than x86.
|
| There are SEVEN _major_ revisions of ARMv8. Then there 's
| v8-R, v8-M, and additional 32-bit variants of each
| instruction set in addition to both ARMv7 and ARMv6 which
| also still ship billions of chips per year. Oh, and under
| pressure from companies, ARM also allows custom instructions
| now. Those aren't just theoretical either -- Apple at least
| added a ton of custom matrix instructions to the M1.
|
| For x86, supporting only semi-recent processors (2006 Core or
| greater) leaves you still checking for support for: SSE3,
| SSE4, SSE4.1, SSE4a, SSE4.2, SSE5, AVX, AVX2, AVX512, XOP,
| AES, SHA, TBM, ABM, BMI1, BMI2, F16C, ADX, CLMUL, FMA3, FMA4,
| LWP, SMX, TSX, RdRand, MPX, SGX, SME, and TME. That's 29
| instruction sets and not all of them have use on both Intel
| and AMD chips.
|
| RISC-V seems at least that cohesive. If you're shipping a
| general purpose CPU, you'll _always_ have mul /div,
| compression, fusion (not actually instructions), privilege,
| single precision, double precision, bit manipulation, and
| probably a few others.
|
| Where you'll run into mul/div missing or no floats are
| microcontrollers or "Larabee" style GPU cores. In all of
| those cases, you'll be coding to a very specific core, so
| that won't really matter.
|
| Thankfully, we've had ways to specify and/or check these
| kinds of things for decades.
| brucehoult wrote:
| Do you have a reason to think the matrix instructions in
| the M1 are not those specified in Armv8.6-A?
| hajile wrote:
| I don't know, but you can look further here.
|
| https://gist.github.com/dougallj/7a75a3be1ec69ca550e7c36d
| c75...
| IshKebab wrote:
| > leaves you still checking for support for: SSE3, SSE4...
|
| Find me a processor that supports SSE4 but not SSE3. That's
| the problem. With x86 you pretty much can say "we're
| targeting processors made after 2010" or whatever and
| that's that. You make one binary and it works.
|
| RISC-V allows a combinatorial explosion of possible CPUs.
| You can have a CPU that supports extension X and not Y, but
| another one that supports Y and not X.
| brucehoult wrote:
| If you're doing something embedded nothing prevents you
| implementing multiply but not divide. RISC-V gcc has an
| option to use an instruction for multiply but runtime library
| call for divide.
|
| In fact, even if you claim to implement the M extension (both
| multiply and divide) all that is necessary is that programs
| using those opcode work -- but that can be via trap and
| emulate. If your overall system can run binaries with
| multiply and divide instructions in them then you can claim
| M-extension. Whether the performance is adequate is between
| you and your customers. Note that there are also vast
| differences in performance between different hardware
| implementations of multiply and divide, with 32-64 cycle
| latencies not unheard of.
|
| The same applies for implementing a subset of other
| extensions in hardware. You can implement the uncommon ones
| in the trap handler if that will meet your customer's
| performance needs.
| IshKebab wrote:
| Yeah if you're willing to do something completely non-
| standard of course you can do whatever you want.
|
| > Note that there are also vast differences in performance
| between different hardware implementations of multiply and
| divide, with 32-64 cycle latencies not unheard of.
|
| Yes that is exactly the problem.
| yiyus wrote:
| I'm quite excited about vector instructions. The approach used
| in RISC-V is very refreshing coming from SIMD. But I would not
| expect an instant impact from a user point of view.
| cbm-vic-20 wrote:
| The ISA is pretty nice, simple, and well documented. And since
| it's "open", people can create their own implementations. Like
| this guy, who is creating a RISC-V processor from scratch,
| without using an FPGA.
|
| https://www.youtube.com/playlist?list=PLEeZWGE3PwbZTypHq00G-...
| fctorial wrote:
| How is RISC-V better than x64? Aren't both of them just ISAs? The
| only pro I can find is that RISC V is cleaner (less legacy). But
| no one programs in assembly these days so why is this an issue?
| rwmj wrote:
| It's more about the licensing of the ISA. Try creating your own
| compatible x86 processors, and find out how long it takes
| before Intel's attack lawyers come down on you. ARM is a bit
| better but you still have to pay licensing fees. For people who
| want to git clone a design and manufacture it without involving
| lawyers or licensing fees, RISC-V is likely the best choice.
| Pet_Ant wrote:
| Think of it as MP3 vs Ogg Vorbis. It's equivalent, slightly
| newer and a bit nicer, but really the benefit is that it's
| patent-unencumbered and you are free to tinker with the ISA and
| build your own versions at will.
| loudmax wrote:
| Not many people program in assembly, but teams working on
| compilers like gcc and LLVM very much do care about the ISA.
|
| Apple has been able to make great progress moving from Intel
| x86 to their own custom ARM M1 processor. The way I understand
| it, RISC-V may allow similar advances.
| arnaudsm wrote:
| Awesome project! But please compress your images, it took me 2
| minutes to load your website.
|
| Convert everything to <300kb progressive jpg and use svg for
| graphics.
| jdkticom wrote:
| OK.
| jdkticom wrote:
| https://developers.google.com/speed/pagespeed/insights/?url=.
| .. score still isn't great, but at least the images aren't
| the bottleneck anymore. The site is in the process of a grand
| rebuild that should get rid of the recurring jquery loads,
| but that's a few months away.
| HoverSausage wrote:
| Where are these manufactured?
___________________________________________________________________
(page generated 2021-01-13 23:00 UTC)