OSDev.org

I don't know how relevant this is, but this video points out something which (until now, anyway) has been part of the RPi's appeal: being able to use the GPU acceleration in the default Linux distro used with a board which sells for < US$50. In many other SBCs, though not all, full GPU acceleration has only been available for the Android port, not the standard Linux distro; Raspbian is one of the exceptions, due to RPF's close ties to Broadcom. Interestingly, the article they are discussing claims that the GPU on the Orange Pi 3 is now fully supported upstream, meaning standard Armbian or Arch ARM distros should be able to drive at least this particular Mali GPU model.

In the immediate term, this means bupkiss for an OS Dev, but it may (probably not, but may) impact the RPi's share of the SBC market.

bzt, your answer only proves my point of many people thinking there is nothing except RPi, or - nothing better, or cheaper. This is even sad. It's so not true. By all means - RPi is not the cheapest, nor the best (to mess around with). I am in no way gonna advertize here other SBC vendors, but what you called arrogantly "replica", are worthy products made by a big bunch of enthusiasts, running their smallish companies, and communities, consisting of dedicated and passionate people, making way better ARM mini PCs than RPi does. Just to name a few, - Odroid, Pine64, Xunlong (Oranges), SinoVoip (Bananas), Khadas, T-Chip (Fireflies), LibreComputer, Radxa, Cubietech (Cubieboards), SolidRun (ClearFog, Hummingboard, Cuboxes etc). Finally, such monsters as Asus entered this "hobbyistic" range, with their very solid Tinkerboard. Replica? O really? Haven't you heard of/looked at these SBCs ever? You wouldn't be calling them so, if you had. There is a youtube channel, ExplainingComputers, its author makes awesome videos on the subject of SBCs as well, and makes interesting reviews and comparisons between them too. Watch them to get the idea. We have a sea of ARM SBCs, of which RPi is an underdog overadvertized to look a king. I have nothing against RPi foundation*, they do a good thing, maybe, but what they've picked for their SBCs up (broadcom SoC) just sucks. sucks badly, sucks turbulently.
For example I bought Banana Pi M2 Ultra for 50$. It has 2GB of DDR3 RAM, SATA port, 8 GB of eMMC, 1G Ethernet. Or, for the same price Rock64. Having 4GB of LPDDR3 memory, USB3, 16MB of SPI NOR, so rare for SBCs. Or octacore Odroid-XU4 with big.LITTLE dual-clustered processor, still being sold as a special offer for 49 bucks!!! Btw, their eMMC could reach up to 140MB/s! SD only, without UHS-I support - of course! RPi could get only ~23MB/s. Where did you see similar set of HW capabilities on RPis? For the system programming, having these kewl interfaces (SATA, USB3/xHCI, 1G Ethernet, eMMC, UHS-I capable SD, even PCIe is available, i.e., rk3399 boards like RockPro64) is a fun. where are all those on RPis? Did they freaking finally add 1G Ethernet at least? Cheap. It's because there is nothing over there to pay for.

Schol-R-Lea, I can't watch the video now, but Orange Pi 3 is a brand new thing, it is so fresh, with the Allwinner H6 SoC, I kinda doubt there is really "full" GPU support in linux yet, but who knows. Everything I heard about H6 boards (PineH64 for example, or some previous cutoff versions of Oranges) were nearly unusable, due to the lack of the basic linux support. of anything. There is some Bootlin thing, they work hard on bringing these goodies (GPU, VPU) into linux though. I heard, they did recently something with supporting Cedar (Allwinner VPU) in linux.
Funny, I was often wondering why other distributives of linux can't make use what's already been done for android, graphics acceleration wise. And when I read in some blog the supposed answer, I was wow. The answer is - because android uses different ... C library!

