Ahh, that trick was most productive. Looks like hardware video decoding is runtime unavailable Force disabled by gfxInfo Blocklisted; failure code FEATURE_FAILURE_VIDEO_DECODING_TEST_FAILED Since RasPiOS' version of firefox is 115, I guess that's expected.
Ok, that clarifies things considerably. Is the API public, at least? Then folks could experiment.
Is this to say that if somebody wanted to write a cryptocurrency miner for the Raspberry Pi VideoCore they'd need Broadcom's help?
Thanks for writing, I've learned a lot!
bob prohaska
Didn't find your answer? Ask the community — no account required.
B
bp
That's most encouraging. The Pi5 is on order, should show up in a week or so. I'll set up a clean install on a new disk to see how it behaves.
Thanks for writing!
bob prohaska
C
Computer Nerd Kev
Broadcom's API is DispmanX, which some programs have used directly, but libbrcmEGL is their library that presents an OpenGL interface and is thus easier to adapt software to. Separately the Linux kernel now has its own drivers, which are used via Mesa. I'm not sure how the performance compares, but the Mesa drivers are the popular ones these days.
There's more info about the various APIs indexed here:
formatting link
Only that it would be easier with Broadcom's help. But there's enough info about the QPUs available that it should be possible.
Here's an early example of the QPUs being used to run custom routines:
formatting link
More recent is this OpenCL implementation which probably makes it easier to do things like cryptocurrency mining:
formatting link
formatting link
The QPU processor cores are used along with one of two more capable VPU processor cores in the VideoCore IV GPU for running the stock GPU firmware. Broadcom released some documentation on the QPUs, but information on the VPU is all reverse-engineered or based on code written by Raspberry Pi developers who obviously have access to the proprietary docs. So that makes writing an open-source replacement for Broadcom's GPU firmware very difficult, but the QPUs can be used for parallel data processing jobs like crypto mining, and some simple things can be done with the VPUs as well.
C
Computer Nerd Kev
At the risk of correcting myself about details that nobody cares about anyway, it turns out the original work on Mesa's VC4 driver was led by a Broadcom developer as well. So that would really be Broadcom's current graphics API. Seems it actually bypasses the original closed-source firmware running on the VPU, to do that graphics processing on the CPU instead, which is a bit of a waste of the GPU's processing abilities. But it seems they preferred that to opening the sources and build system for the VPU firmware and improving upon that, though that's still used for hardware management tasks.
Here's the VC4 driver developer's blog:
formatting link
And their post about being hired by Broadcom to write the GPU driver for Mesa and the Linux kernel:
formatting link
More recently the GPU drivers for the RPi4 and 5 have be developed by Igalia, presumably as sub-contractor for Broadcom since Igalia took over from the Broadcom developer:
formatting link
It's interesting to find out where all this code comes from. Broadcom have been more involved than I thought.
L
Lawrence D'Oliveiro
The thing I usually do is put /home on a separate partition, taking up most of the storage space. The OS itself only needs a few dozen gig or so.
Another thing is to allocate a second partition the same size as the OS one, but left initially unused. That way, you can later switch to a different OS but have it mount the same /home partition, saving the trouble of moving files across.
L
Lawrence D'Oliveiro
Given my experience with SD cards, I think that’s wise.
Indeed. It's interesting to note that about ten years have elapsed, and it looks as if the Pi GPU is getting close to general usefulness.
That's about how long it took from the advent of the i386 to the general availability of *nix clones.
Thank you for a most informative post!
bob prohaska
A
Ahem A Rivet's Shot
...
More like five years, the 80386 came out in 1987. There were BSD ports available by 1993 and the first Linux release was in 1991. However that's just open source - There were commercial XENIX and Interactive ports earlier - even for the 80286.
T
The Natural Philosopher
Very hard to put a decent Unix on a 286 - Venix was the only one, I recally. No memory management.
the 386 made porting unix pretty simple. SCO unix was extremely stable. Wasn;'t that a Xenix evolution?
Interactive was a bit s***ty, but it ran.
A
Ahem A Rivet's Shot
XENIX was available for the 8086 and the 80286.
Altos used to make a surprisingly usable XENIX machine with an 8086 main processor and a pair of Z80B IO processors (one for the serial ports, one for the tape and disc). They kept this basic architecture while upgrading processors (80286+2x8086, 80386+2*80186).
The 80286 had a protected mode with memory management but did not supply any means to exit from it so the transition to kernel side unprotected mode had to be done by calling on the keyboard controller to reset the processor - code then checked a flag location for the value that said this wasn't a cold boot.
It certainly did.
Yes SCO bought XENIX from Microsoft, then when they switched to the SysVR4 codebase (AT&T pulled in everything they could from XENIX and BSD) they got to rename it to Unix. The earlier XENIX was also rock solid IME on PC or Altos hardware.
B
bp
We're comparing different endpoints. I started with 386BSD and it could be made to install and run by about 1992, but that alone was an accomplishment for a non-expert like me. It took a few more years to become _usable_ by non-experts, in the form of FreeBSD. Maybe I'm off a little on the dates (I learned of 386BSD about a year after the Byte Magazine series by Jolitz) but then it was still very fiddly. By about 1997-8 I was using FreeBSD for email.
Others were doubtless quicker on the uptake, but they were a select group. I was (and am) merely an early-adopting consumer.
Thanks for posting,
bob prohaska
A
Ahem A Rivet's Shot
Indeed it was - did you have the patch kit ?
Nope FreeBSD 1.0 came out in November 1993 - I was using 1.1.5.1 to run a Dublin based ISP in 1994. We gave Jordan Hubbard a free account when we discovered he was visiting Ireland and he gave us a stack of 1.1 discs. He got the better deal :)
That would be late 2.2 or early 3.0 days - 3.0 was the release that included APM support for laptops, one of the few occasions I ran -current.
Many others between 1994 and 1998.
B
bp
Not to begin with, the patch kit came later. Can't remember exactly when I started with 386BSD. The Byte issues had gone to the bindery, so it was at least six months after publication.
IIRC 1.1.5.1 worked pretty well, as the last encumbered version. Am I confused? The early un-encumbered versions were somewhat rough. [encumbered meaning "contains AT&T code"]
3.0 rings a bell.
Thanks for writing,
bob prohaska
A
Ahem A Rivet's Shot
I started experimenting with 1.0 in December 1993 after having had Linux for some months (I bought SLS on a stack of floppy discs for £50 thinking that it wasn't a bad price for the floppies if it turned out to be useless). FreeBSD 1.0 was solid enough, rather more so than early Linux which had some nasty TCP/IP issues which didn't become obvious until I tried to set up a prototype dial up ISP. Early Linux was also horribly incoherently packaged - that set of floppies included source tarballs that didn't correspond to the binaries. Discovering that FreeBSD could build itself correctly was a breath of fresh air after battling Linux updates.
A lot of old timers considered 1.1.5.1 to be the most stable release until late 4.x which because of the 5.0 debacle became extremely stable as the last non SMP kernel. Yahoo! (I worked for them for a while) stuck with 4.11 until well after 6.0 came out and then started a migration to Linux.
B
bp
It just dawned on me that I was writing about FreeBSD, not RasPiOS; apologies for the confusion!
In the meantime, the Pi5 is up and running on a fresh install of Bookworm. Impressively faster than the Pi4 running Bullseye.
At this point both machines are on the same 192.168.1.y network, but they don't seem able to communicate at all, simply reporting "no route to host" from either end. Ping fails, losing all packets. It looks like sshd is running, based on ps output.
Both machines are connecting via DHCP, so the WAP is the default route for both. Do I need to do something special to use sftp between them?
Thanks for reading!
bob prohaska
T
The Natural Philosopher
Hang on a minute.
Is the WAP capable of routing?
I assumed you had a proper router somewhere doing routing and DHCP and the WAP was merely bridging to it
From where is the ssh working?b sftp IS ssh.
J
Jean-Pierre Kuypers
In article (Dans l'article) <v5crtg$153r4$ snipped-for-privacy@dont-email.me, snipped-for-privacy@www.zefox.net> wrote (écrivait) :
What about "ifconfig -a"
B
bp
I didn't think routing would be needed, since both hosts are on the same network. The Pi5 is at 192.168.1.10, the Pi4 is at 192.168.1.11 a printer at 192.168.1.250 and a Mac at 192.168.1.22
Both Pi4 and Pi5 can ping the printer sucessfully. Neither Pi can ping the other, nor the Mac. both can ping themselves using their assigned IP number. The Mac can ping the printer but neither Pi.
It works to the WAN, no problem. I don't think I've tried using ssh/sftp across the LAN until now, or at least not recently.
The Pi4 is running Bullseye, the Pi5 Bookworm.
Thanks for writing!
bob prohaska
C
Chris Townley
What netmask are using on these devices? 192.168 can be either B or C
B
bp
The Pi4, Pi5 and Mac are all using 255.255.255.0.
Could this be some sort of security feature? In a classroom environment direct communication between student workstations might be worth suppressing, especially at exam time 8-)
Thanks for writing,
bob prohaska
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required
Report Content
You are reporting this content to the moderators. They will look at it
ASAP.