BeagleBoard-X15 - seriously? :)

They are not. Ports 5 and 6 should be, but I have not tried counting all the pins of the McASP that are out there lately. Been a little busy.

Gerald

John Syn,
Wandboard Quad does have 64 bit memory bus.

P.S. I don't know who needs dual DSP onboard because TI definitely will not
support them as should like it was for omap3/dm37. I'd better have well
supported hardware video encoder/decoder rather than double general purpose
DSPs without any software support

When OMAP3 came out, the only compilers for C6000 were expensive,
closed-source compilers. Now, there is support in mainline GCC for
C6000. As the BeagleBoard.org community, we have to work together to
enable use of the DSPs if they are of interest to the
community---there aren't any barriers in our way.

John Syn,
Wandboard Quad does have 64 bit memory bus.

P.S. I don't know who needs dual DSP onboard because TI definitely will
not
support them as should like it was for omap3/dm37. I'd better have well
supported hardware video encoder/decoder rather than double general
purpose
DSPs without any software support

When OMAP3 came out, the only compilers for C6000 were expensive,
closed-source compilers. Now, there is support in mainline GCC for
C6000. As the BeagleBoard.org community, we have to work together to
enable use of the DSPs if they are of interest to the
community---there aren't any barriers in our way.

The TI C6000 does some amazing pipeline optimization, which seems to be
missing from the GCC compiler. Anyway, using CCSV6 is no big deal, but
support for RPMSG/REMOTEPROC on this processor is a big issue. The source
is difficult to follow and my guess is we would need input from the
original authors to do this work.

Regards,
John

Why dont we get involved in linux-omap discussions on the topic? most
of the rpmsg and remote proc discussions do take place in kernel
mailing list. usually discussing in context helps move patches forward
since it makes it clear to certain maintainers that these things are
important and help community.

Do you have anything specific that you are concerned about?

I think the biggest concern of bb.org, is that we don't end up in a
similar situation to the omap3. Where dsplink/etc never went mainline,
thus 5 years later, we still need to run the 2.6.32 psp to even
utilize the omap3's dsp.

Just the classic.. burn me once... :wink:

For the am57x, since the foundation rpmsg/remoteproc is mainline, we
should be in good shape... (fingers crossed)

Regards,

From the datasheet, it looks like the SoC does not have dual ethernet MAC’s. Instead it has an internal 3 port switch, two run off-chip to the ethernet ports and one to the SoC’s MAC. This is a bit of a disappointment as I was hoping for true dual GbE MAC’s.

John Syn,
Wandboard Quad does have 64 bit memory bus.

P.S. I don't know who needs dual DSP onboard because TI definitely
will
not
support them as should like it was for omap3/dm37. I'd better have
well
supported hardware video encoder/decoder rather than double general
purpose
DSPs without any software support

When OMAP3 came out, the only compilers for C6000 were expensive,
closed-source compilers. Now, there is support in mainline GCC for
C6000. As the BeagleBoard.org community, we have to work together to
enable use of the DSPs if they are of interest to the
community---there aren't any barriers in our way.

The TI C6000 does some amazing pipeline optimization, which seems to be
missing from the GCC compiler. Anyway, using CCSV6 is no big deal, but
support for RPMSG/REMOTEPROC on this processor is a big issue. The
source
is difficult to follow and my guess is we would need input from the
original authors to do this work.

Why dont we get involved in linux-omap discussions on the topic? most
of the rpmsg and remote proc discussions do take place in kernel
mailing list. usually discussing in context helps move patches forward
since it makes it clear to certain maintainers that these things are
important and help community.

Do you have anything specific that you are concerned about?

Looking at git.ti.com/rpmsg/rpmsg, I don¹t see any support for AM572x
processors. Also, Beagleboard-X15 is to be released with Kernel V3.18 but
I don¹t see support for this kernel versions. Last I heard, RPMSG was
working on OMAP4, but not fully implemented on OMAP5, but this was a while
ago and perhaps this has changed. Perhaps Suman can give us an update.
Similar concerns about REMOTEPROC. What I know is that I have been pushing
this issue on the beta list and the only feedback I received was that
"RPMSG/REMOTEPROC was in a SW blackhole².

Based on the TRM, this processor looks extremely attractive, and we need
RPMSG/REMOTEPROC to take advantage of the powerful dual DSPs and dual
CortexM4s.

Regards,
John

Look at the recently submited mail box subsystem.

Hi John,

John Syn,
Wandboard Quad does have 64 bit memory bus.