* - by the way, I remembered an episode showing them being p\/ssies a little. At one time, Odroid was making an RPi "clone", a very similar board, highly compatible, coming with the same Broadcom SoC. Initially, Broadcom was selling SoCs for them just fine. But then, all of sudden, stopped and cancelled farther supply... So, RPi does have teeth, and uses them, even pretending to be a fluffy bunny, friendly to kids.
And yet one thing, I heard, Odroids have been visiting ISS. Kinda not bad for "replica", right?

ExplainingComputers is a good channel, but as I expect some of you know already, he is hardly the only one covering this space. A few others I know of to look into are MickMake (probably the most technically informative of the ones I've seen, with a heavy emphasis on actual projects), ETA Prime (who covers the retrogaming angle very thoroughly and very well), and Novaspirit Tech (who is good for quickie reviews but tends to be light on substance; his project videos aren't bad, though, but he does usually stick to RPi for those simply due to how well he already knows it). These are just the ones I am most familiar with - there are at least fifty other channels covering the topic, and even some of the more mainstream tech channels such as LTT have had some videos on it.

I will add that, from the programming side of things, most of the videos on the topic cover RPi - and mostly older RPi models at that. But then, programming videos are generally problematic in my experience, often being either outdated or light on substance or both. They are useful as supplemental material, but not very good as a primary learning tool, IMAO.

For the most part, the RK3399 boards are still the new hotness, though this new Allwinner SoC which the Orange Pi 3 uses may steal some of it's thunder if the earlier video is any indication. There seems to be a growing interest in the RISC-V based SBCs which are trickling onto the market as well, though so far most of those haven't been much of a much.

zaval wrote:what you called arrogantly "replica"

There was nothing "arrogant" in that sentence, just the truth.

RPi was the first cheap ARM microcomputer available for the masses (the key part here are "cheap" and "available"). They tried to produce it in the UK first, but their greed was stronger than their patriotism, so the production moved to China. After the factories were built there, many similar microcomputers popped up in great quantities. It was in late 2012 when the production moved to the UK, but the damage has already been done.

And here comes the interesting part, although it was said that all production moved to the UK, the majority of RPis are still produced in China.

zaval wrote:Odroid, Pine64, Xunlong (Oranges), SinoVoip (Bananas), Khadas, T-Chip (Fireflies), LibreComputer, Radxa, Cubietech (Cubieboards), SolidRun (ClearFog, Hummingboard, Cuboxes etc).

That's exactly my point. All the boards you've listed are either authentic Chinese boards, or manufactured there (with or without valid license), just like the RPi.

zaval wrote:Haven't you heard of/looked at these SBCs ever?

I made a quick check, and they are not sold here. I can order some of them online, but they all came from Chinese webshops, some of which are questionable at best. Yes, many of those shops are selling rebranded, illegal products, hence the phrase "replica" suits quite well.

RPi is the ONLY board I can buy with support and warranty in my country. Maybe others are better or cheaper, but what good does it make to me if I simply can't purchase them in a local computer store? Even if the RPi I buy was made in China, I don't care because if there's a problem with it, I can take it back and I got a new one free of charge. (Actually that stands for many Chinese products: they are extremely cheap, but 1% usually faulty. The local reseller doesn't care because the profit on the remaining 99% is double or more than on original products, so that's just a calculated risk on their part).

OFFTOPIC
How did the communist China defeat the capitalist West in their own game?

1. a new innovation is developed in the western world (US, UK, EU etc.), let's call it ACMESTUFF
2. taking advatage of capitalist's unlimited greed, China offers cheap labor for quick profit
3. China builds factory to produce ACMESTUFF with minimal cost
4. when the original quantity is shipped and the market is ready for the new product, the Chinese factory began to produce surplus, sold behind the back of the original creator of ACMESTUFF

Result: while the capitalists spend enormous amounts of money on research and marketing, China invests minimal but gets the most profit on the long run. I really doubt that China is paying any license fee after Adibas or Star Wrns.
/OFFTOPIC

Cheers,
bzt

