fresh news from [MeeGo-dev]@meego.com


Hello MeeGos !

This is brief status update of "MeeGo to N900" project. This project is currently running as Nokia project, and I am Nokia project lead for it. The current closed mode of development is not the target for us at all, but rather transitional condition. As already discussed by Valtteri in TSG meeting, we are looking into going more open mode shortly. One reason why we have done this on this way is that at the same time we have been trying to handle opening of many currenly closed components that are needed in MeeGo and to build feasible MeeGo images for N900.

However, a lot of related work is already done completely open, you can find more info from places like ofono.org, connman.net and meego.gitorious.org . So if you are eager to contribute or want to closely follow whats happening, please work on those.

As you know, we have delivered working MeeGo images for N900 as part of first code drop in the end of March. At that state we were using older kernel version on N900 than on Atom side, as we used the same kernel (.28) than what is used in Maemo 5 based products today. We ended up doing that simply because lack of time to contribute and port all the drivers to the newer kernels.

Now, for the upcoming May release of MeeGo, we are going to use the same kernel version (.33) than Atom based devices are using. For that we need to submit number of ARM-architecture patches to MeeGo as well, because many of the required ones have just been contibuted upstream kernel and were not available in .33 version originally.

We have already enabled most of the main drivers, like LCD, GFX, Wlan and BT. Still, there is a lot to do in order to enable .33 on N900, like audio drivers, and modem subsystem including SSI buss driver, modem data and audio drivers etc. Our adaptation guys are in fact contributing those modem subsystem related drivers as we speak, and if you are following kernel mailing lists you can see how that goes on.

Besides of enabling the new kernel, we are working with number of smaller and bigger issues for N900. Starting from the beginning, we are now based on ARMv7 combiled code, so the code should be better optimised for N900 now. ARMv5 compilation that was in use for code drop will still be there, and it also seems to be used at least by community project that is planning to release MeeGo for good old N810 tablets

Also, we are planning to enable dual booting of Maemo 5 and MeeGo for the upcoming release. So that will be offered as 3rd way to setup MeeGo to N900, including the existing "native" MeeGo only on N900 and chroot based MeeGo on Maemo 5 setups. Taking the dual boot mode into use likely includes upgrade to Maemo5 kernel as well, but that should not be big issue in the process of enabling that.

As I don't want to go ahead of others working on MeeGo architecture and other issues I will stop now, but I will report again when we have more to tell about the subject.

Br,
// Harri

---------------------
copied from the [MeeGo-dev] list

Max

Thanks for posting Harri's email here Max!

corrected

I saw this on the mailing list too. Great information from Nokia.

I gave them a standing ovation on the list.

Sorry for not making it clear:
I just copied that from the meego developer mailing list.

Max

So, this is the end of the FUD about the MeeGo on the N900 scheme, then?

Great news! I just hope this team survives any layoffs that might occur because of the stock being hammered today.

At the end of the day, the share holders own Nokia and they will demand blood today's stock drop!

I was unable to attend this week's meeting. Will this project eventually bring Nokia's own (Harmattan) MeeGo UX and applications (Ovi Maps, etc.) to the N900 or is this project for the reference MeeGo handheld UX?

I think it's closer to the definition of a hardware adaptation team. You need that to work before you bring in the fun things. I have no idea if Nokia will do that.

What is happening is that Nokia's actively upstreaming the patches for the N900 and maintaining a hardware adaptation. Isn't this great?

Is there any way that this can be done and still allow custom kernels (e.g. titan's)??

Thanks for the update, too. Actively engaging your community early and often will definitely benefit both your users and your team. (see any PR1.2 thread for a counter-example).

Undoubtedly, since the source for the kernel will be available.