P.S. I don't know who needs dual DSP onboard because TI definitely
will
not
support them as should like it was for omap3/dm37. I'd better have
well
supported hardware video encoder/decoder rather than double general
purpose
DSPs without any software support

When OMAP3 came out, the only compilers for C6000 were expensive,
closed-source compilers. Now, there is support in mainline GCC for
C6000. As the BeagleBoard.org community, we have to work together to
enable use of the DSPs if they are of interest to the
community---there aren't any barriers in our way.

The TI C6000 does some amazing pipeline optimization, which seems to be
missing from the GCC compiler. Anyway, using CCSV6 is no big deal, but

One should be able to directly download the C6000 compilers at
http://software-dl.ti.com/codegen/non-esd/downloads/download.htm#C6000

support for RPMSG/REMOTEPROC on this processor is a big issue. The
source
is difficult to follow and my guess is we would need input from the
original authors to do this work.

Why dont we get involved in linux-omap discussions on the topic? most
of the rpmsg and remote proc discussions do take place in kernel
mailing list. usually discussing in context helps move patches forward
since it makes it clear to certain maintainers that these things are
important and help community.

Do you have anything specific that you are concerned about?

Looking at git.ti.com/rpmsg/rpmsg, I don¹t see any support for AM572x
processors. Also, Beagleboard-X15 is to be released with Kernel V3.18 but
I don¹t see support for this kernel versions. Last I heard, RPMSG was
working on OMAP4, but not fully implemented on OMAP5, but this was a while
ago and perhaps this has changed. Perhaps Suman can give us an update.
Similar concerns about REMOTEPROC. What I know is that I have been pushing
this issue on the beta list and the only feedback I received was that
"RPMSG/REMOTEPROC was in a SW blackhole².

The rpmsg-ti-linux-3.14.y branch in the above tree is the feature
integration branch for rpmsg/remoteproc and does support all the
processors on OMAP4, OMAP5 and AM572x/DRA7x. The AM572x support should
be present through the am57xx-beagle-x15.dts file (its been sometime
since I pulled the required platform branch with any updates to this).

I am in the process of pushing all these features/patches upstream, but
it will mostly be sometime next year before all the patches and their
dependencies will make it into the upstream kernel, so until then have
to rely on a TI tree.

regards
Suman

Hi John,

John Syn,
Wandboard Quad does have 64 bit memory bus.

P.S. I don't know who needs dual DSP onboard because TI definitely
will
not
support them as should like it was for omap3/dm37. I'd better have
well
supported hardware video encoder/decoder rather than double general
purpose
DSPs without any software support

When OMAP3 came out, the only compilers for C6000 were expensive,
closed-source compilers. Now, there is support in mainline GCC for
C6000. As the BeagleBoard.org community, we have to work together to
enable use of the DSPs if they are of interest to the
community---there aren't any barriers in our way.

The TI C6000 does some amazing pipeline optimization, which seems to
be
missing from the GCC compiler. Anyway, using CCSV6 is no big deal, but

One should be able to directly download the C6000 compilers at
http://software-dl.ti.com/codegen/non-esd/downloads/download.htm#C6000

support for RPMSG/REMOTEPROC on this processor is a big issue. The
source
is difficult to follow and my guess is we would need input from the
original authors to do this work.

Why dont we get involved in linux-omap discussions on the topic? most
of the rpmsg and remote proc discussions do take place in kernel
mailing list. usually discussing in context helps move patches forward
since it makes it clear to certain maintainers that these things are
important and help community.

Do you have anything specific that you are concerned about?

Looking at git.ti.com/rpmsg/rpmsg, I don¹t see any support for AM572x
processors. Also, Beagleboard-X15 is to be released with Kernel V3.18
but
I don¹t see support for this kernel versions. Last I heard, RPMSG was
working on OMAP4, but not fully implemented on OMAP5, but this was a
while
ago and perhaps this has changed. Perhaps Suman can give us an update.
Similar concerns about REMOTEPROC. What I know is that I have been
pushing
this issue on the beta list and the only feedback I received was that
"RPMSG/REMOTEPROC was in a SW blackhole².

The rpmsg-ti-linux-3.14.y branch in the above tree is the feature
integration branch for rpmsg/remoteproc and does support all the
processors on OMAP4, OMAP5 and AM572x/DRA7x. The AM572x support should
be present through the am57xx-beagle-x15.dts file (its been sometime
since I pulled the required platform branch with any updates to this).

