rickman  wrote:
> Theo Markettos wrote on 7/19/2017 6:50 PM:
> > 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.
>
> The PC BIOS *is* open source, at least the original BIOS was accessible to
> anyone who bought the technical reference manual.

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 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.
>
> 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?

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.

> > 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.
>
> Ok, but there are other platforms with less software that isn't open
> source, no?

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

> > 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.
>
> I thought you were talking about the rPi, why bring your touch screen
> controller into it?

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.

> > 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.
>
> Your logic doesn't follow.

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.

--- SoupGate-Win32 v1.05