Boring to use Linux, When BSD is up on Pyra and Pandora?


openbsd98324

Still Fresh
Joined
Jan 7, 2022
Messages
60
Hello,

That would be really cool to use BSD on the Pyra and Pandora. BSD is very powerful system.

When will you manage to port BSD to run on Pyra and Pandora?

Kind regards,
James
 
Sure it's possible, but likely you will have to do the work entirely on your own. The Pandora may be a possibility as there was some support for the OMAP3 processor in the past. However the Pyra, It would be very unlikely to have support, the SoC just isn't used anywhere outside the Pyra and Linux support is shaky at best for the OMAP5, let alone BSD.

Even on the Pandora it may support the SoC, but I doubt out of the box it will work smoothly as there are some Pandora specific hardware considerations that have to be reckoned with.
 
craig to do it? they made an opensource hardware, it is their job to do their hardware "open".
 
craig to do it? they made an opensource hardware, it is their job to do their hardware "open".
No, it's the community of users here that volunteered and developed the software for the Pandora and Pyra. Craig had nothing to do with it outside of helping kick off the production of the Pandora and gave us a platform to work on. Also Craig (Craigix) hasn't been in the community for over 10 years, he quit when only a handful of Pandoras have been shipped, basically flaked out leaving customers stranded without the Pandoras they paid for. EvilDragon took over production and delivered the rest of the units, thanks to him we have the community we have today and the Pandora blossomed into a really nice niche gaming device. But EvilDragon only produces these devices, he doesn't directly make all the software for it, it's up to volunteers to make the software/OS work.

Bottom line there is likely not enough interest in the rest of the community to do make a BSD port, so it's pretty much if you want it, do it yourself, maybe others might be interested, but it will be a tough road to get BSD working.
 
Last edited:
No, it's the community of users here that volunteered and developed the software for the Pandora and Pyra. Craig had nothing to do with it outside of helping kick off the production of the Pandora and gave us a platform to work on. Also Craig (Craigix) hasn't been in the community for over 10 years, he quit when only a handful of Pandoras have been shipped, basically flaked out leaving customers stranded without the Pandoras they paid for. EvilDragon took over production and delivered the rest of the units, thanks to him we have the community we have today and the Pandora blossomed into a really nice niche gaming device. But EvilDragon only produces these devices, he doesn't directly make all the software for it, it's up to volunteers to make the software/OS work.

Bottom line there is likely not enough interest in the rest of the community to do make a BSD port, so it's pretty much if you want it, do it yourself, maybe others might be interested, but it will be a tough road to get BSD working.

well, if they have made a locked down hardware, to avoid people to use the wide use of opensource OS-software. the boot should be done alike raspberry pi, to not have need of autoboot.txt.

there are closed source in linux kernel, the wifi of the device is Texas TI = closed source. well, broadcom isnt better. the "closed-source hardware industry" sucks.
 
well, if they have made a locked down hardware, to avoid people to use the wide use of opensource software. the boot should be done alike raspberry pi, to not have need of autoboot.txt.

there are closed source in linux kernel, the wifi of the device is Texas TI = closed source.
No all the Kernel sources are open, you can run the mainline Linux kernel on the Pandora and Pyra, not everything is working yet on the Pyra as it's a SoC that was discontinued by Ti shortly after it was released, but not before we bought a bunch for the Pyra... There is still active development for the OMAP5, but it's slow as we don't have Ti's official support on it.
There are of course some hardware like the SGX and such that require propriatary binary blobs, but it's just a matter of copying them over to get the hardware to work

Does any of this automagically gets BSD running?, No it does not...


6bsf7p.jpg
 
Last edited:
No all the Kernel sources are open, you can run the mainline Linux kernel on the Pandora and Pyra, not everything is working yet on the Pyra as it's a SoC that was discontinued by Ti shortly after it was released, but not before we bought a bunch for the Pyra... There is still active development for the OMAP5, but it's slow as we don't have Ti's official support on it.
There are of course some hardware like the SGX and such that require propriatary binary blobs, but it's just a matter of copying them over to get the hardware to work

Does any of this automagically gets BSD running?, No it does not...