I am in the process of pushing all these features/patches upstream, but
it will mostly be sometime next year before all the patches and their
dependencies will make it into the upstream kernel, so until then have
to rely on a TI tree.

Hi Suman,

That is really good news. I’m guessing that V3.18 support will occur with
the push to mainline? Any chance that we will see support when
Beagleboard-X15 launches in Feb 2015?

Regards,
John

Gerald:

The picture on
http://www.elinux.org/Beagleboard:BeagleBoard-X15
looks great.

But, I note that it does not show a heatsink or fan on the Sitara.

Is this just some “photographic license” or is this Sitara going to need
some proactive cooling?

Thanks,
— Graham

Gerald:

The picture on
http://www.elinux.org/Beagleboard:BeagleBoard-X15
looks great.

But, I note that it does not show a heatsink or fan on the Sitara.

Is this just some “photographic license” or is this Sitara going to need
some proactive cooling?

Gerald added two layers to the PCB to act as a heatsink, so no additional heatsink or fan will be necessary. At least that is the plan.

Regards,
John

TBD. We have a heatsink and a fan option

Gerald

Hi John,

John Syn,
Wandboard Quad does have 64 bit memory bus.

P.S. I don't know who needs dual DSP onboard because TI definitely
will
not
support them as should like it was for omap3/dm37. I'd better have
well
supported hardware video encoder/decoder rather than double general
purpose
DSPs without any software support

When OMAP3 came out, the only compilers for C6000 were expensive,
closed-source compilers. Now, there is support in mainline GCC for
C6000. As the BeagleBoard.org community, we have to work together to
enable use of the DSPs if they are of interest to the
community---there aren't any barriers in our way.

The TI C6000 does some amazing pipeline optimization, which seems to
be
missing from the GCC compiler. Anyway, using CCSV6 is no big deal, but

One should be able to directly download the C6000 compilers at
http://software-dl.ti.com/codegen/non-esd/downloads/download.htm#C6000

support for RPMSG/REMOTEPROC on this processor is a big issue. The
source
is difficult to follow and my guess is we would need input from the
original authors to do this work.

Why dont we get involved in linux-omap discussions on the topic? most
of the rpmsg and remote proc discussions do take place in kernel
mailing list. usually discussing in context helps move patches forward
since it makes it clear to certain maintainers that these things are
important and help community.

Do you have anything specific that you are concerned about?

Looking at git.ti.com/rpmsg/rpmsg, I don¹t see any support for AM572x
processors. Also, Beagleboard-X15 is to be released with Kernel V3.18
but
I don¹t see support for this kernel versions. Last I heard, RPMSG was
working on OMAP4, but not fully implemented on OMAP5, but this was a
while
ago and perhaps this has changed. Perhaps Suman can give us an update.
Similar concerns about REMOTEPROC. What I know is that I have been
pushing
this issue on the beta list and the only feedback I received was that
"RPMSG/REMOTEPROC was in a SW blackhole².

The rpmsg-ti-linux-3.14.y branch in the above tree is the feature
integration branch for rpmsg/remoteproc and does support all the
processors on OMAP4, OMAP5 and AM572x/DRA7x. The AM572x support should
be present through the am57xx-beagle-x15.dts file (its been sometime
since I pulled the required platform branch with any updates to this).

I am in the process of pushing all these features/patches upstream, but
it will mostly be sometime next year before all the patches and their
dependencies will make it into the upstream kernel, so until then have
to rely on a TI tree.

Hi Suman,

That is really good news. I’m guessing that V3.18 support will occur with
the push to mainline? Any chance that we will see support when
Beagleboard-X15 launches in Feb 2015?

Feb 2015 is too early to have all the remoteproc/rpmsg pieces make it to
upstream, so for now the 3.14-LTS based TI kernel is the latest where
everything is in place.

regards
Suman

Gerald:

Thanks. Let us know when you know.

As a comment, I could not find any on-die temperature sensor.

In dealing with FPGA’s and other high power chips, having a way to

directly read die temperature has helped us solve all kinds of problems.

Please pass on to TI marketing, if you get a chance.

— Graham

There are on die and onboard temperature sensors. Current boards have a heatsink only.

Gerald

There are on die and onboard temperature sensors. Current boards have a heatsink only.

Did the heatsink layers work as expected?

Regards,
John

Yes. They helped a lot. But crank everything up and it may still need some help.

Gerald

Fixing up linux-omap mailing list

Graham,
I had a quick look through the manual: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf
On page 4007 it states: “There are five temperature sensors on the device die.”