Reply
Thread Tools
wicket's Avatar
Posts: 634 | Thanked: 3,266 times | Joined on May 2010 @ Colombia
#131
Well, yes. Mainline kernels are already bootable and very functional on the N900. The good news is that there is some of overlap between the N900 and the N9/N950 kernels, that means that there are patches that are needed for the N9/N950 which have already been mainlined by the N900 effort. You can compare the two project pages to get an idea:

https://wiki.merproject.org/wiki/N9_...update_project
http://elinux.org/N900

Good luck with your communication with the N9 kernel update project team. As I mentioned, the project appears to be all but abandoned. I hope don't sound too negative. I'd love to see upstreamed N9/N950 patches, it would respark my interest in the platform, put my N950 to good use and increase the reach and interest in mobile Debian.

The more modern the kernel, the better. N900 patches are being mainlined with each release. The cmt-speech driver for example went into 4.1. See here for the N900 changelog:

http://elinux.org/N900/Changelog
__________________
DebiaN900 - Native Debian on the N900. Deprecated in favour of Maemo Leste.

Maemo Leste for N950 and N9 (currently broken).
Devuan for N950 and N9.

Mobile devices with mainline Linux support - Help needed with documentation.

"Those who do not understand Unix are condemned to reinvent it, poorly." - Henry Spencer
 

The Following 6 Users Say Thank You to wicket For This Useful Post:
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#132
I've already gotten in touch with filippz (received a reply), I'll keep you updated.
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 

The Following 4 Users Say Thank You to marmistrz For This Useful Post:
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#133
Here's the reply from Filip. Anyone: do you have any ideas what to do with it? Pali (he was pinged by me): you work on the N900 kernel, maybe your experiences would be useful here.

Originally Posted by Filip Matijević
Hi again,

regarding upstreaming my commits there are few major reasons why it didn't happen:

  • this kernel work was my first experience with kernel internals, pure C and git. Hence many commits are not up to linux kernel coding standards - they do work, but they can't be used "as is" for upstreaming
  • some of the drivers were part of the kernel, but seemed to be from different code base - depending on their usage they were modified, or rewritten based on original Nokia kernel. I guess replacing entire drivers is not something that would be upstreamed easy. For example CMT parts from n900 are different than those used on N9. N900 stuff got upstreamed (or is about to be), and I'm not really sure if it's the same HW, or there needs to be some N9/N950 specific stuff in there.
  • some hw can't be used without binary blobs from Harmattan (battery - BME, camera - lipomap3camd, and GPS as mentioned earlier). This forced me to do some nasty hacks (twl4030-madc seemed to be quite different and needed "old" stuff in order for BME to work, libomap3camd has trouble because v4l2_event has changed ABI...) This also would be difficult to upstream.
  • many of the stuff in there has no proper documentation (CMT, GPS...), hence it would be difficult to explain why some changes are needed. I guess saying: "It works that way", wouldn't be enough
  • Jolla used non LTS kernel as a base, maybe if we were on 3.4 LTS this would be a bit easier (AFAIK only "must have" reason for 3.0+ kernel was usage of systemd in Mer)
  • Kernel has shifted to device tree, but many of the stuff placed in board-rm680.c seem to be difficult do implement in such way - some of this would also require rewriting drivers

Sadly both of my N9's have stopped working (both developed problems with their CMT modules, one has since been destroyed in an attempt to fix it) I've moved to Android (and no, it's not working out for me. This has reduced my interest in this project considerably, but I'm willing to help. At this point I'm thinking that we would need some kernel hacker that has good knowledge of kernel internals (and maybe even has connections with TI kernel guys and old Nokians that worked on N9) that would be willing to go trough my commits. Still I think that due to lack of documentation (MEIF requires signing NDA with Nokia, so does camera smiapp - together with bunch of "smiapp compatible" sensors that have quirks as they are not 100% compatible - contacting Toshiba, Sony for datasheets could be problematic...) current kernel state is probably best we can do.

It would be awesome if you succeed in getting some helping hands, but I'm under impression that N9/N950 didn't manage to attract "hardcore linux hackers" (at least not as much as N900 did) making it difficult (if not impossible) to find the "right people". In all this time I'm able to count all interested in N9 kernel on fingers of one hand

I've subscribed to TMO thread you linked, and I'll keep an eye on further progress!
About the state of the kernel:

Originally Posted by Filip Matijević
Jolla guys did make first steps in making 3.5.3 bootable on N9, but after they moved onto their own HW they stopped developing N9 kernel further. I've made some progress since then, but biggest obstacle remains: problem of performance. It's believed to be due to rather hacky way wayland is implemented on top of closed source PVR binaries (https://github.com/nemomobile/ti-oma...-wayland-wsegl). Possible solutions would be to fix existing wayland implementation (https://twitter.com/hedayatvk was investigating that), or use PVR drivers for android (from LG Optimus Black P970, https://twitter.com/crazybulgarian was looking into that). There is also small possibility that Imagination makes open source driver (https://www.phoronix.com/scan.php?pa...R-Open-Chatter) but I wouldn't hold my breath on that one.

The only non function part of the kernel is GPS - and this will remain unchanged. GPS chip speaks MEIF instead of NMEA, and all the binary blobs for GPS (there seem to be a few of those) from Harmattan are tied to Qt4.
Filip's TMO nick is Filip.pz
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 

The Following 2 Users Say Thank You to marmistrz For This Useful Post:
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#134
Info from pali:

Originally Posted by pali
Hello!

You can look at page http://elinux.org/N900 which track upstreaming
status for Nokia N900.

Process for upstreaming support for N9 or N900 should be similar or
quite same.

There are basically two big problems:

1) SGX graphics drivers and changes they need in mainline kernel

There is no open source userspace support for these TI/IM/SGX drivers
and this is enough reason that they will never be merged into mainline
kernel. Also now only KMS graphics drivers are accepted to mainline
kernel, so you those SGX kernel drivers (even they are GPLv2) will never
hit mainline kernel.

Just to note that *every* and *every* SGX chip needs different:
microcode, kernel driver and userspace driver.

Plus those SGX kernel drivers needs some changes (hacks!!) to mainline
kernel to make they work.

I would just say, ignore SGX driver in upstream process and keep them in
separate tree (with also changes to mainline kernel which are needed).


2) Quality of current Nokia/TI drivers which are in some production
Nokia kernels used on Nokia N9.

