OSD 3
Joe Born
reaction. That being said, given what we've learned from our past
history, I know that there's a window of opportunity on this that we
should seize. We simply can't wait until the OSD 2 is done or this
window will be gone. We need to start early so that we can influence
the direction of the device and software at an early stage.
Had we been involved sooner in the process with the OSD2, I'm certain
we could have helped to ensure a mainline kernel, etc. I've been
personally involved in the discussions with TI and believe their
enthusiasm and commitment is real. In fact, we are actively involved
in ongoing discussions, which, quite frankly, they are driving. It
may be a long way away from a consumer product, but now's the time
that the resources and enthusiasm are at a peak and we can have the
most impact.
http://forums.neurostechnology.com/index.php?topic=10248.0 is the
forum post describing the high level outline.
Joe
Daniel Díaz
On Wed, Jul 15, 2009 at 3:58 PM, Joe Born<jb...@neurostechnology.com> wrote:
[...]
> Had we been involved sooner in the process with the OSD2, I'm certain
> we could have helped to ensure a mainline kernel, etc. I've been
> personally involved in the discussions with TI and believe their
> enthusiasm and commitment is real. In fact, we are actively involved
> in ongoing discussions, which, quite frankly, they are driving. It
> may be a long way away from a consumer product, but now's the time
> that the resources and enthusiasm are at a peak and we can have the
> most impact.
>
> http://forums.neurostechnology.com/index.php?topic=10248.0 is the
> forum post describing the high level outline.
I'm not big on forums, so here you have my thoughts.
First of all, I truly believe you need (and have needed) something
capable of 1080p for the near future needs, and I'm totally in favor
of OSD3 even though I bought my OSD2 not long ago.
Do you not get the feeling that leveraging the existing support for
the OMAP3530 (as with the Beagle) would have helped the OSD2 a great
deal? I cannot help but thinking that way, because Linux (not forks,
but mainline kernel) is accepting more and more patches for it. There
are a lot of interests in getting OMAP3 support in the kernel from
several companies, not just TI. For instance, the DSP Bridge is much
more aligned with (and thus closer to be included in) mainline kernel
than is DSP Link, even though there's still a long way to go.
In general, I get the feeling the OMAP3 is more supported than
DaVinci, but then again you have to take this from somebody who is
biased and hasn't played at all with DaVinci devices (the OSD2 is my
first, and I have yet to unbox it).
Greetings!
Daniel Díaz
dd...@ti.com
Steven Robertson
> I send this out with mixed feelings since I can anticipate some of the
> reaction. That being said, given what we've learned from our past
> history, I know that there's a window of opportunity on this that we
> should seize. We simply can't wait until the OSD 2 is done or this
> window will be gone. We need to start early so that we can influence
> the direction of the device and software at an early stage.
The chance for an open source product vendor to strongly collaborate
with a major embedded microprocessor company this early in the design
stage is rare. Open platforms, both on the whole and in Neuros'
history, have been held back by hardware and driver constraints that
lie outside of the control of hackers. The partnership between Neuros
and TI on the OSD3 hardware is a chance to eliminate those roadblocks
and create a platform where real innovation can happen, and I believe
that it deserves the attention of both Neuros and its community.
I'm excited to see where the OSD3 can go, and I am looking forward to
helping it get there.
Steven (who will be returning from Closed Platform HQ in four weeks or so)
Vladimir Pantelic
> http://forums.neurostechnology.com/index.php?topic=10248.0 is the
> forum post describing the high level outline.
Sure, why not, sounds fun and the logical thing to do.
But at the same time, I conclude that doing an "open source" HW product
does not work. It somehow only becomes feasible if there is a large entity
behind, in this case TI driving (as you say) both the HW platform and the SW
(TI opens source efforts, I know them well and I know they are huge atm)
With stuff like MythTV or XMBC almost running OK on the beagleboard, I am
sure they will run fine on the next HW (OMAP4?), Adobe is porting Flash10
to ARM and webkit has widespread ARM use and optimization, so what is left
for Neuros to do? ;-)
Ramakrishnan Muthukrishnan
>
> Had we been involved sooner in the process with the OSD2, I'm certain
> we could have helped to ensure a mainline kernel, etc. I've been
I have posted my comments in the forum.
I believe OSD2 has its own place in the market as a cheaper product.
Most of the world still has standard definition and it fills the gap
as a nice recording/playback device for the living room.
--
Ramakrishnan
Joe Born
> With stuff like MythTV or XMBC almost running OK on the beagleboard, I am
> sure they will run fine on the next HW (OMAP4?), Adobe is porting Flash10
> to ARM and webkit has widespread ARM use and optimization, so what is left
> for Neuros to do? ;-)
I can only pray we'll find ourselves asking that question! In fact,
I've come to the conclusion that our success depends on that being the
question we ask ourselves. It's because its the details where success
is had or lost. It's not enough to slap xbmc or myth on there and
call it done, just read the forums on the LINK if you need proof of
that. We have to tweak, configure, integrate and refine a whole host
of little details to make the device work seamlessly for an audience
of real users. Then theres all the stuff associated with the physical
device from the case and configuration to the controller, etc. To be
frank, at this point if there's much more to do to make this device
work than the LINK, I wouldn't be very interested. Dealing with this
low level stuff is a formula for getting embroiled a bunch of things
we shouldn't be.
Vladimir Pantelic
> On Thu, Jul 16, 2009 at 3:10 AM, Vladimir Pantelic<vlad...@gmail.com> wrote:
>
>> With stuff like MythTV or XMBC almost running OK on the beagleboard, I am
>> sure they will run fine on the next HW (OMAP4?), Adobe is porting Flash10
>> to ARM and webkit has widespread ARM use and optimization, so what is left
>> for Neuros to do? ;-)
> To be
> frank, at this point if there's much more to do to make this device
> work than the LINK, I wouldn't be very interested. Dealing with this
> low level stuff is a formula for getting embroiled a bunch of things
> we shouldn't be.
which confirms my statement that doing open source HW is a fail.
what you list above is the same work that you need for the LINK, so
the actual HW platform is not the real issue, it is a pure SW task
in the end, no?
Joe Born
> Most of the world still has standard definition and it fills the gap
> as a nice recording/playback device for the living room.
no question about it. I wish it were further along software wise.
Vladimir Pantelic
actually, that was unclear. The HW platform is of course an issue,
but now you assume it available and capable and just concentrate on
the SW side - which is of course fine and understandable.
John Wu
however you stand on a developer position. I think for normal consumer only talk about SW or HW
do not make sense. OSD is a product, so make a product need do the task that make the SW and
HW combine perfectly and easy to use.
Joe Born
> Hi, Vladimir. I think you do not stand on the same position with Joe, he
> stand on a consumer position,
> however you stand on a developer position. I think for normal consumer only
> talk about SW or HW
> do not make sense. OSD is a product, so make a product need do the task that
> make the SW and
> HW combine perfectly and easy to use.
Yes, this is what I mean. I have no problem "finishing the hardware"
if that finishing makes creating a great controller etc or other
"trivial details" that are vitally important and possible to
differentiate on. I have no problem "finishing the software" if that
finishing means tweaking the UI and integration that makes the
software intuitive and enjoyable to use, etc.
Joe Born
> but now you assume it available and capable and just concentrate on
> the SW side - which is of course fine and understandable.
Right, I think it makes a lot more sense for TI to be doing that HW
integration work because all those investments will payoff with
silicon sales and can be leveraged against multiple products. For
fundamental stuff that's usable across a broad platform of products,
investments from TI just make more sense than Neuros for a bunch of
obvious reasons.
Joe
Michael Gao
Well, the subject of this thread is OSD 3, IMHO where the 'much more'
comes from also tightly ties to how OSD 3 is defined. For one example,
if OSD 3 is defined to play _all_ (or most) media formats _and_ supports
browser flash contents, spending time to deal with low level stuff on a
TI platform is doomed (as of today). On the other hand, if it is crucial
to support Video recording with a given set of video format playback
_and_ the goal is to deliver a silent living room box, I'd think the x86
platform might be somewhat un-tweakable. ;-).
/MG
Joe Born
> Well, the subject of this thread is OSD 3, IMHO where the 'much more'
> comes from also tightly ties to how OSD 3 is defined. For one example,
> if OSD 3 is defined to play _all_ (or most) media formats _and_ supports
> browser flash contents, spending time to deal with low level stuff on a
> TI platform is doomed (as of today). On the other hand, if it is crucial
> to support Video recording with a given set of video format playback
> _and_ the goal is to deliver a silent living room box, I'd think the x86
> platform might be somewhat un-tweakable. ;-).
Can you expand on this? I'm sure you've been following beagleboard
and such, why do you feel that broad "x86 level" broad playback is
doomed with the Netra chips?
Personally, while I feel that recording is a very nice compliment to a
box like this, I can't see building a dvr. Between Tivo and the
operator boxes, I don't see it as an attractive place to compete. The
market of folks that care enough to have unlocked recordings (and are
willing to sacrifice so many of the tivo niceties) is just too small.
I'm vastly more interested in a net tv box (ideally one that can also
record)
Michael Gao
> >
> > Well, the subject of this thread is OSD 3, IMHO where the 'much more'
> > comes from also tightly ties to how OSD 3 is defined. For one example,
> > if OSD 3 is defined to play _all_ (or most) media formats _and_ supports
> > browser flash contents, spending time to deal with low level stuff on a
> > TI platform is doomed (as of today). On the other hand, if it is crucial
> > to support Video recording with a given set of video format playback
> > _and_ the goal is to deliver a silent living room box, I'd think the x86
> > platform might be somewhat un-tweakable. ;-).
>
> Can you expand on this? I'm sure you've been following beagleboard
> and such, why do you feel that broad "x86 level" broad playback is
> doomed with the Netra chips?
'doomed' as of today, to name just a few,
- codec availability: PC supports all, and even for those strictly
proprietary, you can find free download binaries for your personal use.
TI supports only a subset.
- sw stack: PC has fully functional multimedia framework, TI has none on
Davinci side and some on OMAP (the OpenMAX + gstreamer).
- hackability: PC supports all (or hackers have figured out all), TI
platform is just beginning to get popularity, and the dual core
architecture makes the hacking a bit too hard.
These issues should really be TI's target to resolve, thus leaving
Neuros or any other product manufactures to tackle the product details.
IMHO, as of today, TI platform is just not the right candidate for broad
'x86' level playback. In the future, may well be, depending on the SW
readiness.
> Personally, while I feel that recording is a very nice compliment to a
> box like this, I can't see building a dvr. Between Tivo and the
> operator boxes, I don't see it as an attractive place to compete. The
> market of folks that care enough to have unlocked recordings (and are
> willing to sacrifice so many of the tivo niceties) is just too small.
> I'm vastly more interested in a net tv box (ideally one that can also
> record)
On the other hand, 'net tv box' does not have to mean broad playback
support. For example, if majority of the internet contents are H264 +
VPx based, and assuming both codecs are available from TI. TI platform
may be a better solution than x86, considering the recording capability,
the fan-less etc.
If the goal is to 'play all you can get from net on your TV', x86 is the
answer.
/MG
Porro
In fact I'm rather disappointed with Ti and their Linux kernel
developers. Everything is in constant movement. I don't understand
them at all (apparently this is why there was a quarrell between them
and Solarise developers, now I understand Solaris developers much
better, unfortunately technically inferior products tend to win).
I wanted to take part in Neuros development, I purchased OSD 2.0
board, I have will, skills and time to do it, but the overall Ti
products picture looks to me extremely bad.
When I say I want to take part in development it doesn't mean that I
want to tackle with all their proprietory drivers every time they make
kernel modification.
Yes, basic kernel works fine if you want serial port console to play
with a green screen. But, Good Lord, this is not what Davinci is
invented for (or it is?)
Why cmem driver, ir, rtc, dsplink drivers are not a part of the kernel
main line? Why I have to watch Ti developers each time they jump to
new kernel revision?
In fact I don't see any need for this jumping at all. I thought
business has to have a target, but in this case Ti developers target
the move itself - i.e. absolutely useless to end customers and
partners. I don't care what nice features they impelement in kernel io
scheduler - I want all the periferials devices work and be stable. The
worst is that they fix bugs in future kernel revisions leaving old
versions unfixed.
Nevertheless:
Positives:
- the latest Ti kernel works on OSD 2.0
- cmem driver seems work
- IDE seems work
Negatives:
- after Linux kernel developers again changed all the specifications
about kernel parts interoperability neither leds, not ir work. And
there is no description of hardware for this part. 2.6.23 drivers are
absolutely useless in 2.6.31.
- framebuffer doesn't work
- codecs don't also
I tend to agree with Michael, if everything will go this way technical
superiority won't help Ti. Their products will die as many other x86
rivals.
If we have spoken about OSD 3.0 I would vote for low power mobile
version of x86 as a platform with standard periferials.
A
Vladimir Pantelic
> On the other hand, 'net tv box' does not have to mean broad playback
> support. For example, if majority of the internet contents are H264 +
> VPx based, and assuming both codecs are available from TI. TI platform
> may be a better solution than x86, considering the recording capability,
> the fan-less etc.
what is this constant mantra here that x86 cannot "record" about?
Fernando Cassia
> In fact I'm rather disappointed with Ti and their Linux kernel
> developers. Everything is in constant movement. I don't understand
> them at all
It is the TI programmers' job to move their changes "upstream" so
those are incorporated in the Kernel.
> scheduler - I want all the periferials devices work and be stable. The
> worst is that they fix bugs in future kernel revisions leaving old
> versions unfixed.
Again, it's TI programmers job to "backport" any new kernel features
to their older kernel.
Fedora 11 uses some features of the 2.6.30.x kernels, yet continues
using 2.6.29, with those features backported.
Ideally, TI should NOT suggest or deploy any "frozen" kernel version.
They should just send any changes upstream and the end-user should be
able to download the latest greatest kernel from kernel.org and
compile, and get a functional box.
So, instead of fumbling about it, why doesn't someone at Neuros writes
a polite but strong message to TI's Linux development manager and asks
about these issues?
FC
Koen Kooi
> They should just send any changes upstream
accepted on the first try. If you look at the dm3xx and daxx efforts
you can see that going from patches -> review -> kevin -> linus will
take at least 6 months due to the kernel release cycle.
There's nothing stopping other people from pushing things upstream,
anyone can help out. I couldn't code my way out of a wet paper bag,
but I have pushed quite a few patches upstream :) Sitting around for
things to happen almost always leads to dissappointment.
Koen
Daniel Díaz
On Mon, Jul 27, 2009 at 7:14 PM, Fernando Cassia<fca...@gmail.com> wrote:
[...]
> Ideally, TI should NOT suggest or deploy any "frozen" kernel version.
> They should just send any changes upstream and the end-user should be
> able to download the latest greatest kernel from kernel.org and
> compile, and get a functional box.
> So, instead of fumbling about it, why doesn't someone at Neuros writes
> a polite but strong message to TI's Linux development manager and asks
> about these issues?
Much of that is happening for OMAP:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=heads
http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=summary
As Koen says in another email, it's a slow process, but things are
being pushed to Linux OMAP (which is closer to ARM Linux (which is
closer to upstream Linux (which is what we all want))).
Greetings!
Daniel Díaz
yo...@danieldiaz.org
Vladimir Pantelic
>
> Gentlemen,
>
> In fact I'm rather disappointed with Ti and their Linux kernel
> developers. Everything is in constant movement. I don't understand
> them at all (apparently this is why there was a quarrell between them
> and Solarise developers, now I understand Solaris developers much
> better, unfortunately technically inferior products tend to win).
> I wanted to take part in Neuros development, I purchased OSD 2.0
> board, I have will, skills and time to do it, but the overall Ti
> products picture looks to me extremely bad.
hmm, last time I checked the OSD2 was manufactured and sold by Neuros.
not by TI. And I don't remember TI advertising the OSD2 to anybody.
So blaming TI for not supplying a kernel is barking up the wrong tree
from an end users point of view. Even more when seeing that at the same
time (or even 1y before the OSD2), there were products available that used
the same SOC, the same features and they ran under Linux.
So, I would have expected that if I buy a unit from Neuros, Neuros would
supply me with a working kernel for that one (well defined) product, not caring
about whether this kernel runs on any other PCB or architecture.
Whether this kernel is linux mainline or not, I would not care, the
most important part is that it supports all the HW features and related
SW components (e.g. cmem, dsplink etc..) of the OSD2, enterprising hackers
can then forward port all that to mainline or not, but all the OSD2 hackers
would have had a working kernel to base development on. And frankly, what is
the point in running the latest and greatest mainline kernel? Most of the
new features there would have had 0 impact on OSD2 useage and performance.
I don't know what TI "promised" to Neuros when the project started, so
maybe Neuros has all the rights to bark up TIs tree, but Neuros telling
people "go complain at TI" is not the right thing IMHO.
Regards,
Vladimir
Vladimir Pantelic
>
> On Sun, Jul 26, 2009 at 6:09 AM, Porro<_po...@mail.ru> wrote:
>
>> In fact I'm rather disappointed with Ti and their Linux kernel
>> developers. Everything is in constant movement. I don't understand
>> them at all
>
> It is the TI programmers' job to move their changes "upstream" so
> those are incorporated in the Kernel.
Not sure, their managers might argue their job is to support TI's
customers, however that is achieved.
>> scheduler - I want all the periferials devices work and be stable. The
>> worst is that they fix bugs in future kernel revisions leaving old
>> versions unfixed.
>
> Again, it's TI programmers job to "backport" any new kernel features
> to their older kernel.
Wow, again check their job description, this might not help their customers at all.
> Fedora 11 uses some features of the 2.6.30.x kernels, yet continues
> using 2.6.29, with those features backported.
nice for Fedora...
> Ideally, TI should NOT suggest or deploy any "frozen" kernel version.
Ideally, YES, TI should supply ONE stable and known working (=frozen?) kernel
for their SOCs (occasionally rebasing that of newer mainline kernels, maybe
once every 6mo or so) This would give TIs customers a stable base to develop
products against.
> They should just send any changes upstream and the end-user should be
> able to download the latest greatest kernel from kernel.org and
> compile, and get a functional box.
The end user to download a kernel? Like who? The guy who bought a STB from
a company that happens to use a TI chip? heck does he care about the kernel,
except in his cereals... What the end user wants is a working product.
Now, of course the average OSD user might be more enterprising, but you
have to understand that the total OSD user base is really tiny compared
to the "commercial" customers and volumes...
> So, instead of fumbling about it, why doesn't someone at Neuros writes
> a polite but strong message to TI's Linux development manager and asks
> about these issues?
As I wrote in the other mail, I have no idea what TI "promised" to Neuros,
but it seems that Neuros fully believed that ouputting the HW is enough,
the rest will either come from TI (it did not) or the hacker community
(which it did neither
Regards,
Vladimir
Fernando Cassia
>
> On 27 jul, 12:14, Fernando Cassia <fcas...@gmail.com> wrote:
>> They should just send any changes upstream
>
> Yes, let's "just" send everything upstream and it will magically get
> accepted on the first try.
Did I say that? No I did not. So please stop using irony when
referring to my posts.
TI could also maintain a separate branch, making it easier to
incorporate changes:
See:
http://julipedia.blogspot.com/2007/03/building-updated-kernel-for-ps3.html
"To make things easier, I'd simply have used the Linux sources
provided by YellowDog Linux 5 (YDL5), which correspond to a modified
2.6.16 kernel. However, as I have to do some kernel development on
this platform, I objected to using such old sources: when developing
for an open source project, it is much better to use the development
branch of the code — if available — because custom changes will remain
synchronized with mainstream changes. This means that, if those
changes are accepted by the maintainers, it will be a lot easier to
later merge them with the upstream code.
So, after a bit of fiddling, I found the public kernel branch used to
develop for the PS3. It is named ps3-linux, is maintained by Geoff
Levand and can be found in the kernel's git repository under the
project linux/kernel/git/geoff/ps3-linux.git."
Dos such public kernel branch exist for TI's target CPUs?
FC
Chase Maupin
On Jul 27, 7:11 am, Fernando Cassia <fcas...@gmail.com> wrote:
>
> > On 27 jul, 12:14, Fernando Cassia <fcas...@gmail.com> wrote:
> >> They should just send any changes upstream
>
> > Yes, let's "just" send everything upstream and it will magically get
> > accepted on the first try.
>
> Did I say that? No I did not. So please stop using irony when
> referring to my posts.
>
> TI could also maintain a separate branch, making it easier to
> incorporate changes:
>
> "To make things easier, I'd simply have used the Linux sources
> provided by YellowDog Linux 5 (YDL5), which correspond to a modified
> 2.6.16 kernel. However, as I have to do some kernel development on
> this platform, I objected to using such old sources: when developing
> for an open source project, it is much better to use the development
> branch of the code — if available — because custom changes will remain
> synchronized with mainstream changes. This means that, if those
> changes are accepted by the maintainers, it will be a lot easier to
> later merge them with the upstream code.
>
> So, after a bit of fiddling, I found the public kernel branch used to
> develop for the PS3. It is named ps3-linux, is maintained by Geoff
> Levand and can be found in the kernel's git repository under the
> project linux/kernel/git/geoff/ps3-linux.git."
>
> Dos such public kernel branch exist for TI's target CPUs?
You can find more information on what is supported and where the
branch is located at http://wiki.davincidsp.com/index.php/DaVinci_GIT_Linux_Kernel.
Notice that the branch is located on kernel.org. The general Linux
strategy at TI is moving to pushing new driver and features to the GIT
tree first. Periodically a snapshot of that tree will be taken,
validated, and releases as a stable starting point in the PSP. This
is a change from the older method of targeting the MontaVista kernel
and then pushing some of the changes upstream. This push to move
everything upstream first will help with long term maintenance and
support going forward.
>
> FC