when might SDK move to newer linux kernel

The plan moving forward as I understand it is to move SDK kernel toward GIT tree and eventually have customers either work of GIT tree or buy a commercial distro (e.g. MontaVista).  Additionally, there are 3rd parties such as RidgeRun that can provide additional Linux support.

That said, I thought the SDK was based on 2.6.22 kernel, but I have not played with this myself.

FYI, the strongest open source initiative in my opinion is probably the community at beagleboard.org; I would sign up for their IRC and ask them what is the best git to work from.

I hope this helps.

Hi,

From some TI webcast we have gather that TI SDK team is moving towards having the next release based on Git kernel. Keep in mind that Git is a moving target and therefore is important to perform an feature freeze and stabilization work on it to create an SDK. Another issue to consider is the drivers functionality: the current 2.6.22 kernel supports several features, but some of them are not supported yet on the Git kernel and the process to merge them is slow as you need to keep compatibility in mainline with other OMAP boards.

At RidgeRun we have some internal work using Git kernel plus our quilt patch stack to create SDKs for OMAP35x, but at this point is not longer develop since we are focusing on supporting TI provided kernels. If you are interested on using a Git based kernel, or what customers really want is most of the time an particular kernel feature from Git, we can provide you engineering services to perform the work. But you have to keep in mind that is can of worms on the driver level.

The other option is that if you are interested on a particular kernel feature from Git, we can evaluate how (if possible) to back port it to the 2.6.22 kernel, however in some cases (like power management) the back porting is not a good option. 

Regards,

Diego

Hi,

Hit post too soon.

To answer the specific question, if you want to do the port yourself is better to use the omap git kernel at source.mvista.com. It has a decent support for OMAP35x EVM.

Regards,

Diego

I see lots of activity on omap git kernel at source.mvista.com referring to OMAP3.  Does this imply support for OMAP34xx and OMAP35xx?  These processors are the same, but I suspect that support is added specific to a development platform - and OMAP3430 SDP is different from OMAP35x EVM.  So which platform does "OMAP3" refer to?

Still confused as to why 35x SDK development that went into SDK 1.0.0 (by TI team I assume) wouldn't be in linux-omap.kernel.git.  Seems like multiple groups (TI, linux-omap team, omapzoom team, etc.) are working independently towards very similar objectives.

Thanks.

Unfortunately OMAP3 could mean either OMAP34x or OMAP35x, and you are correct that since it is not specific to a device or a board, the board level code/drivers may not apply, you would have to look into the source for the particular drivers that would be at board level to see if there is mention of EVM vs. SDP to get a better idea of what board it would be for.

I believe that the work that went into the SDK will eventually be fed back to the open source community (much of the EVM drivers in there are based on open source drivers anyway), though this may take time.

EDIT: I can confirm we are planning on aligning the OMAP35x Linux release with the GIT tree, though likely in a different tree, this is expected to be completed early next year.

I believe OMAP3 refers primarily to our OMAP35x family of processors; this family was targeted for the mass-market.

At present TI will provide SDKs and DVSDK software that works with mistral EVM.  But we are also working towards putting all the source code in GIT tree so that it can be merged and evolve along with newer Linux kernel releases; this is why you see activity from community supported sites as well. 

Additionally, we have third parties such as LogicPD which provide their own EVMs; they typically do not write their own drivers from scratch but rather borrow that software from our SDK or GIT tree source code.  They may tweak a few things, but they are probably not developing the code from scratch.

I hope this helps clear things up.

Codec Engine 2.23.01 (not yet bundled into a DVSDK) has comments that suggest support for Linux kernel up to version 2.6.29.

I currently have it running on 2.6.28.

Any updates on how moving the source code into the GIT tree is going?

adding source code to GIT tree is an ongoing process as we are constantly making software updates... any particular update you are looking for...?

The git tree for omap35x can be found here: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary

So how does the git tree you refer to differ from the omapzoom git tree at...

http://git.omapzoom.org/?p=repo/omapkernel.git;a=summary

It seems like two different kernels - both targeted at OMAP processors.

yes, at the moment they are different although I have heard of plans to merge them; if these plans solidify, omapzoom may go away... this is why I recommended the other tree.

Is there anything important which is OMAP / EVM specific in the TI 2.6.22 kernel which hasn't been pushed into the omap GIT tree ? I note that TI does not officially any kernel.org kernel for the OMAP35x EVM, which is why I'm asking.

