FPGA Internal or external USB PHY/SIE ??

On 4/5/2016 7:07 AM, Theo Markettos wrote:
> rickman <gnuarm@gmail.com> wrote:
>> What confidential info in the rPi core?  My understanding is that the
>> GPU has proprietary aspects, but the core is ARM which is fully
>> documented.  Do I not understand this properly?
>
> We're talking peripheral IP cores.  The Pi has a bunch of IP from third
> party vendors - Synopsys (USB), Arasan (SDHCI), maybe others (DDR2
> controller?).  Those are proprietary and documentation is not public.
> (though the SD core mostly obeys the SDHCI spec so is less of an issue)
>
> Any SoC is much more than the CPU, and it's the I/O where it always gets
> messy.

I thought specifically this was about using the USB port.  Are you 
saying the USB port on the rPi is not fully documented?  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.  This has been discussed widely 
about the rPi and I'm sure it would have been brought up if any other 
portions were not fully documented.

-- 

Rick

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

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)

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)
>


-- 

Rick

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

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

On 4/7/2016 6:23 AM, 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.
>
>> 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

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?

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.

All the rest are controlled by the GPU with the ARM sending commands via the
'mailbox' interface: ie there is a software API, there is no hardware
documentation.

Look for them in:
https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bcm2835/BCM2835-ARM-Peripherals.pdf
or
https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bcm2836/QA7_rev3.4.pdf
- you won't find them.

Theo

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

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

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