Theo Markettos wrote on 7/20/2017 5:18 AM:
> 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]

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

--- SoupGate-Win32 v1.05