I am not sure if I completely understand the question but will give this a shot.  The TI 2.6.22 kernel we provide with out SDK includes software dirvers that are specific to the hardware devices found on Mistral OMAP35x EVM; that said, just because these drivers may be specific to this EVM does not mean it cannot be pushed onto GIT tree.  So long as you configure you GIT kernel to build for the proper hardware EVM (of which the mistral EVM could be one choice), you should be good to go.  We are working hard to get all the Linux drivers found in the TI Kernel 2.6.22 into the GIT tree, but we are not quite there yet, but this is not for any hardware specific reason, it is more of a time issue, eventually we will get there..  That said, you should be able to find some support for Mistral OMAP35x EVM on GIT tree already..

Ok, so if I compare the TI and GIT kernels it should be fairly easy to determine what EVM drivers are not yet available in the  GIT kernel?

I am inclined to say yes, but a bit hesitant to say so.  For some of our older DaVinci platforms, we found that by moving to newer kernels which supported newer APIs and features in the audio and video space, it was not a simple drop new drivers in approach, we had to do sognificant merging of code with the main tree before committing drivers to GIT tree which probrably made our drivers look significantly different than what we started with from the TI kernel.  I am not sure if this will be the case as we move our OMAP35x drivers to the GIT tree, but it is certainly possible.  Are you looking for any driver in particular in the OMAP GIT tree?

I don't have any particular drivers of interest yet.   I still don't have my hands on hardware, but I'm trying to get a feel beforehand of what and how much is unavailable or unstable in the GIT tree.  Ideally we use the GIT tree but if that kernel has some key drivers missing or unusable I don't want to be banging my head against the wall.

my recommendation would be to use the TI Kernel provided in the SDK at the moment; it is free and tested and should have the most complete support.  Eventually, we when migrate OMAP35x drivers to GIT tree, GIT tree will become a good option and we will promote this to customers.  When we get here, we will likely make future software releases of TI kernel based on GIT tree snapshots (just an educated guess, please do not quote me on this last statement).

Thanks for your advice; I will import the TI kernel into openembedded.  If and when you happen to know about a SWAG for the GIT tree I'd appreciate it.

sorry, I do not have a tentative timeline yet, but will definitely post a message out to the community whenever we have something I can share.

Why do you need to import the kernel into OpenEmbedded?  It should already be in the OE metadata for the Angstrom Distribution.  You can get a very basic OE-based system built from http://arago-project.org, which brings in TI patches on top of the git kernel.  The patch set is still unfortunately somewhat large, but I expect it to go down over time.  As the patch set goes to 0, we'll have an SDK release that really is based on the public git kernel.

If  you are familiar with OpenEmbedded, then you should understand this list of patches to git kernel: http://arago-project.org/git/?p=arago.git;a=blob;f=recipes/linux/linux-omap3_psp2.1.0.5.bb;h=33fdd20b0c5d56cd9cee9dd087d72ee2e6f5fccb;hb=HEAD.

Yes, I see that the EVM is already in OpenEmbedded.  I am looking at OpenEmbedded directly, and at stable/2009 because I don't want to be running off a development branch.  Angstrom does not have a seperate git tree and stable/2009 is the branch Angstrom recommends according to their build instructions.  In OE stable/2009 omap-linux-pm @ 2.6.28 is the current default kernel. f I take the recommendation of Juan Gonzales then I want the TI kernel in OE.   In OpenEmbedded I did not see offhand support for the TI 2.6.22 kernel though I could have missed it. 

I did not know of arago; thank you for pointing it out.  On the front page for arago it currently says "This project is not ready for prime-time but feel free to poke around."   If arago is actually ready for prime-time it sounds great to me.

gumstix also has their own git tree.  I would be using the overo instead of the EVM, but I need signals which are not brought out by the overo. I also know of the omapzoom kernel but that only looked like it was for the zoom development platform.  Poky has also registered but I don't see much real information.  And of course there is the plain kernel.org kernel.  Which ones am I missing? 

Basically I don't want to waste my time twiddling with an unstable kernel as opposed to getting real work done.   I admit I still haven't done enough due diligence which is why I'm here looking for guidance.   I guess mostly what I need to evaluate is how full-featured the McBSP support is in the newer kernels.  Everything else should be standard enough to be usable.

OK, based on the TI update advisor for "linux platform packages updates" TI is officially supporting Arago.