Dreaming of the next Pi's features...

I like to have a very fast well specced Intel desktop for gaming and the like, but I also find that for 95% of what I do, a 'Pi Pro' as I imagine it, would suffice. Because a Pi 3 nearly manages. It comes closer than any other SBC for which I've paid $50 or less :-) I'd happily pay half again as much for my 'Pi Pro'.

I reckon the age of super cheap but still highly capable general purpose personal computers, will be a bright one. And I expect people in less developed countries will be even more enthusiastic than I for such devices.

--
If you're not part of the solution, you're part of the precipitate.

Okay, maybe not $20 for _ absolutely everything_ I desire, but I shouldn't have to pay $240 for my imagined 'Pi Pro' twice as good as a Pi 3. To oversimplify the matter, it seems reasonable to expect such a device to only be twice the price at worst. As I can already see other SBCs with 8 cores, more RAM, SATA, etc, for around twice the price of the Pi 3.

I see more powerful SBCs than the Pi 3 still happily powered by very cheap power supplies.

And I'm not saying get rid of the Pi 3. But to add a bigger brother for someone who wants a fuller experience that remains highly affordable and moddable.

--
If you're not part of the solution, you're part of the precipitate.

Again, I never suggested replacing the Pi 3. With respect, you misunderstand what I'm after and why :-)

--
If you're not part of the solution, you're part of the precipitate.

Unless Microsoft gets there first, brainwashes those people as thoroughly as they have North Americans, and renders any machine more than a year old obsolete thanks to their latest generation of bloatware.

--
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs) 
\ /  I'm really at ac.dekanfrus if you read it the right way. 
 X   Top-posted messages will probably be ignored.  See RFC1855. 
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

Yep - the RK3399 based boards have hit my personal list of required features for a replacement desktop. It's a pity that the dev boards with ubuntu support are nearly twice the price of the TV boxes - and that I'd really prefer to run FreeBSD - but the hardware is there and will no doubt be getting cheaper.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:>WIN                                      | A better way to focus the sun 
The computer obeys and wins.                |    licences available see 
You lose and Bill collects.                 |    http://www.sohara.org/

I don't know what you need the source to: the ARM-side boot process is quite simple. The file that you said was the 'kernel' in config.txt is loaded into RAM and execution is started. It's basically the Linux boot process. All the heavy lifting is done by the GPU.

This is a bit old, but gives the basic idea of the Linux-ARM boot:

(not Pi specific; device tree is now used instead of ATAGS)

For querying locations of things (eg the framebuffer), you can use the mailbox property interface:

Arguably this is more friendly to an educational OS, because the GPU does all the SoC bringup (setting up power rails, clocks, configuring memory controllers, etc). You can get started running your OS in a much more pleasant environment than traditional bare-metal SoC bringup (which typically requires JTAG to see what's going on, and lots of head scratching).

One advantage for learning is that the GPU can already drive the SD card so, if your 'kernel' includes a ramdisc image, the GPU will load it all together. That means you don't need to deal with writing an SDHCI driver until further down the line because you can either run from ramdisc or mount a USB stick as root filesystem. Though you will have to deal with USB fairly soon if you want a keyboard, unless a serial console is sufficient.

Synopsys dwcusb and SDHCI are the most complex peripherals on the Pi, that need fairly large software stacks to deal with. The GPU is mostly abstracted so the interface is a lot nicer, as long as you're not expecting

2D/3D offload.

Theo

Yes. I understand the Linux boot process. I'm simply quoting Andrew Tanenbaum, the author and still developer of Minix, who said that he chose the beaglebone for ARM development because it was more open source than the Pi. I therefore expressed a wish, and I'm not the first, that more of the Pi's drivers were open in the spirit of the subject of this thread. If you think he was wrong and that you can help, then his email is

snipped-for-privacy@gmail.com

In addition I'm not sure that it's in the spirit of Minix that there's a whole load of abstraction to a closed blob of any part of the kernel processes.

Another Dave

--
Change nospam to techie

I think perhaps you misunderstand - what I think we're saying is that your proposed machine probably isn't a member of the RPi family. RPi is based on chips designed for set-top boxes, it's firmly rooted in the embedded world. The fact it can run a full version of Linux and be used as a general purpose computing device is almost coincidental to that. It's maybe more appropriate to think of it as an Arduino with a load of extra hardware modules and the ability to run its own IDE.

RPi is based on proprietary chips, there are legitimate commercial reasons why the full implementation details are not available without an NDA. If total openness is important to you (for political/ ideological/practical reasons) then choose a product with that designed into it instead.

RK3399 - that'd be nice.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:>WIN                                      | A better way to focus the sun 
The computer obeys and wins.                |    licences available see 
You lose and Bill collects.                 |    http://www.sohara.org/

Rob Morley wrote on 7/19/2017 12:02 PM:

I believe that is what Dave said.

--

Rick C

Rob Morley wrote on 7/19/2017 11:44 AM:

I think you aren't being honest about why the rPi is so popular in its intended market. Without the ability to run a full fledged OS, access the web, download software and provide a support platform for software development, you might as well be using a microBit.

The original rPi would barely run a web browser and the rPi 3 is still no speed daemon. Wanting a bit more performance is natural for such a practical device. If it can be done without raising the cost would be a great boon! I have no doubt this will happen sooner or later.

--

Rick C

Indeed. There can be no doubt a strong reason the Pi took off is it quickly became more than just a hobby/education board. It could be a fully fledged general purpose computer with a GUI OS - if a rather slow one that cannot support too many RAM hungry processes at once.

It just needs a bit more processing power and RAM to be widely useful and stable for the multitasking the average person does :-)

