The practicality life forces on us supports this approach but I'd
welcome an open platform so I don't have fun things like Intel's IME
which practically no one can examine or fix on their own and it has had
severe failures which can completely undermine all OS level efforts to
secure a machine.
Having a single source for key components/software in your computing
solution is not a great place to be as a consumer so the more we can get
open solutions out there the better we can keep things running on the
long time scale and hopefully reduce the leverage of a particular vendor.
Michael Fulbright
On 1/15/21 12:21 PM, John Vaughters via TriEmbed wrote:
+1 for Rodney
Also, on the 10k ft. view. I am less concerned about any of the hidden details
until it affects me. Cost and performance first. Is it cheap and does it do
what I need? If not, Can I up the cost on something else? Or Should I consider
the time to dig into the ability to make the low cost device do what I need
with lower level customization. Unless I am designing anything with volume,
it's usually not a big factor. So if the Rpi has performance issues, I look to
other devices in most cases. I have found Rpi to have great value in this area
and it does alot. But there are alternatives that have obvious advantages like
my Rock64 that I use to run Mango SCADA application. But cost goes up. Also at
the time I bought it Rpi did not have 4GB mem, which I needed for this
application.
So for me the article is good, because I like to understand technology, but I
have not really run into it causing me an issue. I try what I am attempting and
if performance lags, I try something else. The cost of all these things are so
cheap compared to my time frame of computing development. I just moonshot it
with that whopping $80 Rpi. My dad bought us an Apple IIe for about $2000,
which is about $4000 equivalent today. Yea, perspective, it's a thing `,~)
John Vaughters
On Friday, January 15, 2021, 11:23:38 AM EST, Rodney Radford via TriEmbed
<[email protected]> wrote:
Personally I think the closed GPU on the Raspberry Pi gets a bad rap. Yes, the
GPU is closed source (nothing the Raspberry Pi guys can do about that as it is
not their choice),.
It is true that it is responsible for mounting the SD card and starting up
Linux, but the way I look at is that it takes the place of the BIOS and
bootloader on a standard PC system. Like the BIOS, it opens up the boot device
(SD card), loads the bootloader. The main difference is the bootloader is also
part of the GPU code so it does make it more difficult porting other systems to
it, but not impossible.
After that, the code runs on the Linux side of things with it being in control
with the GPU handling graphics, as expected, and monitoring voltages and
temperatures, with the ability to directly write to the display for battery and
heat issues.
You can modify the Linux code and you can create custom device drivers for it,
so I don't see it as a closed system any more than a PC is running Linux with a
'closed' BIOS.
On Fri, Jan 15, 2021 at 11:12 AM jonathan hunsberger via TriEmbed
<[email protected]> wrote:
Maybe not a lot of fully open options in the "sbc running Linux" category yet,
but..
BeagleV recently released on RISC-V. At $150 it's not really a RPi
replacement, but could lead to proliferation of similar solutions at lower cost.
On Thu, Jan 14, 2021 at 1:10 AM Mauricio Tavares via TriEmbed
<[email protected]> wrote:
On Sun, Dec 27, 2020 at 10:17 AM Pete Soper via TriEmbed
<[email protected]> wrote:
Here are some criticisms of RPI that this list will hopefully take as
constructive. Some good tech details that many of us may have been unaware of.
https://ownyourbits.com/2019/02/02/whats-wrong-with-the-raspberry-pi/
I was not aware of the everything-goes-through-gpu-blob aspect
of the Rpi4. What are the alternatives? I was looking at the Rock Pi,
especially the N10 for some applications, and then started wondering
if it has as much closed source stuff as the Rbpi.
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected]
List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
TriEmbed web site: http://TriEmbed.org
To unsubscribe, click link and send a blank message:
mailto:[email protected]?subject=unsubscribe
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected]
List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
TriEmbed web site: http://TriEmbed.org
To unsubscribe, click link and send a blank message:
mailto:[email protected]?subject=unsubscribe
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected]
List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
TriEmbed web site: http://TriEmbed.org
To unsubscribe, click link and send a blank message:
mailto:[email protected]?subject=unsubscribe
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected]
List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
TriEmbed web site: http://TriEmbed.org
To unsubscribe, click link and send a blank message:
mailto:[email protected]?subject=unsubscribe
