Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BeagleV – An affordable RISC-V computer designed to run Linux

beaglev.seeed.cc

Post reply on HN
Print view View original

291–300 of 311 posts

Re: BeagleV – An affordable RISC-V computer designed to run Linux

#291

Post by acehreli »

CyberDildonics wrote: post #210
acehreli wrote: post #199

Earlier quoted context omitted.

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.

Where does their income come from? When is the CPU going to be released?

I haven't worked for them for a few years now but it's still a "sweat equity" organization as described on the web page under "About" at https://millcomputing.com/

They consider investments for their minimal costs as well.

Re: BeagleV – An affordable RISC-V computer designed to run Linux

#292

Post by tenebrisalietum »

qwerty456127 wrote: post #259
cogman10 wrote: post #120

Earlier quoted context omitted.

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.

The existence of Raspberry Pi as it is, Raspberry Pi 4 in parricular, is is a huge leap forward for the humanity already. The next leap is going to be the same kind of board but with no connectors besides an increasing number of full Thunderbolt 4 ports letting you connect anything you can imagine (incl as many GPIO connectors as you need). There is no need in a zoo of connectors like M.2, U.2, SATA, HDMI etc when we…

There's value in having GPIO pins not behind any bus or controller at all. Don't Thunderbolt controllers need firmware uploaded and such before they start working? How complex is Thunderbolt device and bus enumeration?

Re: BeagleV – An affordable RISC-V computer designed to run Linux

#293

Post by lovelyviking »

1vuio0pswjnm7 wrote: post #282
lovelyviking wrote: post #277

Earlier quoted context omitted.

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…

>I actually came up with this myself just playing around with NetBSD. You will probably not find anyone advocating disabling swap.

Actually I saw recently some discussion exactly about that. I think many people would be glad to do it if they new how. It is not easy when you relatively new in the area. It is not too complicated but a lot of information and it is not obvious what is important and what not, so you read all and get overwhelmed easily.

>I do not run X11 anymore. I stay in VGA textmode. Doubt anyone would want to do exactly what I do.