View attachment 37955

try Linux, Wayland, Systemd,... you will see. Linux going south. BSD not.
 
the boot should be done alike raspberry pi, to not have need of autoboot.txt.
You do realize that the Raspberry Pi SoC is a GPU with an attached CPU and not the other way 'round? The entire boot process depends on a proprietary GPU firmware, without it the CPU is completely incapable of booting anything. Things get especially complicated if you take a closer look at the interrupt controller - the CPU does not have any, all interrupts are just proxy'd by the GPU's interrupt controller to the CPU, it's seriously messy to handle. The original chip was developed for video recorders, the Raspberry Pi guys just grabbed it for being cheap. Pretty much all successors just upgraded the CPU cores while keeping everything else just as it was.
 
Last edited:
MacOS is my favorite flavor of BSD. ;)
MacOS kernel is called "Darwin" or "XNU" and is open source.
There was a port to the BeagleBoard (OMAP3 which is the same processor as the Pandora) long time ago but not updated to later releases.
It is somewhere on github waiting for volunteers...
 
You do realize that the Raspberry Pi SoC is a GPU with an attached CPU and not the other way 'round? The entire boot process depends on a proprietary GPU firmware, without it the CPU is completely incapable of booting anything. Things get especially complicated if you take a closer look at the interrupt controller - the CPU does not have any, all interrupts are just proxy'd by the GPU's interrupt controller to the CPU, it's seriously messy to handle. The original chip was developed for video recorders, the Raspberry Pi guys just grabbed it for being cheap. Pretty much all successors just upgraded the CPU cores while keeping everything else just as it was.

I am afraid it is very likely there was worse reason. Having biggest SBC market captured, with propietary firmware controlled by the same controlling Intel or AMD SOC. All it's about who can control your hardware without you knowing or being able to stop it.

Even SOC was not only cheap but on some point free on intelectual property. So there is a lot of interest they use that SOC with propietary firmware.
Post automatically merged:

Risc OS for the future!

No RISC-V, no future. RISC OS is late.
 
I am afraid it is very likely there was worse reason. Having biggest SBC market captured, with propietary firmware controlled by the same controlling Intel or AMD SOC. All it's about who can control your hardware without you knowing or being able to stop it.
The RPi along with a lot of other SBC's use a processor running ARM cores. in the case of the RPi series the processor is made by Broadcom.
 
Having biggest SBC market captured
That would imply that a mainstream SBC market worth of that name even existed before the RPi. The SBC market was extremely niche and industry-oriented, most of the stuff on the market wasn't even available publicly. Aside from providing a fairly standard desktop Linux distro, being effectively a video recorder with a network connection and without an enforced proprietary OS was the only reason it even managed to dominate the market. The hardware video de- and encoding cabalitities were pretty much the backbone of every single popular use-case of the first generation.

Look at the SheevaPlug to get an idea what kind of SBCs were available before the RPi. Even at the time when it was being sold the hardware was horribly outdated, lacking any video output whatsoever and twice as expensive as the first RPi board. I still have a defect Seagate FreeAgent device with a custom Debian lying around, which uses the same SoC, was much cheaper in a special offer and could be flashed with a different OS if you used the leaked/hacked default SSH account in an isolated network to avoid automatic updates on its first use.

For Broadcom it's just a cash-cow, just large enough to put a bit of effort into developing slightly modified derivates of the original chip, exploiting the already available licenses in Broadcom's portfolio of newer ARM designs. They don't sell nearly enough of these boards for the RPi guys to be able to even demand more than that. They don't give a damn about the whole firmware issue, it's how it started and that's how it will stay simply because the income does not justify any investment in this direction. As far as Broadcom's sales go, even the RPi is just a niche, industry customers buy a LOT more chips from them to actually care about it.
 
Last edited:
The Sheevaplug wasn't an SBC, I'd expect inside that shell at the very least the power supply would be on a different borad, and maybe RAM as well, I couldn't say. It was part of the category called plug computers. Now that category died pretty much as soon as the first RPi came out indicating they they were filling the same niche, before it expanded into the retrogaming niche and on from there.
 
Back
Top