Richard Miller, who did the first Unix port, retired a few years ago and ported Plan 9 to the Raspberry Pi for a hobby. He updated it for the Pi 2 & 3 last year, you could look at its driver source. Here's a few tips I've picked up over the years on which OSs to read:

* "Reading Linux kernel code is where the fun stops." -- Ron Minnich, then a Plan 9 dev; echoed by many
* OpenBSD kernel source is the first choice of 9front devs (Plan 9 fork) if documentation isn't enough
* Plan 9 and 9front kernels are much simpler and easier to read than even OpenBSD (but watch out for the non-standard C library)

I'm having a bit of trouble locating Richard Miller's latest code, (the plug was finally pulled on the official Plan 9 server,) so here's the 9front port, probably including his latest code, here:
http://code.9front.org/hg/plan9front/fi ... /src/9/bcm
Repository address:
http://code.9front.org/hg/plan9front/
You might possibly need an old version of Mercurial to pull it because porting things to Plan 9 is hard. (Non-standard C library, old POSIX compatibility layer, filesystem semantics aren't POSIX, etc.) A new port of Python has been made, but when I was last there, the 9fronters didn't want to take the time to make sure it won't break when they're relying on it. The old version has worked from the beginning of the project and doesn't have a billion features.

I've found an image of a slightly older version of Richard Miller's code on a mirror:
http://9p.io/sources/contrib/miller/9pi.img.gz
You'll probably need to boot the image to extract the code. (9front's code above is easier to get at.) But... this is where I realized I could give you the commands to extract the code but don't want to write a tutorial for Plan 9's window system, including how to make the terminal scroll...
Anyway, I've done this so many times I can type it from memory:
% cd /sys/src
% aux/listen1 -t 'tcp!*!9393' tar -c 9/bcm 9/port # optionally 9/pc 9/amd64
At the other end:
$ netcat $pi 9393 | tar -xv
or similar with Putty's plink -raw.
The delete key will kill listen1. The fshalt command makes it safe to shut down.

If you don't have tar on Windows, I think Plan 9's zip takes the same options as tar, but might not be able to send its ouput over a pipe. If not, make a file, and substitute:
% aux/listen1 -t 'tcp!*!9393' cat $zipfile

While I agree that the OpenBSD source is often a far better guide than the rather erratic Linux code is, there are some caveats:

• None of these boards are meant to be used as stand-alone desktop or mobile systems; while it is possible to uses them as such, the real intent of them is for education, and for rapid prototyping of IoT devices and other embedded projects. The availability of a full-fledged operating system, accelerated graphics, Ethernet, Wifi, USB, Bluetooth, etc., on them is solely for the convenience of the hardware developers to ease development and debugging.
• Given the above, the SoC designers and SBC integrators have no reason to bend over backwards for non-Linux OS devs, and every reason not to. They are entirely justified in deliberately making it harder for lunatics like us, who do unsupported things with their hardware and then expect them to hold our hands. We, as a group, make their jobs harder just by doing what we do.
  For that matter, this same logic applies to PC hardware vendors as well. Look at how reluctant most GPU vendors have been to provide working open-source drivers for Linux even now - and for good reason. The more OSes they have to support, the more support costs them. Linux support is a money-losing proposition, on its own, even regarding proprietary drivers. They only do it because it is good PR (which they are gambling will bring in more sales in the long run, even if it is at a cost in overhead).