I do exactly what you do, simply because x11 is not working on Pi with TV I have and I have nothing more since MBPro has simply died. (if you wish details, see here ”how“: https://news.ycombinator.com/item?id=25778247 )

>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.

Thank you very much. This advice is already precious, because it helps to orient yourself in tons of info, and now I would know where to start digging. I would love to try once I’ll have equipment and time. I really wish to encourage you though to write down this process, I am sure there are some people who are desperately looking for this setup and how to achieve it properly, bothered with many questions. This guide could also be a good practical introduction into a NetBSD by the way.

>Chromebooks are claimed to be 100% safe from certain types of attacks. The developers came up with this silly "whitewash" gimmick. Their motivation for a disk-less-like system is to force users to store personal data in the cloud. Ugh.

it’s a shame really and done for wrong purpose. I never considered Chromebooks seriously for that reason.

>Well, the disk-less systems I have been creating for recreational use long before Chromebooks existed are just as safe. Probably safer because I do not use a graphics layer or a web browser with Javascript interpreter.

What I really like about it is the ability of fast recovery, which gives more freedom for experiments. I love it.

Re: BeagleV – An affordable RISC-V computer designed to run Linux

#294

Post by 1vuio0pswjnm7 »

lovelyviking wrote: post #293
1vuio0pswjnm7 wrote: post #282

Earlier quoted context omitted.

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…

>I actually came up with this myself just playing around with NetBSD. You will probably not find anyone advocating disabling swap. Actually I saw recently some discussion exactly about that. I think many people would be glad to do it if they new how. It is not easy when you relatively new in the area. It is not too complicated but a lot of information and it is not obvious what is important and what not, so you read…

Note I did all the experiments many years ago, on i386, and using NetBSD's venerable bootloader. For the Pi, some things will differ obviously.

Not only does this type of setup give freedom for experiments (which NetBSD really does in general) but it makes expts easier. You can put multiple different kernels on the USB stick and reboot into each of them to test pros and cons of different release versions and/or configurations. Or you might boot one computer with kernel A, pull out the stick, insert into another computer and boot kernel B and run them simultaneously. No HDDs needed.

I might do a writeup; some users have done writeups on "disk-less" in the distant past. I have some simplification tricks no one has ever written about. However NetBSD has such great documentation relative to almost every other project and the developers tend to be "quietly competent" in the best way. It was never a culture of "HOW-TO's" as you will find in Linux. Studying the source and following source-changes and other mailing lists is better than any writeup, IMO.

It is like the old saw about teaching a man to fish. It is worth learning. Things do not change in NetBSD so fast or dramatically that what you have learnt will be later considered "obsolete".

Re: BeagleV – An affordable RISC-V computer designed to run Linux

#295

Post by panny »

cogman10 wrote: post #120
qwerty456127 wrote: post #91

Earlier quoted context omitted.

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 te…

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.

>Honestly I just wish there was a faster standard than SD

There is one. It's called UFS 3.0. The Sony Xperia 1 II has it. They're same size as MicroSD, but look slightly different.

https://store.shopping.yahoo.co.jp/rarahu-store/B085B2LTLB.h...

Re: BeagleV – An affordable RISC-V computer designed to run Linux

#296

Post by SulfurHexaFluri »

Fnoord wrote: post #279
SulfurHexaFluri wrote: post #249

Earlier quoted context omitted.

If you want sata then your best bet is probably the Intel NUC. Still fairly small but as powerful as your average laptop.

Aren't AMD NUCs supposed to be better now with Ryzen 2 and onward?

Probably. I had no idea such a thin existed

Re: BeagleV – An affordable RISC-V computer designed to run Linux

#297

Post by lovelyviking »

1vuio0pswjnm7 wrote: post #294
lovelyviking wrote: post #293

Earlier quoted context omitted.

>I actually came up with this myself just playing around with NetBSD. You will probably not find anyone advocating disabling swap. Actually I saw recently some discussion exactly about that. I think many people would be glad to do it if they new how. It is not easy when you relatively new in the area. It is not too complicated but a lot of information and it is not obvious what is important and what not, so you read…

Note I did all the experiments many years ago, on i386, and using NetBSD's venerable bootloader. For the Pi, some things will differ obviously. Not only does this type of setup give freedom for experiments (which NetBSD really does in general) but it makes expts easier. You can put multiple different kernels on the USB stick and reboot into each of them to test pros and cons of different release versions and/or confi…

I would agree that following source-changes is better then any writeups if there is time and dedication. I like the culture you describe and it could fit very well with the way I like to do things. I use those “how to” just as quick tutorial to get into the new topics and then I go deeper. It is easier to learn when you actually do something and if there is no person around who can introduce me into the topic properly which is much faster and better of course then I use some “how-to” for that. Writeups can help too so if you know some good ones it’s worth mentioning.

Re: BeagleV – An affordable RISC-V computer designed to run Linux

#298

Post by brucehoult »

giantrobot wrote: post #256
brucehoult wrote: post #241

Earlier quoted context omitted.

The older HiFive Unleashed (1.5 GHz single-issue) builds things considerably faster on a per-core basis than qemu-system on current amd64 (or at least did in the Skylake generation). The dual-issue cores in the HiFive Unmatched should be around 50% faster. amd64 machines do have the advantage that you can get them with 32 or 64 cores and hundreds of GB of RAM -- at a price, especially in power consumption. The three…

That's running qemu which is unnecessary for cross compiling. I'm not seeing any advantage to building on native silicon rather than cross compiling on existing machines AMD64 machines. Even with the power usage of the AMD64 chips being higher, the faster compilation speed will likely net less overall energy used for the builds. I fully understand wanting native silicon to do development on and to work on some archit…

There are many packages that compile some kind of tools and then run them to produce other things necessary for the build, possibly several layers deep.

In theory you can set up the build system to correctly know which things should be compiled native and which should be cross-compiled. Sometimes you even need native and cross-compiled versions of the same thing.

In practice, this is a capability that few people use and even if everything is set up correctly at some point most people contributing patches do not think about or test maintaining the ability to cross compile and it gets broken.

When you're building hundreds or thousands of packages for a distro such as Debian or Fedora this is a huge problem.

Building natively in a full system emulator or on real hardware is the only way, in practice.

Re: BeagleV – An affordable RISC-V computer designed to run Linux

#299

Post by brucehoult »

IshKebab wrote: post #191
hajile wrote: post #92

Earlier quoted context omitted.

> 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 A…

> 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 a…

If you're in an embedded situation where you're building all the software yourself then that's fine.

If you're on a general purpose PC/smartphone with packaged software then the OS vendor specifies a base set of extensions that everything must implement -- for Linux at the moment that is RV64IMAFDC aka RV64GC.

All of those extensions (except maybe A) are very generally useful and pervasive in code.

Some other extensions, such as the Vector extension, will provide significant benefits to applications that don't even know whether the system they are running on has them -- you'll just get dynamically linked to a library version that uses V or doesn't, as appropriate.

To take a very trivial example, on a system with V, every application will automatically use highly efficient (and also very short) V versions of memcpy, memcmp, memset, bzero, strlen, strcpy, strcmp and similar.

The same will apply to libraries for bignums, BLAS, jpeg and other media types, and many others.

Re: BeagleV – An affordable RISC-V computer designed to run Linux

#300

Post by brucehoult »

IshKebab wrote: post #190
brucehoult wrote: post #97

Earlier quoted context omitted.

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 wi…

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.

This problem exists even among different CPUs that all implement the M extension in hardware -- or different CPUs in ISAs where multiply and divide are not optional, such as x86 or aarch64.

The worst (but conforming) hardware implementations are barely better than the best software emulations -- and maybe worse if the software emulation is running on a wide OoO CPU.

Post reply on HN