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
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
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)
> 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? ;-)
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
> 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.
> 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?
no question about it. I wish it were further along software wise.
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.
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.
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
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
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)
'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
> 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?
> 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
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
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
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
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