• If you are intent on an OS design which is radically different from Unix, none of these Unices are very useful as a guide to driver development. For example, my own kernel design, Kether, is going to be written in a Lisp derivative, and will use runtime code synthesis in the drivers. IIUC, Zaval's also outside of the mainstream in many regards (though perhaps not to the same extreme degree as with Kether); certainly, my impression is that Zaval despises all the existing mainstream OSes.
• All of the various OSes for RPi still use the Broadcom blob driver for several key GPU functions. For a non-Unix OS, accessing those functions will mean bending your driver model out of shape in order to accommodate the blob driver.
• This is by no means unique to the RPi - indeed, it is my understanding that because of the licensing of, and patents applying to, the Bluetooth protocol, it is impossible to write a FOSS Bluetooth stack for any hardware without breaking both the law and the technology licensing. AFAIK, none of the commonly available and used Wifi hardware for SBCs has either open-source drivers or sufficient documentation needed to implement one, as well.
• Most of the boards other than the RPi do not have any OpenBSD ports, and many don't have even RiscOS ports. Armbian is often the only freely available source code example for the hardware, while the other option, Android, is usually not available as source for the given SBC.
• In quite a few cases (especially RK3399 systems), the only version that supports the GPU acceleration features is Android, and these ports are invariably closed-source for the drivers. No open-source versions of the full drivers are currently published, even where they would be possible.

Schol-R-LEA wrote:some caveats

Good points, I'll bookmark this. I'm starting to feel better about my Kaph being a sort of application stack rather than the operating system I wanted it to be. That said, I'm also hoping for affordable FPGA-based hardware. A nice board was made for 9front around an IC with 2 ARM cores and an FPGA. Couldn't design for the FPGA on 9front, but could load designs into it which is the main thing. Not cheap though; production run of only about 20 boards. Anyway, this is off topic, I'll stop now.

eekee wrote:

Schol-R-LEA wrote:some caveats

Good points, I'll bookmark this. I'm starting to feel better about my Kaph being a sort of application stack rather than the operating system I wanted it to be. That said, I'm also hoping for affordable FPGA-based hardware. A nice board was made for 9front around an IC with 2 ARM cores and an FPGA. Couldn't design for the FPGA on 9front, but could load designs into it which is the main thing. Not cheap though; production run of only about 20 boards. Anyway, this is off topic, I'll stop now.