Lot of times quality is really bad and in that state drivers are not
accepted. You need to communicate with developers of specific kernel
trees what do they think about those drivers, what needed to be fixed,
changes and so, so maintainers can accept and merged them.

Plus whole OMAP and ARM code in kernel is converting to DeviceTree
structures (from old board code), so when you will try to mainline it,
you need to add support for DeviceTree (and probably remove old
platform_device board code which is obsolated).


3) First and important: Create table line on http://elinux.org/N900 and
decide which drivers are needed, which are already in upstream (but
in different name, etc) and which must be rewritten (e.g because
interface/subsystem was changed).

Thanks all.
Originally Posted by pali
I think all hackers who hacking n900 kernel know all these information,
so for them it is not needed...

>
>> 3) First and important: Create table line on http://elinux.org/N900 and
>> decide which drivers are needed, which are already in upstream (but
>> in different name, etc) and which must be rewritten (e.g because
>> interface/subsystem was changed).
>
> You mean that we should combine the N900 & N9 efforts together?
>

Rather create new wiki page (on elinux.org). Please not add N9 info into
N900 page as we want to have that page clean...
Any other kernel hackers here?

I think it's a good idea to create the elinux.org page for N9, indicating what is already upstreamed, what has to be done (issues for each of the commits, etc.), which parts need binary blobs (we'd have to reverse engineer them or use them)

When it comes to the coding style, maybe I could fix a commit or two.

One more thing: (@filip.pz) BME has been reverse engineered.
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here

Last edited by marmistrz; 2015-09-15 at 13:51.
 

The Following 3 Users Say Thank You to marmistrz For This Useful Post:
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#135
@Everyone: Any thoughts?
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#136
For people not watching the Upstreaming Force: crossposting: http://talk.maemo.org/showpost.php?p...4&postcount=45
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 

The Following 4 Users Say Thank You to marmistrz For This Useful Post:
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#137
Feature request: could you add the possibility of installing kernel only to debian900, without removing all the fs?

When I have time to devote to the N950 kernel upstreaming, I'll probably test >1 kernels, so I don't want to kill my internal memory with write cycles.
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 

The Following 3 Users Say Thank You to marmistrz For This Useful Post:
wicket's Avatar
Posts: 634 | Thanked: 3,266 times | Joined on May 2010 @ Colombia
#138
Originally Posted by marmistrz View Post
Feature request: could you add the possibility of installing kernel only to debian900, without removing all the fs?

When I have time to devote to the N950 kernel upstreaming, I'll probably test >1 kernels, so I don't want to kill my internal memory with write cycles.
This is something that I've wanted to do for a while now as to test a new kernel I would often find myself manually mounting the file systems, copying over the kernel and modules and then I'd chroot into it in order to generate U-Boot compatible kernel and initrd images. It's a bit of a pain when it can be easily automated.

Sadly, I've no free time available in the coming months to do any work on this project.
__________________
DebiaN900 - Native Debian on the N900. Deprecated in favour of Maemo Leste.

Maemo Leste for N950 and N9 (currently broken).
Devuan for N950 and N9.

Mobile devices with mainline Linux support - Help needed with documentation.

"Those who do not understand Unix are condemned to reinvent it, poorly." - Henry Spencer
 

The Following 4 Users Say Thank You to wicket For This Useful Post:
Posts: 3 | Thanked: 2 times | Joined on Nov 2015
#139
Thanks a lot for this project, really cool to have debian on my N900!
I am curious can you connect USB devices?
 

The Following 2 Users Say Thank You to NIK510 For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#140
Quick update on GTK3. Will start a dedicated thread at some stage.

Been cleaning up the test suite and examples lately to help track down a few issues and to make the build output easier to follow. It is down to hildon-pannable-area-tuning-example (segfaults because I ripped out a lot of HildonPannableArea) and hildon-button-example (gtk_button_set_alignment IIRC) being the only files to generate warnings.

With regard to actual source files, HildonCaption, HildonButton, HildonPannableArea and hildon-main are still causing warnings.

I have some changes not yet commited to github (inc some of the examples fixes unfortunately), mainly due to HILDON_SIZE_HALFSCREEN_WIDTH and HILDON_SIZE_FULLSCREEN_WIDTH not being handled the same in GTK3. These helpers are probably going to have to be removed, and the height definitions need some work to prevent a warning being spewed out by HildonAppMenu (amongst others).

It is buildable on its own on Debian if anyone really wants to have a play. Stacked windows and some notifications won't work as intended (they need hildon-desktop/matchbox). You'll also get several styling/font errors as I've not started to look at that fully yet.
 

The Following 8 Users Say Thank You to Android_808 For This Useful Post:
Reply

Tags
debian, debian900, devuan, maemo 7

Thread Tools

 
Forum Jump


All times are GMT. The time now is 01:55.