> rickman <gnuarm@gmail.com> wrote:
>>
>> What part of the CPU chip on the rPi is not documented in the manual?
>> It is large and I have not read it all of course, but I'm sure I would
>> have heard in these discussions if there were any other part than the
>> GPU that was driven by closed source code.
>
> Have you lookead at the manual at all? I have BCM2835-ARM-Peripherals.pdf
> which seem to be the only official documentation and it has 205
> pages. This is tiny compared to other chips. For example main
> i.MX6 manual from FreeScale has 5739 pages and there are additional
> smaller manuals for i.MX6.
>
> USB part in BCM manual tells you that they use Synopsys IP,
> what configuration options they use with Synopsis core and
> list registers that Broadcom added. In a sense Broadcom
> released all _their_ information, but you need to get
> Synopsys information from other source.
Yes, I looked at the manual. I think I already said I didn't read the
entire manual, so why do you even ask? I was only looking for info on
the part I was using. I don't read 205 page manuals for fun.
Seems weird that there is open source driver code for the various parts
of the chip that has no released documentation. I guess you can figure
out some aspects of how the chip is being used by looking at the driver
code, but anything not being used would still be unknown.
--
Rick
Reply by Waldek Hebisch●April 9, 20162016-04-09
rickman <gnuarm@gmail.com> wrote:
>
> What part of the CPU chip on the rPi is not documented in the manual?
> It is large and I have not read it all of course, but I'm sure I would
> have heard in these discussions if there were any other part than the
> GPU that was driven by closed source code.
Have you lookead at the manual at all? I have BCM2835-ARM-Peripherals.pdf
which seem to be the only official documentation and it has 205
pages. This is tiny compared to other chips. For example main
i.MX6 manual from FreeScale has 5739 pages and there are additional
smaller manuals for i.MX6.
USB part in BCM manual tells you that they use Synopsys IP,
what configuration options they use with Synopsis core and
list registers that Broadcom added. In a sense Broadcom
released all _their_ information, but you need to get
Synopsys information from other source.
--
Waldek Hebisch
Reply by bob prohaska●April 8, 20162016-04-08
In comp.sys.raspberry-pi rickman <gnuarm@gmail.com> wrote:
>
> I was talking about this because of the rPi and the controversy around
> the lack of source for the GPU. I thought that was the only binary code
> in the Linux package. Theo is saying that even though there are source
> codes for various other pieces of the chip, the pieces are not actually
> documented. That surprises me. But it's not the first time I've been
> surprised. :)
>
Not so long ago there was a much-ballyhoo'd "release" of GPU documentation
and a "contest" to use the GPU. The implication seemed to be that we'd
see a GPU-accelerated X server in the not-too-distant future.
Was that entirely of smoke and mirrors?
Thanks for reading,
bob prohaska
Reply by rickman●April 7, 20162016-04-07
On 4/7/2016 7:26 PM, KJ wrote:
> On Thursday, April 7, 2016 at 5:25:04 PM UTC-4, Theo Markettos wrote:
>> In comp.arch.fpga rickman wrote:
>>> I find it hard to believe the cache and memory controller are not fully
>>> documented for example. Is the USB core only supported with a binary
>>> core? How about the clock generator? You are saying there is source
>>> code, but no documentation?
>>
>> You can find it hard to believe if you like. To repeat myself, in the USB
>> case the driver is open source but documentation of the hardware is not. In
>> the SDHCI case the core is based on a standard but the documentation for the
>> specific IP core is not available.
>>
> Another example is the Texas Instruments AM3352 processor. That part has a freely available ~5000 page technical reference manual that lists all of the myriad registers for all of the various subsystems (such as the two USB cores) as well as the bit fields within the registers, but many of those fields are totally undefined as to their function. TI supplies an RTOS as well as Linux for the device. Unless you reverse engineer to create your own documentation, using the OS is the only way to use that device.
>
> Unfortunately, I don't think undocumented hardware that is only supported at the software device driver level is that uncommon. Obviously 'someone' would have to have the hardware documentation in order to write the device driver(s), but that can be taken care of without divulging the documentation outside of the company's control by writing and owning the device driver code or contracting out the work only under NDA.
I was talking about this because of the rPi and the controversy around
the lack of source for the GPU. I thought that was the only binary code
in the Linux package. Theo is saying that even though there are source
codes for various other pieces of the chip, the pieces are not actually
documented. That surprises me. But it's not the first time I've been
surprised. :)
BTW, I apologize to Theo if I sounded a bit stiff about this. I just
don't like to fully believe something if there is doubt. But now that I
have heard this from several people, I guess I should believe it.
--
Rick
Reply by KJ●April 7, 20162016-04-07
On Thursday, April 7, 2016 at 5:25:04 PM UTC-4, Theo Markettos wrote:
> In comp.arch.fpga rickman wrote:
> > I find it hard to believe the cache and memory controller are not fully
> > documented for example. Is the USB core only supported with a binary
> > core? How about the clock generator? You are saying there is source
> > code, but no documentation?
>
> You can find it hard to believe if you like. To repeat myself, in the USB
> case the driver is open source but documentation of the hardware is not. In
> the SDHCI case the core is based on a standard but the documentation for the
> specific IP core is not available.
>
Another example is the Texas Instruments AM3352 processor. That part has a freely available ~5000 page technical reference manual that lists all of the myriad registers for all of the various subsystems (such as the two USB cores) as well as the bit fields within the registers, but many of those fields are totally undefined as to their function. TI supplies an RTOS as well as Linux for the device. Unless you reverse engineer to create your own documentation, using the OS is the only way to use that device.
Unfortunately, I don't think undocumented hardware that is only supported at the software device driver level is that uncommon. Obviously 'someone' would have to have the hardware documentation in order to write the device driver(s), but that can be taken care of without divulging the documentation outside of the company's control by writing and owning the device driver code or contracting out the work only under NDA.
Kevin Jennings
Reply by Theo Markettos●April 7, 20162016-04-07
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:
> On 4/7/2016 6:23 AM, Theo Markettos wrote:
[On the undocumented parts of the Raspberry Pi]
> > There is no 'CPU chip', it's a system on chip, ie a paste together of
> > silicon and HDL IP from different vendors. Off the top of my head:
> >
> > 'The GPU':
> > The VideoCore GPU 'scalar/vector' processor (VPU)
> > The VideoCore GPU 'shader' processors (QPU)
> > The graphics pipeline (DMA, DAC, HDMI tranceiver, etc)
> > The DSI display output
> > The imaging pipeline (CSI, camera hardware)
> > Hardware encoders/decoders
> > Cache internals and memory controller
> > The Syonpsys USB core
> > The Arasan SDHCI core (any differences from the standard SDHCI)
> > Internal power control
> > Internal clock generation
> > Internal resets (if any, I'm unclear)
> >
> > There are probably other bits.
>
> Which of these bits are not fully documented (by "not fully" I mean as
> fully as digital logic is ever documented). I know the GPU is
> proprietary and only supported by an closed source binary module.
All of them.
> I find it hard to believe the cache and memory controller are not fully
> documented for example. Is the USB core only supported with a binary
> core? How about the clock generator? You are saying there is source
> code, but no documentation?
> rickman <gnuarm@gmail.com> wrote:
>>
>> The issue was open source software. The drivers for the GPU were
>> binary. If the drives for any other part of the chip were binary I'm
>> sure it would have come up.
>
> Many-KLOC drivers are not the same as documentation, even if they're open
> source.
>
> You'll find many many SOCs where source code is available but documentation
> is not. Most Android phones for example. The OSS people moan about binary
> blobs, they do not moan that about undocumented hardware or hardware that is
> unusable without the vendor-provided OSS driver. That driver keeps the
> Linux OSS folks happy, but is not helpful if you want to write your own
> driver (for an OS that isn't Linux, for example).
>
> The moral of the story is that a lot of the debate about OSS is framed by
> software people with a very strong Linux focus. They aren't hardware
> engineers. It may have OSS but not be open hardware - indeed most devices
> that run Linux aren't open hardware.
>
>> What part of the CPU chip on the rPi is not documented in the manual?
>> It is large and I have not read it all of course, but I'm sure I would
>> have heard in these discussions if there were any other part than the
>> GPU that was driven by closed source code.
>
> There is no 'CPU chip', it's a system on chip, ie a paste together of
> silicon and HDL IP from different vendors. Off the top of my head:
>
> 'The GPU':
> The VideoCore GPU 'scalar/vector' processor (VPU)
> The VideoCore GPU 'shader' processors (QPU)
> The graphics pipeline (DMA, DAC, HDMI tranceiver, etc)
> The DSI display output
> The imaging pipeline (CSI, camera hardware)
> Hardware encoders/decoders
> Cache internals and memory controller
> The Syonpsys USB core
> The Arasan SDHCI core (any differences from the standard SDHCI)
> Internal power control
> Internal clock generation
> Internal resets (if any, I'm unclear)
>
> There are probably other bits.
Which of these bits are not fully documented (by "not fully" I mean as
fully as digital logic is ever documented). I know the GPU is
proprietary and only supported by an closed source binary module.
I find it hard to believe the cache and memory controller are not fully
documented for example. Is the USB core only supported with a binary
core? How about the clock generator? You are saying there is source
code, but no documentation?
--
Rick
Reply by Les Cargill●April 7, 20162016-04-07
Theo Markettos wrote:
> rickman <gnuarm@gmail.com> wrote:
>>
>> The issue was open source software. The drivers for the GPU were
>> binary. If the drives for any other part of the chip were binary I'm
>> sure it would have come up.
>
> Many-KLOC drivers are not the same as documentation, even if they're open
> source.
>
> You'll find many many SOCs where source code is available but documentation
> is not. Most Android phones for example. The OSS people moan about binary
> blobs, they do not moan that about undocumented hardware or hardware that is
> unusable without the vendor-provided OSS driver. That driver keeps the
> Linux OSS folks happy, but is not helpful if you want to write your own
> driver (for an OS that isn't Linux, for example).
>
> The moral of the story is that a lot of the debate about OSS is framed by
> software people with a very strong Linux focus. They aren't hardware
> engineers. It may have OSS but not be open hardware - indeed most devices
> that run Linux aren't open hardware.
>
The Linux people aren't that happy about it but the experience with
graphics cards has led to acceptance of this.
Linus is on record as saying all drivers should trigger a full on GPL
cascade - that all drivers, and any* other code that runs in kernel
mode is part of the kernel ( which is true from a support/accountability
perspective ).
*or something...
But graphics card makers have set the standards and practices. The
OSS folk made their peace with the Philistines.
The problem then becomes - you may hear from
corporate counsel that the drivers for your FPGA may be a
GPL liability.
It's a bit more unsettling that say, an Allwinner A20 requires
a blob. My understanding is that this is an extension
of the same principle but because those SOICs are not available
with seperable graphics cards,
The generation that remembers what happens when all hardware is
proprietary is going into the sunset. And phone makers re at
least attempting to exploit this. Pure IP
ploys rarely work out, however.
>> What part of the CPU chip on the rPi is not documented in the manual?
>> It is large and I have not read it all of course, but I'm sure I would
>> have heard in these discussions if there were any other part than the
>> GPU that was driven by closed source code.
>
> There is no 'CPU chip', it's a system on chip, ie a paste together of
> silicon and HDL IP from different vendors. Off the top of my head:
>
> 'The GPU':
> The VideoCore GPU 'scalar/vector' processor (VPU)
> The VideoCore GPU 'shader' processors (QPU)
> The graphics pipeline (DMA, DAC, HDMI tranceiver, etc)
> The DSI display output
> The imaging pipeline (CSI, camera hardware)
> Hardware encoders/decoders
> Cache internals and memory controller
> The Syonpsys USB core
> The Arasan SDHCI core (any differences from the standard SDHCI)
> Internal power control
> Internal clock generation
> Internal resets (if any, I'm unclear)
>
> There are probably other bits.
>
> Theo
>
--
Les Cargill
Reply by Theo Markettos●April 7, 20162016-04-07
rickman <gnuarm@gmail.com> wrote:
>
> The issue was open source software. The drivers for the GPU were
> binary. If the drives for any other part of the chip were binary I'm
> sure it would have come up.
Many-KLOC drivers are not the same as documentation, even if they're open
source.
You'll find many many SOCs where source code is available but documentation
is not. Most Android phones for example. The OSS people moan about binary
blobs, they do not moan that about undocumented hardware or hardware that is
unusable without the vendor-provided OSS driver. That driver keeps the
Linux OSS folks happy, but is not helpful if you want to write your own
driver (for an OS that isn't Linux, for example).
The moral of the story is that a lot of the debate about OSS is framed by
software people with a very strong Linux focus. They aren't hardware
engineers. It may have OSS but not be open hardware - indeed most devices
that run Linux aren't open hardware.
> What part of the CPU chip on the rPi is not documented in the manual?
> It is large and I have not read it all of course, but I'm sure I would
> have heard in these discussions if there were any other part than the
> GPU that was driven by closed source code.
There is no 'CPU chip', it's a system on chip, ie a paste together of
silicon and HDL IP from different vendors. Off the top of my head:
'The GPU':
The VideoCore GPU 'scalar/vector' processor (VPU)
The VideoCore GPU 'shader' processors (QPU)
The graphics pipeline (DMA, DAC, HDMI tranceiver, etc)
The DSI display output
The imaging pipeline (CSI, camera hardware)
Hardware encoders/decoders
Cache internals and memory controller
The Syonpsys USB core
The Arasan SDHCI core (any differences from the standard SDHCI)
Internal power control
Internal clock generation
Internal resets (if any, I'm unclear)
There are probably other bits.
Theo
Reply by rickman●April 5, 20162016-04-05
On 4/5/2016 4:06 PM, Theo Markettos wrote:
> rickman <gnuarm@gmail.com> wrote:
>> I thought specifically this was about using the USB port. Are you
>> saying the USB port on the rPi is not fully documented?
>
> Yes. (Not publically anyway)
>
>> Like I said, my understanding is that the only portion of the rPi
>> processor (the original rPi, I haven't discussed the new rPi 2 or 3
>> processors with anyone) that is not fully documented (that means as well
>> as anyone ever documents complex cores) is the GPU.
>
> That is incorrect. This is a misapprehension because most people are
> running Linux, and Linux has drivers for these peripherals, so they don't
> care. It only comes to bite you when you want to write drivers for an OS
> (or lack of OS) that isn't Linux.
The issue was open source software. The drivers for the GPU were
binary. If the drives for any other part of the chip were binary I'm
sure it would have come up.
> The situation with the Pi is actually somewhat better than that because a)
> the Arasan core is (more or less) SDHCI, which is a documented standard even
> if this particular core isn't. The next usual problem then relates to
> clocks, resets and power control which are frequently controlled external
> to an IP core (so not in its documentation), quite often by a pile of GPIOs
> in a dark corner. In this case the GPU handles those so we just use its API
> (config.txt or mailbox) and don't have to worry. But it's not the same as
> understanding what it's doing inside.
What part of the CPU chip on the rPi is not documented in the manual?
It is large and I have not read it all of course, but I'm sure I would
have heard in these discussions if there were any other part than the
GPU that was driven by closed source code.
> Theo
> (who notes that ability to cut and paste random IP into an SoC frequently
> makes for a mess that software people have to deal with)
>