--
If you're not part of the solution, you're part of the precipitate.

Fair enough, if you can only support one platform then you have to pick one. But the Pi GPU firmware is essentially similar to a PC BIOS - and people don't insist they can't use a PC unless the BIOS is open source.

I should be clearer about this: there is a high chance that almost every hardware component of any complexity you talk to has a processor of some kind inside running software - that you don't get the source to. That includes the BBB. A lot of that software is in ROM that you can't change. You communicate via a defined API - maybe that API uses registers over MMIO or I2C or whatever, but it's still an API. So it's not fair to single out the Pi with its GPU, which is essentially no different.

Now, there are projects for making fully open source SoCs - eg SiFive and lowRISC, and they (will be) great for learning platforms. Likewise there are open source FPGA systems. However today you can't buy a fully open source SoC of the Pi class.

But do I need the source code for (eg) my touch screen controller? If it gives me X, Y and number of fingers, that's probably all I need it to do. I'm not going to be booting Linux on it or mining bitcoins.

Parts of the Pi hardware have open-source drivers but not open-source documentation - which is a different problem, and I can understand that makes it less attractive. It is, unfortunately, a problem shared with a lot of other SoCs (TI are one of the better vendors in terms of documentation). If that's the reason then it's understandable.

Theo

The PC BIOS *is* open source, at least the original BIOS was accessible to anyone who bought the technical reference manual.

I don't know what "fair" means. People have said there is *less* of the BBB that is not open source. Are you disputing that fact?

Ok, but there are other platforms with less software that isn't open source, no?

I thought you were talking about the rPi, why bring your touch screen controller into it?

Your logic doesn't follow.

--

Rick C

The 2017 PC BIOS is somewhat different to the 1984 PC BIOS. The (UEFI) BIOS does a *lot* of setup, including loading CPU microcode (another closed source blob). Thinking about all those settings BIOSes allow you to tweak.

Other than a few routines to keep legacy OSes happy, I doubt there's much functionality left of the 1984 BIOS. And the 1984 functionality is basically irrelevant today.

[Some UEFI source code is available. But you can't ask Gigabyte, Dell or Asus for the code for your particular motherboard]

I'm saying that the Pi has a GPU which isn't publically documented. The BBB has a GPU which isn't publically documented. Neither SoC is open source.

The Pi uses its GPU to boot and do basic setup, the BBB doesn't. Both the Pi and BBB use ROM-ed first stage bootloaders which are closed source. The Pi's second stage bootloader is closed source (because it runs on the GPU, which is not publically documented and doesn't have an official public toolchain, so you couldn't build the firmware if it was open source), the BBB's is open source (and runs on the ARM, which is documented).

It isn't a difference in open-source-ness per se, but I understand that people want to understand the boot process. The Pi puts more behind the firmware/software interface, agreed. What I'm saying is that every system has closed source code in it: therefore any distinction is a matter of degree, not of fact.

The OP referred to closed-source blobs: every SoC has them. If you think your SoC doesn't, it's likely that you simply don't know that they are there.

Yes, some are more open than others, agreed. (subject to my comment about visibility)

It is an example of a chip I'm familiar with that runs firmware and provides an API (and one I've dealt with the firmware upload for). This is not about the Pi or BBB specifically. It's also an example where having the source is of minimal consequence: you buy the chip because it provides its API (over I2C or whatever). What you think is a single-function hardware component is actually a processor providing a service - most of the time this difference doesn't matter[1].

There are valid reasons you might want to see or change the firmware, fair enough, but you paid the money for it providing the API and if it doesn't do that it's the manufacturer's problem. I'm pointing out that some 'hardware' components are actually software but, most of the time, as far as the user is concerned it makes no difference.

The SoC is not open source, which means I can't modify it.

I don't need it to be, because the programmer is not going to modify it and fab a new chip. What they want to do is understand it.

I can do that with the transistor layout or verilog netlist, or I can do that with good documentation.

The documentation is more useful than the source code because what the programmer wants to know is the software model, not the hardware details.

The source code is useful in the case I want to find out where the documentation is lacking or incorrect, or I want to do something outside the model. But, if there's sufficient documentation, it's easier to understand what's going on from human words then low-level netlists.

In the Pi's case, the USB IP docuemntation is not public. The SDHCI controller's documentation is not public but it mostly follows a published standard. Lack of USB IP documentation /is/ a stumbling block to OS development. But it wouldn't help OS development very much to get the netlist of the USB controller (if it was open source), when what I actually want is something telling me how it works.

[typo 'open-source documentation' when I meant 'open documentation' above. The rights to modify the documentation are useful but secondary]

Theo

[1] Security is one area where the exact details of how something is constructed /do/ matter.

I don't know what you are arguing. The other poster has pointed out the rPi is less open source than other devices. Nothing you posted above mitigates that. Some people prefer working with open source software and would like to see the rPi more open. Why is this such a bee in your bonnet?

--

Rick C

It is, in part:

--
 (\_/) 
(='.'=)  "Between two evils, I always pick 
(")_(")   the one I never tried before."  - Mae West

Something (hopefully) simple: have a few (maybe 3) LEDs on the board showing the state of some of the less commonly used GPIO pins, so even a headless Pi can give some feedback on its activity.

Add an "I've shutdown, and you can safely pull the plug" LED.

--
Cheers, 
John