4 ms·

Nvidia hasn't submitted any platform patches, nor device tree contents, for mainline yet. Nearly all the drivers carry over just fine between 32- and 64-bit, a

by ojn 12y ago

Nvidia hasn't submitted any platform patches, nor device tree contents, for mainline yet. Nearly all the drivers carry over just fine between 32- and 64-bit, and they've been actively moving a bunch of the little glue code out of arch/arm lately, so there's not a _whole_ lot left to do. I haven't seen anything posted yet so it's not looking all that promising that it'll make 3.19 either (but it's still possible).

uaygsfdbzf 12y ago
ARM SoC support in Linux mainline is usually pretty good but support for individual mobile devices that normally run Android's version of Linux is almost non-existent. Basically we are never going to get the usual Linux distros running on Android devices without using Android's version of Linux. There isn't anyone with the available, time, skills and motivation to get new or old Android devices supported by Linux mainline. I expect the same goes for other vendor-controlled Linux based mobile distros (Tizen, Sailfish, FirefoxOS etc). Probably the closest to mainline is the very old Nokia N900 but that doesn't even support all of the hardware on the device: http://elinux.org/N900 http://elinux.org/N900
- sandGorgon 12y ago
  Does anyone know what the differences between the mainline kernel and the Android kernel are? This is actually surprising to me - I had expected that the only differences were in username (unit system, ipc, etc). Is it a question of one time development to make driver format compatible in Linux?
  - ojn 12y ago
    (upstream arm-soc kernel maintainer here :) It's not really about anything Android-specific that's in the "android kernel", it's about all the other code that's needed for a platform to run well. The main problem is that besides the base kernel, most mobile platforms require a lot of code that hasn't been upstreamed. In some cases, "hasn't yet", in some cases "probably never will be" -- it depends on the vendor involved if they have any such ambitions. Most of this is drivers of various kind. Some vendors are better than others at upstreaming them and the other pieces that are needed, but nearly none of them have upstreamed sufficient amount of power management to make a real device useful and have reasonable battery life. There's also usually drivers missing for modems, etc. And, of course, graphics is a very sore topic in this area -- no vendor today ships a phone that uses an open graphics base. Ironically enough, Nvidia is the vendor that has done best here, with work happening in the open on their DRM drivers (but no products have shipped with those drivers at this time). The vendors that have done best are normally those who have more embedded-type platforms and not primarily mobile phone chipsets. By the time upstreaming of a mobile platform is done, the next generation is already out and nobody will build new products with the old one. It _does_ get better over time as more and more share code goes in, but most vendors have enough of a backlog that they don't see those benefits yet and as a result don't prioritize it as high as I wish they would. Then there is of course some vendors who don't participate at all, or does very very little. The Chinese manufacturers used to be notorious here, but even some of them have started doing better as of late (Rockchip in particular, but MediaTek has started posting some patches too). The vendor that traditionally has done best is TI, but they've gotten out of the mobile business. ST-Ericsson was making a good attempt too, and they also got out of it. Nvidia has actually been really good at working upstream on their 32-bit Tegra support, it's unfortunate that it's taken them this long to get going on the 64-bit support upstream.
    - tonyg 12y ago
      When you say that there are drivers missing, does this go as far as GPL violations? Or is it not quite as toxic as that? Also, what is the situation like with regard to figuring out what has been changed in a vendor-supplied kernel vs. a generic kernel source tree? Is it reasonably straightforward to get a clean diff so you can see what was changed? Non-upstreamed hacks and bodges seem less terrible to me if it's possible to at least see how they work.
      - ojn 12y ago
        Not necessarily GPL violations (there are cases of those too, but the bulk of it is not). It's just a matter of nobody having cleaned up the drivers enough to get them submitted for upstream inclusion. It can be quite a bit of work to do, and the next generation of product is sitting there waiting on the same people to make that work instead. You can usually download and diff the source tarballs. Some vendors keep git repos so you can see changelogs as well. There's usually a lot of noise in there though, lots of various imported vendor drivers that duplicate things, firmware files in hexdump format, etc. It's pretty common to see diffs of millions of lines.
        tonyg 12y ago
        Thanks. The noise issue sounds pretty frustrating.
        sandGorgon 12y ago
        could you elaborate on what you mean by "cleaning the drivers" ? I'm really curious, because it seems that Android has built an architecture where vendor supplied drivers (binary blobs?) can be dropped in without too much changes. But upstream linux needs a considerable amount of rework to "absorb" a driver. Is this deliberate (the same reason why GCC is obfuscated) or is there a technical reason behind it ? Because Android Linux works on thousands of different platforms with a lot of stability - I'm beginning to think that the Android driver model is superior... and perhaps mainstream Linux would do well to move to that.
  - arghnoname 12y ago
    Another difference between Android Kernel and mainstream is the power management system. Android devices suspend aggressively. Userspace acquires 'wakelocks,' during which time the device is not allowed to suspend. As soon as no wakelocks are held, the device can (and does typically) suspend. This is pretty different than the heuristics used in cpu idle style power management.
- deleted 12y ago
  [deleted]
- hobo_mark 12y ago
  I have a N800 laying around, would it be possible to put a modern kernel on it? I see there is still activity on linux-omap [1] but I haven't played around with it yet. [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/tmlind/linux-omap/ https://kernel.googlesource.com/pub/scm/linux/kernel/git/tml...
  - digi_owl 12y ago
    Best i recall, there will be some issues with the power management as those parts were largely Nokia proprietary.

by ojn 12y ago

uaygsfdbzf 12y ago

ARM SoC support in Linux mainline is usually pretty good but support for individual mobile devices that normally run Android's version of Linux is almost non-existent. Basically we are never going to get the usual Linux distros running on Android devices without using Android's version of Linux. There isn't anyone with the available, time, skills and motivation to get new or old Android devices supported by Linux mainline. I expect the same goes for other vendor-controlled Linux based mobile distros (Tizen, Sailfish, FirefoxOS etc). Probably the closest to mainline is the very old Nokia N900 but that doesn't even support all of the hardware on the device: http://elinux.org/N900 http://elinux.org/N900

sandGorgon 12y ago
Does anyone know what the differences between the mainline kernel and the Android kernel are? This is actually surprising to me - I had expected that the only differences were in username (unit system, ipc, etc). Is it a question of one time development to make driver format compatible in Linux?
- ojn 12y ago
  (upstream arm-soc kernel maintainer here :) It's not really about anything Android-specific that's in the "android kernel", it's about all the other code that's needed for a platform to run well. The main problem is that besides the base kernel, most mobile platforms require a lot of code that hasn't been upstreamed. In some cases, "hasn't yet", in some cases "probably never will be" -- it depends on the vendor involved if they have any such ambitions. Most of this is drivers of various kind. Some vendors are better than others at upstreaming them and the other pieces that are needed, but nearly none of them have upstreamed sufficient amount of power management to make a real device useful and have reasonable battery life. There's also usually drivers missing for modems, etc. And, of course, graphics is a very sore topic in this area -- no vendor today ships a phone that uses an open graphics base. Ironically enough, Nvidia is the vendor that has done best here, with work happening in the open on their DRM drivers (but no products have shipped with those drivers at this time). The vendors that have done best are normally those who have more embedded-type platforms and not primarily mobile phone chipsets. By the time upstreaming of a mobile platform is done, the next generation is already out and nobody will build new products with the old one. It _does_ get better over time as more and more share code goes in, but most vendors have enough of a backlog that they don't see those benefits yet and as a result don't prioritize it as high as I wish they would. Then there is of course some vendors who don't participate at all, or does very very little. The Chinese manufacturers used to be notorious here, but even some of them have started doing better as of late (Rockchip in particular, but MediaTek has started posting some patches too). The vendor that traditionally has done best is TI, but they've gotten out of the mobile business. ST-Ericsson was making a good attempt too, and they also got out of it. Nvidia has actually been really good at working upstream on their 32-bit Tegra support, it's unfortunate that it's taken them this long to get going on the 64-bit support upstream.
  - tonyg 12y ago
    When you say that there are drivers missing, does this go as far as GPL violations? Or is it not quite as toxic as that? Also, what is the situation like with regard to figuring out what has been changed in a vendor-supplied kernel vs. a generic kernel source tree? Is it reasonably straightforward to get a clean diff so you can see what was changed? Non-upstreamed hacks and bodges seem less terrible to me if it's possible to at least see how they work.
    - ojn 12y ago
      Not necessarily GPL violations (there are cases of those too, but the bulk of it is not). It's just a matter of nobody having cleaned up the drivers enough to get them submitted for upstream inclusion. It can be quite a bit of work to do, and the next generation of product is sitting there waiting on the same people to make that work instead. You can usually download and diff the source tarballs. Some vendors keep git repos so you can see changelogs as well. There's usually a lot of noise in there though, lots of various imported vendor drivers that duplicate things, firmware files in hexdump format, etc. It's pretty common to see diffs of millions of lines.
      - tonyg 12y ago
        Thanks. The noise issue sounds pretty frustrating.
      - sandGorgon 12y ago
        could you elaborate on what you mean by "cleaning the drivers" ? I'm really curious, because it seems that Android has built an architecture where vendor supplied drivers (binary blobs?) can be dropped in without too much changes. But upstream linux needs a considerable amount of rework to "absorb" a driver. Is this deliberate (the same reason why GCC is obfuscated) or is there a technical reason behind it ? Because Android Linux works on thousands of different platforms with a lot of stability - I'm beginning to think that the Android driver model is superior... and perhaps mainstream Linux would do well to move to that.
- arghnoname 12y ago
  Another difference between Android Kernel and mainstream is the power management system. Android devices suspend aggressively. Userspace acquires 'wakelocks,' during which time the device is not allowed to suspend. As soon as no wakelocks are held, the device can (and does typically) suspend. This is pretty different than the heuristics used in cpu idle style power management.
deleted 12y ago
[deleted]
hobo_mark 12y ago
I have a N800 laying around, would it be possible to put a modern kernel on it? I see there is still activity on linux-omap [1] but I haven't played around with it yet. [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/tmlind/linux-omap/ https://kernel.googlesource.com/pub/scm/linux/kernel/git/tml...
- digi_owl 12y ago
  Best i recall, there will be some issues with the power management as those parts were largely Nokia proprietary.