Sorry for the slow response, I had to get caught up to speed myself.
I'm actually still not entirely clear, but probably better to clear up
my confusion on the list, so others can chime in.
AFAIK, we were waiting for TI to bring their kernel into mainline,
which apparently has been done, but apparantly it doesn't work on the
davinci board? or maybe it works on the davinci evm board, but not
the OSD2 board? I'm not entirely clear here, Nero? Jason?
In addition we were waiting on some codecs, which AFAIK were being
delivered, but I haven't heard much out of it. There was quite a bit
of discussion, particuliarly about licensing, but that seems to have
quieted off. Honestly when TI released dsplink and the other tools
under GPL, I was under the impression that had been cleared up too.
Before I go on, can anyone comment on status of the above?
The davinci kernel is being maintained in a branch on kernel.org these days [1]
and is in the process of being merged with the mainline kernel
(slowly, as we know the process can be quite strict) by the davinci
community (including TI people) lead by Kevin Hillman.
What this means is that TI and/or the community attached to davinci
are doing a bunch of work to fully opensource kernel and driver for
davinci boards, and this kernel is already fully usable on many
davinci boards as far as I understand it.
The mailing list is also very active, with a lot of patches that come
in everyday, so it's definitely a project that seems alive and
running.
The problem is: it doesn't run yet on the OSD2 board. OSD2 is a
davinci board allright, but of course it has its own peculiarities and
small differences (e.g. peripherals, etc). It also currently use an
older kernel than the davinci kernel.
Last year we were in contact with some TI engineers, we sent them OSD2
boards and there were talks of them doing the work to ensure davinci
kernel ran on our board.
As far as I know, nothing came out of that, since these TI engineers
were apparently reassigned to other priorities, and we didn't "apply
pressure" to get them back on this job since we were starting to focus
on the Link project at that time. I basically didn't hear from them in
months and I wasn't contacting them either due to Link-related work
here at Neuros that kept me otherwise busy.
Personally, judging by the discussions that I had with them and the
fact they had osd2 boards at their offices, I would've expected them
to be going ahead and doing the porting on their own, asking questions
when things were not clear to them. But no one asked us questions.
Apparently, the way TI thinks is that they need to have constant
"external pressure" on various levels to keep any project going, or it
will die out and nothing will be done.
Which is as far as I know what happened to this kernel project:
nothing has been done.
I'll let Joe comment on why, consciously or unconsciously, we choose
not to keep "applying pressure" on TI, but I bet you can guess what I
personally think of this whole idea of "pressure".
> In addition we were waiting on some codecs, which AFAIK were being
> delivered, but I haven't heard much out of it. There was quite a bit
> of discussion, particuliarly about licensing, but that seems to have
> quieted off. Honestly when TI released dsplink and the other tools
> under GPL, I was under the impression that had been cleared up too.
Another of the good things that TI did in the opensource realm is to
release the DSPLink and Codec Engine (CE) components as open source
[2]. They released them with the BSD license even, which is pretty
liberal. Plus they released some other libraries and tools related to
them. The only thing that is so annoying is that they can be
downloaded only after registering with TI, but we were even given some
permission to mirror them, if i recall correctly. So that part is
quite peachy, and I commend TI on this decision.
Now, we are still using the closed versions while we should probably
switch. Point taken.
However this isn't really the problem with the codecs that Joe
mentions above. These components, open or closed, are just used to
load and run the codecs, but are not the codecs themselves. Our
problem here is with the codecs themselves.
The problem with the codecs is that to the present day we still lack
an encoder-decoder pair for davinci that is capable of at least 720p
operation. The story more or less goes like this:
- Back then when we choose the DM6446 platform as the base for OSD2 we
were told that (when pushed) it was capable of operating in HD, thus
the marketing of OSD2 as an HD platform by Neuros, I suppose. I wasn't
much involved in the choice and initial testing of OSD2 hardware, an
hardware itself is not my forte, so I can't give any useful opinion if
this was the right choice or not. Not that it matters much at this
point anyway.
- After that, we tested the codecs that TI gave us, and naturally we
were expecting them to work ok when configured them to decode or
encode in 720p. Turns out that the codecs had instead a software
"cap", in the sense that they even refuse to initialize at all if we
asked them to work in a resolution higher than SD resolutions.
- TI people confirmed that yes, these codecs were not meant to operate
at HD resolutions by design. We were told that TI had allocated some
engineers to work for us at preparing a codec pair capable of HD. Any
codec pair was good for us at this point, we didn't even care if
mpeg4, h264 or mpeg2 as long as it demonstrated any HD operation at
all was possible on the platform.
- Months passed, we got nothing, despite asking from time to time.
After a while we stopped "applying pressure", again around the time
the Link project was started, if i recall correctly.
- We still got no such Hd codecs at the present day.
So,
this is the current situation, for both kernel and codecs, as far as I
can remember it.
I personally would totally love to see some kernel hackers (regardless
if TI, Neuros, Community or possibly all three together) embrace the
task of making the davinci kernel work on the OSD2 board.
Submitting patches for it to the davinci mailing list seems far less
scary proposition than submitting to the Linux Kernel ML directly, so
this is a great project for those that love embedded Linux but were
always afraid of being mauled to death in the LKML.
It's also probably the most useful thing that can happen to OSD2 right
now, as once we do the bulk of the work, the maintenance (in the sense
of keeping drivers up to date when kernel internals change) comes
basically for free.
Regarding the HD codecs, that's far less interesting to our community
I suppose, as it seems that it's just a matter of politics at this
point.
Clearly if anyone has the skill to write from scratch HD codecs, more
power to them and anyone who can pull that off will be hailed as a
legend forever. But it's probably a task of epic proportions and too
big for anyone to undertake.
I'll let Joe fill in the blanks here, and correct me where my failing
memory produced something incorrect.
And I'll let you all draw your own conclusions on this topic.
Cheers,
--
nero
[1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summary
[2] http://groups.google.com/group/neuros/browse_thread/thread/7920bee9cc2c9ae2
> Last year we were in contact with some TI engineers, we sent them OSD2
> boards and there were talks of them doing the work to ensure davinci
> kernel ran on our board.
> As far as I know, nothing came out of that, since these TI engineers
> were apparently reassigned to other priorities, and we didn't "apply
> pressure" to get them back on this job since we were starting to focus
> on the Link project at that time. I basically didn't hear from them in
> months and I wasn't contacting them either due to Link-related work
> here at Neuros that kept me otherwise busy.
at least on the #beagle IRC "khasim" (from TI) mentioned one time that
he has an OSD2, how much he is working on it I cannot tell.
____________________________________________________________________________
This email and any files transmitted with it are confidential and are
intended solely for the use of the individual or entity to which they are
addressed. Access to this e-mail by anyone else is unauthorised. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it, is prohibited. E-mail
messages are not necessarily secure. Archos does not accept responsibility
for any changes made to this message after it was sent.
> The problem is: it doesn't run yet on the OSD2 board. OSD2 is a
> davinci board allright, but of course it has its own peculiarities and
> small differences (e.g. peripherals, etc). It also currently use an
> older kernel than the davinci kernel.
>
> Last year we were in contact with some TI engineers, we sent them OSD2
> boards and there were talks of them doing the work to ensure davinci
> kernel ran on our board.
> As far as I know, nothing came out of that, since these TI engineers
> were apparently reassigned to other priorities, and we didn't "apply
> pressure" to get them back on this job since we were starting to focus
> on the Link project at that time. I basically didn't hear from them in
> months and I wasn't contacting them either due to Link-related work
> here at Neuros that kept me otherwise busy.
pardon my ignorance, but wouldn't Neuros be the one to adapt the "stock" Davinci kernel to run on the OSD2?
Good question. Not understanding the details of this process, I can
> pardon my ignorance, but wouldn't Neuros be the one to adapt the "stock"
> Davinci kernel to run on the OSD2?
only comment at a high level. The way I thought this would work would
be a more collaborative effort between ti, neuros and community, but
we came to something of an impasse. Vlc porting stalled because of
the kernel issues I guess, this stalled community work, although there
were probably a lot of factors there, not the least of which is the
beagle board. Lack of community momentum quelled ti's enthusiasm,
which slowed progress on codecs, kernel, etc. Neuros simply isn't big
enough to break out of this with brute force development effort, so
here's what we're doing to break out of this impasse:
I plan to work on getting the latest linux-davinci git kernel up on
OSD2. Afew weeks ago I started merging the neuros kernel with the
davinci git but got into some problems. This time I plan to take a
different approach and start with davinci git kernel as my starting
point and merge in neuros git patches into it.
I believe it is an enormous learning opportunity and am willing to
work with anyone interested to join me in this process.
Here is my plan:
0. Start with linux-davinci-2.6 git kernel from kernel.org and start
looking at the changes to be done to make it support the peripherals
on OSD2. I have also made a list of ICs used in OSD2 looking at the
schematics. I feel that the System Ref manual provided by Beagleboard
is a great resource and a similar guide on OSD2 will be a great
addition. I made this list as a starting point in that effort but
never got around to starting a wiki page.
1. Start merging neuros kernel changes into the git version. This is
going to be the major step and will be dne step by step, testing every
step on the hardware.
2. Start pushing the changes back into davinci git. This is important
to keep us uptodate with the upstream. We will rebase to the upstream
while in this process.
> If we can create some grassroots enthusiasm for the platform (its
> still the strongest dsp platform of its class) then we can get things
> moving. Anyway, that's what's we're trying now. While it's not an
> ideal solution, I think it's our best shot to get things moving again
> hopefully quickly.
I also have an XDS100 JTAG with me and Jason (TI) is helping me
getting it work on OSD2/Beagle. I have also started playing a bit with
TI packages like codec-engine.
I plan to start right away on step #0. If anyone is interested, let
the list know and let us join the effort and get things rolling..
thanks
--
Ramakrishnan
My guess is no one until the next generation silicon comes out. It's
hard to justify all the effort when the DSP is 25% weaker and lacking
acceleration that we currently have.
I also have an XDS100 emulator which I bought for $50 (and payed
another equiv of $50 to get it out of the Indian Customs). It
supposedly works with DM6446. I spent afew nights and days trying to
get it to work, but gave up. If anyone wants to have it, please
contact me offline. I don't think I have the patience and energy to
use it to do development for a propreitary DSP in my free time. Day
job of course is a different story.. I would happily continue
developing on Free Software on a Free Platform and save myself some
time and sleep..
regards
Ramakrishnan
There's something moving on the OSD2 front, and as Joe said the board
isn't so much non-standard as one would think.
If anyone of you is following the TI davinci mailing list, you may
have noticed that Jorge Zapata (previously of Neuros team) has posted
there a bunch of patches that enable basic support for the OSD2 within
mainstream davinci kernel.
From what he told me, it boots already and lots of stuff works, such
as serial, ethernet, mmc/sd cards, USB and most interestingly the hard
disk works too (it didn't work on Neuros' original kernel).
Other stuff may require more work, but it's an encouraging starting
point for sure and a big help for anyone that wanted to help out but
was scared of the "blank page" state. It's a lot easier now to just
boot the system and work on a single driver, since you don't have to
bother with bringing the whole thing up from scratch anymore.
Cheers,
--
nero