Slashdot Mirror
Texas Instruments Embedding Linux
darthcamaro writes "Looks like pretty soon Linux will truly become ubiquitous thanks to Texas Instruments new DaVinci System on a chip DSP. The new consumer electronics chip aimed at capturing the Digital Video market is powered by MontaVista Linux. 'TI understands that there is a larger number of Linux programmers than there are DSP programmers,' Huy Pham, DSP System-on-Chip product marketing manager at TI, told internetnews.com. 'What [DaVinci] does in partnership with MontaVista is enables the Linux developer to use the DSP without needing to understand the complexity of programming the DSP.'"
If you get Xen up and running then it will run windows but veeery slooowly maybe vmware will do a better job. Then again if there is any virtualization support in the Ti DSP then Xen should fly on this device.
From TFA:
"There have definitely been a few GPL legal issues and even TI had to work through some of these," Pham said. "TI does have a proprietary processor communication between the ARM and the DSP. We do need to keep that separate from the Linux side."
Pham noted that TI provides its customer with support and some legal advice to keep things separate.
"Yes it's a complication and yes some customers have some issues with it and some questions with it," Pham said. "But in general, it hasn't been so much as an issue as it has been questions."
A house divided against itself cannot stand.
TI really need to kick out their QA team, hire a new one, and get off their asses. I work with CCS 10 hours a day. After 2 weeks of working with the latest version (3.1) I had about 20 different things to complain about, and those are only the new bugs (the old ones tend to stay). I'm not talking about anything advanced - I just use the IDE for editing, compiling and debugging (breakpoints, etc) - I'm talking about usability annoyances, inexplicable slowdowns, crashes, Ctrl-F3 suddenly not working, things like that.
It is also not uncommon for basic Chip Support Library functions like DAT_copy (which initiates an EDMA memory transfer) to stop functioning with a new CSL release. QA, people, QA.
phozz
Yes, the Knights of the Templar hatched a plot with Emperor Constantine and put the clues to their scheme in a microchip. They've been waiting a while for the technology to be available.
Except for ending slavery, the Nazis, communism, & securing American independence, war has never solved anything.
Bet you never knew that TI actually stood for The Illuminati
This is great and all, I just don't see why this is front page news. I would consider ARM-DSP hardware with Linux support mainstream rather than a bold step taken by TI. A random grab from sponsored adds on google:
http://www.sandorlabs.com/
http://www.compulab.co.il/
http://www.plexxa.com/
http://www.atmel.com/products/AT91/
http://www.xbow.com/
http://www.lynuxworks.com/
All products seem to support Linux on ARM/XScale and (at least) some in combination with a DSP.
Sure, Texas instruments is a heavyweight in the embedded world, but is this just another clueless ScuttleMonkey post or did I miss something?
Can't tell you much about the ARM side, though I will say the TI compiler tends to get high marks on code density and speed on the ARM. I'm sure you could write your ARM code with GCC. I don't know how the heterogeneous linking process works. Only other thing I know off-hand is that there is no flash. Silicon processes that support flash tend to not support high clock rate, and DaVinci can go real fast. :-) More at DaVinci's website.
Disclaimer: I work for TI and had a hand in the C64+ DSP that it includes, but I'm not a member of the DaVinci product team.
Program Intellivision!
When I asked MV for the source, the salesperson tried to tell me that required a special source license that I had to pay for.
Is this just ignorance on the part of the salesperson, or is it MontaVista company policy?
If the latter then the folks at gpl-violations.org will probably be interested.
As a direct user of MontaVista software, you might like to inform them that you are currently assessing whether they are knowingly in violation of the GPL, or whether its an unfortunately and temporary mistake which can be corrected with remedial education of their salesforce.
Our compiler supports exceptions now? I've only ever used our C compiler and the linear assembly optimizer. I haven't really touched our C++ support.
:-)
All I can say is when you find bugs, send them in and get a bug number. The compiler team does track bugs, and they can't fix bugs they don't know about.
The IDE (Code Composer Studio) is not handled by the compiler team and I don't know if anyone on the compiler team uses it much, if at all. CCS is maintained in TI Toronto, last I knew. They too track bug reports. Unfortunately, though, they're under greater feature pressure than bug fix pressure. That makes it even more important to file bugs. Otherwise they'll never get the message. I'm probably not the only person who finds it a tad ironic that our integrated development environment is actually built out of parts by a handful of groups, at least a couple of which (TI Toronto, formerly Go DSP and TI Santa Barbara, formerly Spectron) used to be 3rd party companies.
FWIW, I don't really use CCS myself either. These days I barely even use the compiler, though. The last time I used CCS seriously, I filed plenty of bugs against it. Our software tools team continues to evolve and I've seen some changes recently that I think will point CCS in a better direction. Here's hoping! (Since I am a TIer, I'm not sure how much I'm allowed to say, so sorry I haven't given more juicy details.)
--Joe
Program Intellivision!
As long as you understand fixed-point arithmetic, it's not too bad to code from C either. I do recommend that you restrict-qualify pointers whenever possible and use some of the #pragma directives to let the compiler know about things like "I know this pointer is aligned to an 8-byte boundary" or "I know this loop goes around eleventy-billion times." Other compilers also benefit from this information, but given the extreme amounts of explicit parallelism and SIMD a DSP like the C64+ offers (up to 8 instructions per cycle, but more like 26 or more actual "operations"), you have much more to gain in DSP-space by giving the compiler this info. DSPs can't spend the transistors desktop CPUs do on dynamically scheduling all those operations at run-time.
Coding for the DSP is actually a lot like coding for MMX or SSE in some ways. (More like MMX when coding for C64x, since the DSPs are fixed point.) Just keep your data types sized appropriately, and in the case of TI DSPs, listen to the feedback from the compiler.
--Joe
Program Intellivision!
MontaVista's kernel is the Linux kernel, with their modifications (and others' modifications) on top of it - which is GPL-ed. So if a customer requests the source, they must jump and provide it ...
With my limited understanding of the GPL (IANAL), I believe that a vendor can charge what he/she wants for the binary version of the software, and is then obligated to provide the source (to that same person) at a nominal additional cost. The GPL only requires providing the source to those parties that receive the binaries. The customer, however, has no obligation (under the GPL) to keep the source code secret, and can redistribute the code at any cost (including none) to other parties. If MV adds an additional license to the GPL'd source that prevents redistribution, *that* would be a violation of the GPL.
So where are all these MV customers and why haven't they provided the MV kernel source for the rest of us?
I big thing with this is that there are 2 CPU cores on the one die. There is an ARM9 processor and a TI C64x DSP core. Think AMP (Asymentric Multi Processing) with the DaVinci stuff for now.
This allows the processor that is good at branching and control code to execute that and the DSP to execute the filters that it is good at.
They are special purpose CPUs which do one thing well, implementing a fast filter. The trouble is, they really suck at branching and I/O servicing like protocol stack handling, decoding messages and state-machines.
You are entirely missing the point because that IS the point of the DSP. It is a lean, mean, number crunching machine, that crunches those numbers extremely fast and with low power consumption. If you need to control pretty GUIs on the device's LCD screen, use an ARM or somesuch. Better yet, use OMAP and get both.
You're not going to run a cellphone for days without charging if you try to use MIPS or powerpc. You will if you use an OMAP.
You're right - but this doesn't address that. DaVinci is a dual-core solution ala OMAP; you have an ARM running Linux and a DSP running DSP/BIOS on the same chip. Admittedly, with well-defined communication channels and "standard" TI XDIAS modules on the DSP you can mostly avoid doing real "DSP programming" - but then you're limited to using canned DSP algorithms or at most playing "building blocks" with them.
Not to say this isn't a nice setup - it is. Just don't assume it will remove the need to do traditional signal-processing coding.
You are wrong.
Please read the ellided GPL pieces below (or read a copy of the GPL). We do not mention what constitutes a derived work here, but the rights and obligations are clear. You would be wrong -- source rights extend to any 3rd party, or include full source which is then again distributable.
Ratboy
" if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights."
" You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License."
" You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) "
Just another "Cubible(sic) Joe" 2 17 3061
This is now getting rather far-afield from the original, since all other evidence points to MV being a very good GPL-abiding corporation. (I suspect, as do others, that some wires got crossed)
However, this is a frequently quoted misconception that I thought I'd stomp on, in the hopes that it doesn't get repeated. Like most widely circulated misconceptions, there's a kernel of almost-truth to it, but in its essence it's wrong.
What the GPL requires (section 3) is:
- that every binary be shipped with source, OR
- that every binary be shipped with a written offer to provide to any third party, not just those who have a copy of the binary, or only to those who are original customers of the company, the source for a cost no greater than the cost of creating the physical copy of the source
Since we're talking about commercial distribution, I'm ignoring section 3(c).What this means is that either you give every customer a copy of the (GPL-ed portion of the) source with every binary, or you give the GPL-ed part of the source code to anyone who asks and coughs up the cost of doing the physical duplication. (for at least three years after shipping the binary) None of this "we'll let you have the source for the cost of the disks + S/H, but only if you're our customer" stuff.
Really, people, the GPL isn't that long, nor is it anywhere near as lawyerly as many software licenses. There's no excuse for holding forth on it and having not read it.