You might want to consider a RISC-V alternative at some point, though right now all of the significant ones are either implemented on FPGAs (of which there are several), are microcontrollers with no memory management (e.g., HiFive 1), or cost a small fortune (SiFive's HiFive Unleashed is the only one I know of that has a full MMU and other support needed for a full-fledged OS such as Linux). This is expected to change this year as more and more RISC-V hardware comes to market, but it is impossible to say at this point how many options there will be and at what prices.

However, this does little to help regarding either GPUs or Wifi, as there really aren't any FOSH options for either of them (yet), and FOSS drivers for the less-open hardware that the SoCs may end up using is, well, the same as for ARM systems really.

(Interestingly, NVidia are going to be using a modified RISC-V core for their next GPU controller (or has this already happened? I'm not sure), but that's not going to be something which affects the GPU cores themselves; I have no idea if they will be exposing that controller core to software developers.)

The HiFive Unleashed gets around this by not being an SoC; it uses standard DDR4 memory chips (on the SBC), and has no accelerated GPU. For accelerated graphics, you would need to get an add-on backplane with two PCIe x16 slots, meaning you can add a stock video card to it (and they do have Linux drivers for some older cards which will work with it). However, at $1000 each for both the HiFive Unleashed base unit and the backplane, plus a video card and other additional hardware, you'd be looking at nearly $3K for a working system, not really a feasible option for most hobbyist developers. The whole system is about the size of an mITX PC, too. This video covers the current state (as of ~6 months ago) of RISC-V systems, with specific coverage of the HiFive Unleashed.

In other words, RISC-V is a potential still, not really a practical option. When and if this changes, it is likely to be a big deal for SBC integrators and maker-class developers, but that's still in the future.

I forgot about RISC-V.

Schol-R-LEA wrote:This is expected to change this year as more and more RISC-V hardware comes to market,

Woohoo!

Schol-R-LEA wrote:However, this does little to help regarding either GPUs or Wifi, as there really aren't any FOSH options for either of them (yet), and FOSS drivers for the less-open hardware that the SoCs may end up using is, well, the same as for ARM systems really.

That's odd, I remember a FOSH GPU project years ago. I guess it fizzled out. It was for PCs but I'm pretty sure it was PCI, not PCIe; it was that long ago.

I'm not convinced a GPU beyond a framebuffer is really needed if the bus is fast enough, unless of course you want more than minimal 3D graphics. I remember running mplayer under linuxemu on 9front with VESA framebuffer. I thought it was all right, but didn't test thoroughly for some reason. That was on a Thinkpad R400 with a Core 2 Duo CPU, but I can't find how fast its FSB was. There was some caching issue with some computers when doing this, but I didn't understand the details.

I wonder if aijuboard (the board I mentioned) had more than just a framebuffer GPU in its FPGA. It could rotate and warp the screen in response to its accelerometer -- very fancy for ascetic 9front! lol

Schol-R-LEA wrote:The HiFive Unleashed gets around this by not being an SoC; it uses standard DDR4 memory chips (on the SBC), and has no accelerated GPU. For accelerated graphics, you would need to get an add-on backplane with two PCIe x16 slots, meaning you can add a stock video card to it (and they do have Linux drivers for some older cards which will work with it). However, at $1000 each for both the HiFive Unleashed base unit and the backplane, plus a video card and other additional hardware, you'd be looking at nearly $3K for a working system, not really a feasible option for most hobbyist developers. The whole system is about the size of an mITX PC, too. This video covers the current state (as of ~6 months ago) of RISC-V systems, with specific coverage of the HiFive Unleashed.

Yeeek! 'OW MUCH? hehe~ Aijuboard was "only" about $150. It had 512MB DDR off the SoC. My friend routed all the lines for that on a 4-layer board. It was tough!

I'm thinking maybe I'll forget about RISC-V again for a couple of years. There are other boards built around FPGA+ARM ICs, I'd forgotten all about them too. Not that I actually want to get into Verilog, I'd be starting almost from scratch again.

What I really want to do is try to use GreenArrays ga144 for video output. 144 computers on one IC, 700MHz 18-bit, each with 64MW each RAM & ROM. I'd have much more fun with that than trying to get started with FPGAs. Rough calculations indicate it could do well over 1080p. The trouble again is cost, at least for the good board. There was a board produced for hobbyists, but the power lines weren't decoupled close enough to the IC. And again, I don't know if they ship to the UK.

Edit: Yay! There's a new ga144 board in the works, and an upgrade of the chip itself. That's a step up from the inactivity of a couple of years ago.

Schol-R-LEA wrote:In other words, RISC-V is a potential still, not really a practical option. When and if this changes, it is likely to be a big deal for SBC integrators and maker-class developers, but that's still in the future.

Yeah. I'll not bother with RISC-V yet. Unless I can do well enough without an MMU. There's a clone of AmigaOS which does all right without an MMU (even though it runs on PPC). Most of the programs save their state, so after a crash you can pick up where you left off.

There's a new small x86 for hobbyists with a breadboard on top. It's under $50, but I don't know if they ship to the UK. It was linked in another thread, but I think everyone looked at the first device featured at the link and not the hobbyist device below it.

Heh, coming full circle, "A Raspberry-style FPGA development board"

eekee wrote:

Schol-R-LEA wrote:However, at $1000 each for both the HiFive Unleashed base unit and the backplane, plus a video card and other additional hardware, you'd be looking at nearly $3K for a working system, not really a feasible option for most hobbyist developers.

Yeeek! 'OW MUCH? [..]
I'm thinking maybe I'll forget about RISC-V again for a couple of years.

Yeah, one of the problems with developing completely new chips in general is that they tend to be insanely expensive for the first 10,000 or so units shipped; those units not only have to swallow a lot of the development cost, but there is usually a shakedown period in which the yields are down around 50% or so, until the process is firmed up. In this case, both of those apply, hence $999 for the first batch of 64-bit RISC-V CPUs to reach the market.

Prices invariably drop as volume rises, but you usually need to sell those 10,000-50,000 initial units first... unless you're Intel or someone like that, who can afford to just eat a big part of the development costs of their new systems by leveraging existing sales.

Also, right now it is mostly a proof-of-concept device, not really one with a specific market. Think of it as Early Access hardware, like, say, the Vega Frontier card, or the engineering samples Intel and AMD send out to motherboard manufacturers - expensive, inefficient, and with significant lingering bugs, but it shows where things are going if your have the funding and expertise to read between the lines. It'll be a while before a full-fat RISC-V system is ready for the public.

OTOH, the lower-end 32-bit RISC-V micro-controllers like the FE310 seem to be coming along nicely, and the prices for those are likely to drop, which will at least give the maker-space hardware people a new set of options for the sort of things you might use an Arduino or a PIC for. SiFive are far from the only ones in that space, unlike with fully Linux-capable CPUs; right now, the FU540 is the only one like that on the market, and as I said earlier, it's only barely on the market at that. But that is set to change, too, as some other CPU fabricators seem ready to step up to making their own 64-bit RISC-V SoCs.

EDIT: There is one company claiming to have an < US$6 RISC-V SBC which runs Linux (albeit at only 574MHz). I haven't seen anything else about it except this post last November, so I'm more than a bit skeptical. Looking around more, I found another article here with more or less the same claims, but disavowing the RISC-V connection. This Hackaday article states that it is not, in fact, RISC-V, but actually an unrelated ISA. When I checked AliExpress for it, I found this at US$21.50 shipped.

Still, they're sort of in an awkward point right now. Chances are, a lot of what RISC-V will be use for in the near future will be things like drive controllers and programmable embedded devices. This blog post from last month and this article from a week ago should be good indicators of where things are headed in the short term.

Interesting details and some fun links, thanks.

Schol-R-LEA wrote:OTOH, the lower-end 32-bit RISC-V micro-controllers like the FE310 seem to be coming along nicely, and the prices for those are likely to drop, which will at least give the maker-space hardware people a new set of options for the sort of things you might use an Arduino or a PIC for.

32 bits to replace an Arduino? I understand this, but at the same time I find it a little bit staggering. I've never needed more than a 32-bit architecture in my life. Granted, for over a decade my life centered around this one game that was a bit demanding, but even it never needed 64 bits.

As for the lack of MMU, I think that warrants another thread.

Does this page help?

https://jsandler18.github.io/extra/prop-channel.html

I bought a RPi B a few years ago, and got far enough along to blink one of the board LEDs on and off in a loop, but I pretty much gave up after that. I may get back into it one day.

But this site seems to have documented at least a little of the undocumented message formats of both the old RPi and the newer ones.

This video giving an update about the work on porting the full version of Windows 10 to the Raspberry Pi (!) might or might not be relevant... though if it is, I'm not certain how.

This preview video on the Raspberry Pi 4 hints at some interesting developments, both good and bad. One thing that is definitely problematic, if not unexpected, is that it seems that the RPF have doubled down on the proprietary aspects, with a bespoke SoC which will probably not be documented to any real degree at all.

EDIT: Today's date? What do you mean, check today's date? sigh Oh, right, never mind... my face is red now, especially when it is so obvious looking at it again. Still, I might as well leave this post up, if only to remind myself not to be an April Fool.

Let's try that again - for real, this time. Both Explaining Computers and ETA Prime have dropped videos on the Raspberry Pi 4B. I'm not sure what it actually brings to this discussion, but I thought it should be mentioned anyway.

EDIT: Core Electronics has posted a benchmark video, as well. From the look of it, it is a substantial improvement over the 3B+, especially in the 4GB configuration... but that improvement is, at best, bringing it to par with other SBCs in that price range, so overall, not much of a much in terms of overall specs. Also, it is still using Videocore (naturally), with all that this implies about the lack of open documentation needed for implementing drivers. However, for other (maker-type) uses, it does bring the RPF support and the Pi user community with it, which may make a difference in some ways.