Mailing List Archive

Hi Frantisek!

On Tue, Jul 15, 2008 at 10:25 AM, Frantisek Dufka <dufkaf@seznam.cz> wrote:
> Hello,
>
> this was already discussed here
> http://www.gossamer-threads.com/lists/maemo/developers/36516#36516 but
> nothing happened. Today GeneralAntilles mentioned it again
> http://www.internettablettalk.com/forums/showthread.php?p=203080#post203080
> so I have finally sumbitted request for garage project which was
> approved - https://garage.maemo.org/projects/kernels/
>
> Primary goal is to accumulate kernel patches so they do not get lost,
> secondary goal is to build kernel images for all devices and latest
> versions of all IT200x releases. Patches should primarily apply to
> kernel sources release in Maemo SDK (i.e not current linux-omap).
>
> I am currently not the best admin for this project (daughter born last
> week :-) so feel free to join and help.

Congrats! I am willing to put in some time, and I see Im already an
admin of the project :)

>
> Good place to discuss ideas is perhaps open-discussion forum of the
> project https://garage.maemo.org/forum/forum.php?forum_id=2801
> Big question is to how to structure patches and where to keep them
> (directly in svn tree, tracker).
>
> Frantisek
> _______________________________________________
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>



--
Nick Loeve
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

nick loeve wrote:
> Congrats! I am willing to put in some time, and I see Im already an
> admin of the project :)
>

Excellent. Yes, anyone competent that wants to help (even with
administration) is welcome. As I explained I don't have much spare time
so I don't want to slow down anybody.

The GA's idea of packaging set of patches properly so they can be pushed
to extras-devel (and built by autobuilder) as specific community kernel
release makes perfect sense. My first idea was just to keep source
patches somewhere but this could make life significantly easier for
end-users too. This will need some additonal (admin and debian related)
work I did not expect at first.

Frantisek
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Hi again,

On Tue, Jul 15, 2008 at 11:48 AM, Frantisek Dufka <dufkaf@seznam.cz> wrote:
> nick loeve wrote:
>>
>> Congrats! I am willing to put in some time, and I see Im already an
>> admin of the project :)
>>
>
> Excellent. Yes, anyone competent that wants to help (even with
> administration) is welcome. As I explained I don't have much spare time so I
> don't want to slow down anybody.
>
> The GA's idea of packaging set of patches properly so they can be pushed to
> extras-devel (and built by autobuilder) as specific community kernel release
> makes perfect sense. My first idea was just to keep source patches somewhere
> but this could make life significantly easier for end-users too. This will
> need some additonal (admin and debian related) work I did not expect at

Im offline at home for the next week or so until my connection at my
new apartment is switched on. Once that happens i will take a look at
what it would take to get kernel packages built in the autobuilder and
the best way to 'version/store' patches.

Cheers

> first.
>
> Frantisek
>



--
Nick Loeve
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

On Tuesday 15 July 2008 09:25:36 Frantisek Dufka wrote:
> Primary goal is to accumulate kernel patches so they do not get lost,
> secondary goal is to build kernel images for all devices and latest
> versions of all IT200x releases. Patches should primarily apply to
> kernel sources release in Maemo SDK (i.e not current linux-omap).

Do you see this also addressing the related issue of building and distributing
kernel modules?

I have a package (sisusbvga) which contains a kernel module (to drive an
external VGA adapter). At the moment, I have built the kernel module using
the instructions on the wiki and then I package it up as a binary blob -- in
other words the debian package does NOT build the module from source. If
possible, I would like to change that so that the debian package builds the
module, in the autobuilder.

Actually in my case the situation may be reasonably straightforward: the
sisusbvga driver is actually part of the standard Linux kernel, although a
patch is required to get it to build for the Internet Tablet (I ought to
submit the patch to LKML one day). So, I guess it falls within the scope of
this project anyway, assuming you are addressing the problem of kernel
modules as well as the kernel image itself.

There are another couple of issues -- are they part of this project?

Firstly, as it stands today, I can't find a way to install the module such
that it can be found and loaded automatically when the hardware is seen on
boot: /lib/modules is only in the initfs.

The other problem is how to deal with kernel versions. I believe the plan for
Maemo going forward is that even kernel upgrades may occur. What package do
I specify as a dependency so that my package only installs on the correct
kernel version? How do I get the autobuilder to build the various versions
of my module needed for the different kernel versions? What magic do I need
to put in my debian/control to get the installer to install the correct
version of my module for the kernel version?

Graham
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Hi,

Wow, congratulations! I've applied to join. I'm not a programmer but I have
had enough experience with the maemo kernels (porting patches etc) to think
I am eligible for joining :).

On Tue, Jul 15, 2008 at 9:25 AM, Frantisek Dufka <dufkaf@seznam.cz> wrote:

> Hello,
>
> this was already discussed here
> http://www.gossamer-threads.com/lists/maemo/developers/36516#36516 but
> nothing happened. Today GeneralAntilles mentioned it again
> http://www.internettablettalk.com/forums/showthread.php?p=203080#post203080
> so I have finally sumbitted request for garage project which was
> approved - https://garage.maemo.org/projects/kernels/
>
> Primary goal is to accumulate kernel patches so they do not get lost,
> secondary goal is to build kernel images for all devices and latest
> versions of all IT200x releases. Patches should primarily apply to
> kernel sources release in Maemo SDK (i.e not current linux-omap).
>
> I am currently not the best admin for this project (daughter born last
> week :-) so feel free to join and help.
>
> Good place to discuss ideas is perhaps open-discussion forum of the
> project https://garage.maemo.org/forum/forum.php?forum_id=2801
> Big question is to how to structure patches and where to keep them
> (directly in svn tree, tracker).
>
> Frantisek
> _______________________________________________
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers


Have you looked at usb(lan, mouse etc)?
It uses your dbus-scripts, an udev rule and an init script to automatically
load modules when an usb device is inserted.

http://www.electronicproductonline.com/~electron/catalog/supportFiles/usbLAN_0.2.1_armel.deb
http://www.electronicproductonline.com/catalog/supportFiles/usbSerial_0.1_armel.deb
http://www.electronicproductonline.com/catalog/supportFiles/usbMouse_0.1.2_armel.deb

Hopefully I didn't misread the question.
On Tue, Jul 15, 2008 at 2:57 PM, Graham Cobb
<g+770@cobb.uk.net<g%2B770@cobb.uk.net>>
wrote:

>
> Firstly, as it stands today, I can't find a way to install the module such
> that it can be found and loaded automatically when the hardware is seen on
> boot: /lib/modules is only in the initfs.
>
> Graham
> _______________________________________________
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>

Graham Cobb wrote:
> On Tuesday 15 July 2008 09:25:36 Frantisek Dufka wrote:
>
>> Primary goal is to accumulate kernel patches so they do not get lost,
>> secondary goal is to build kernel images for all devices and latest
>> versions of all IT200x releases. Patches should primarily apply to
>> kernel sources release in Maemo SDK (i.e not current linux-omap).
>>
>
> Do you see this also addressing the related issue of building and distributing
> kernel modules?
>
> I have a package (sisusbvga) which contains a kernel module (to drive an
> external VGA adapter). At the moment, I have built the kernel module using
> the instructions on the wiki and then I package it up as a binary blob -- in
> other words the debian package does NOT build the module from source. If
> possible, I would like to change that so that the debian package builds the
> module, in the autobuilder.
>
> Actually in my case the situation may be reasonably straightforward: the
> sisusbvga driver is actually part of the standard Linux kernel, although a
> patch is required to get it to build for the Internet Tablet (I ought to
> submit the patch to LKML one day). So, I guess it falls within the scope of
> this project anyway, assuming you are addressing the problem of kernel
> modules as well as the kernel image itself.
>
> There are another couple of issues -- are they part of this project?
>
> Firstly, as it stands today, I can't find a way to install the module such
> that it can be found and loaded automatically when the hardware is seen on
> boot: /lib/modules is only in the initfs.
>
> The other problem is how to deal with kernel versions. I believe the plan for
> Maemo going forward is that even kernel upgrades may occur. What package do
> I specify as a dependency so that my package only installs on the correct
> kernel version? How do I get the autobuilder to build the various versions
> of my module needed for the different kernel versions? What magic do I need
> to put in my debian/control to get the installer to install the correct
> version of my module for the kernel version?
>
I have a similar issue where I have to maintain the openafs kernel
modules, but I am trying to get them to automatically build in the
autobuilder. my module lives in a odd folder and is loaded by the init.d
script so loading is taken care of. I will continue to maint the openafs
kernel module along with the openafs package.

Jason
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Hi,

On Tue, Jul 15, 2008 at 12:20 PM, Jason Edgecombe
<jason@rampaginggeek.com> wrote:
> Graham Cobb wrote:
>> On Tuesday 15 July 2008 09:25:36 Frantisek Dufka wrote:
>>
>>> Primary goal is to accumulate kernel patches so they do not get lost,
>>> secondary goal is to build kernel images for all devices and latest
>>> versions of all IT200x releases. Patches should primarily apply to
>>> kernel sources release in Maemo SDK (i.e not current linux-omap).
>>>
>>
>> Do you see this also addressing the related issue of building and distributing
>> kernel modules?
>>
>> I have a package (sisusbvga) which contains a kernel module (to drive an
>> external VGA adapter). At the moment, I have built the kernel module using
>> the instructions on the wiki and then I package it up as a binary blob -- in
>> other words the debian package does NOT build the module from source. If
>> possible, I would like to change that so that the debian package builds the
>> module, in the autobuilder.
>>
>> Actually in my case the situation may be reasonably straightforward: the
>> sisusbvga driver is actually part of the standard Linux kernel, although a
>> patch is required to get it to build for the Internet Tablet (I ought to
>> submit the patch to LKML one day). So, I guess it falls within the scope of
>> this project anyway, assuming you are addressing the problem of kernel
>> modules as well as the kernel image itself.
>>
>> There are another couple of issues -- are they part of this project?
>>
>> Firstly, as it stands today, I can't find a way to install the module such
>> that it can be found and loaded automatically when the hardware is seen on
>> boot: /lib/modules is only in the initfs.
>>
>> The other problem is how to deal with kernel versions. I believe the plan for
>> Maemo going forward is that even kernel upgrades may occur. What package do
>> I specify as a dependency so that my package only installs on the correct
>> kernel version? How do I get the autobuilder to build the various versions
>> of my module needed for the different kernel versions? What magic do I need
>> to put in my debian/control to get the installer to install the correct
>> version of my module for the kernel version?
>>
> I have a similar issue where I have to maintain the openafs kernel
> modules, but I am trying to get them to automatically build in the
> autobuilder. my module lives in a odd folder and is loaded by the init.d
> script so loading is taken care of. I will continue to maint the openafs
> kernel module along with the openafs package.

The fuse module, from the package fuse-modules-rx-34 is installed at
/lib/modules/2.6.21-omap1/extra/fuse.ko
and it is loaded by the default kernel.

I didn't find a good solution for building kernel modules in
autobuilder, except building the whole kernel first.
I don't have much experience with kernel modules, but maybe there's a
way of avoiding compiling the kernel every time I want to build a
single module.

Maybe someone with more experience building modules can give some hints.

Marcio

> Jason
> _______________________________________________
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Graham Cobb wrote:

> Do you see this also addressing the related issue of building and distributing
> kernel modules?

Yes. Changing kernel configuration (enabling additonal modules or
additional features) is part of this too. Nokia is (understandably)
quite conservative in enabling stuff not strictly required for stock
firmware so this is the role of community too. There is real need for
stuff like additional filesystems (both local and remote) drivers for
various usb stuff usable in host mode ... etc

I guess this naturally extends also to out of tree (open source) modules.

> Firstly, as it stands today, I can't find a way to install the module such
> that it can be found and loaded automatically when the hardware is seen on
> boot: /lib/modules is only in the initfs.

Well, there is no modprobe preinstalled, just insmod. This is problem is
not related to initfs or custom kernels.

Yes some modules needed for boot live in initfs but I guess once we
package modules into debs they should live in rootfs, even the current
ones should perhaps be duplicated there. Then maybe some package that
modifies initfs (hopefully bootmenu some day) should depend on such
module and copy it from rootfs to initfs.

>
> The other problem is how to deal with kernel versions. I believe the plan for
> Maemo going forward is that even kernel upgrades may occur. What package do
> I specify as a dependency so that my package only installs on the correct
> kernel version? How do I get the autobuilder to build the various versions
> of my module needed for the different kernel versions? What magic do I need
> to put in my debian/control to get the installer to install the correct
> version of my module for the kernel version?

I guess Nokia people (Marius?) could comment on how exactly they plan to
solve it with system updates once first kernel update comes and some
package depends on it (like whole updated initfs or anything in rootfs)?
In general debian package versions and dependencies should solve it.

As for packaging and using autobuilder I am newbie here. I guess we can
have set of kernel patches (or does building debian package require only
one source tar.gz and only one diff?) in .dsc file and reuse original
kernel source in maemo SDK repository, patch it just like debian does it
for any upstream source and build set of binary packages from it -
flashable kernel image package plus module(s) package(s). I remember
similar system was used in Familiar distribution, you had package
kernel-2.4.18-hhXX.ipk and then set of modules-whatever-2.4.18-hhXX.ipkg
packages. Of course modules had dependency on the kernel so you needed
to install it first.

Frantisek
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Marcio Macedo wrote:
> Hi,
>
> On Tue, Jul 15, 2008 at 12:20 PM, Jason Edgecombe
> <jason@rampaginggeek.com> wrote:
>
>> Graham Cobb wrote:
>>
>>> On Tuesday 15 July 2008 09:25:36 Frantisek Dufka wrote:
>>>
>>>
>>>> Primary goal is to accumulate kernel patches so they do not get lost,
>>>> secondary goal is to build kernel images for all devices and latest
>>>> versions of all IT200x releases. Patches should primarily apply to
>>>> kernel sources release in Maemo SDK (i.e not current linux-omap).
>>>>
>>>>
>>> Do you see this also addressing the related issue of building and distributing
>>> kernel modules?
>>>
>>> I have a package (sisusbvga) which contains a kernel module (to drive an
>>> external VGA adapter). At the moment, I have built the kernel module using
>>> the instructions on the wiki and then I package it up as a binary blob -- in
>>> other words the debian package does NOT build the module from source. If
>>> possible, I would like to change that so that the debian package builds the
>>> module, in the autobuilder.
>>>
>>> Actually in my case the situation may be reasonably straightforward: the
>>> sisusbvga driver is actually part of the standard Linux kernel, although a
>>> patch is required to get it to build for the Internet Tablet (I ought to
>>> submit the patch to LKML one day). So, I guess it falls within the scope of
>>> this project anyway, assuming you are addressing the problem of kernel
>>> modules as well as the kernel image itself.
>>>
>>> There are another couple of issues -- are they part of this project?
>>>
>>> Firstly, as it stands today, I can't find a way to install the module such
>>> that it can be found and loaded automatically when the hardware is seen on
>>> boot: /lib/modules is only in the initfs.
>>>
>>> The other problem is how to deal with kernel versions. I believe the plan for
>>> Maemo going forward is that even kernel upgrades may occur. What package do
>>> I specify as a dependency so that my package only installs on the correct
>>> kernel version? How do I get the autobuilder to build the various versions
>>> of my module needed for the different kernel versions? What magic do I need
>>> to put in my debian/control to get the installer to install the correct
>>> version of my module for the kernel version?
>>>
>>>
>> I have a similar issue where I have to maintain the openafs kernel
>> modules, but I am trying to get them to automatically build in the
>> autobuilder. my module lives in a odd folder and is loaded by the init.d
>> script so loading is taken care of. I will continue to maint the openafs
>> kernel module along with the openafs package.
>>
>
> The fuse module, from the package fuse-modules-rx-34 is installed at
> /lib/modules/2.6.21-omap1/extra/fuse.ko
> and it is loaded by the default kernel.
>
> I didn't find a good solution for building kernel modules in
> autobuilder, except building the whole kernel first.
> I don't have much experience with kernel modules, but maybe there's a
> way of avoiding compiling the kernel every time I want to build a
> single module.
>
> Maybe someone with more experience building modules can give some hints.
>
> Marcio
>
I thought that too, but I seem to be able to get away with running the
following in the kernel source to make things work "make distclean; make
n800_defconfig; make modules_prepare"

I'm having trouble with fakeroot and scratchbox building my package but
if I get to the autobuilder, I'll let you know how this works. There is
a kernel-diablo-headers package but it was not enough to compile kernel
modules against.

Jason
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Hi,

On Tue, Jul 15, 2008 at 10:50 PM, Jason Edgecombe
<jason@rampaginggeek.com> wrote:
> Marcio Macedo wrote:
>> Hi,
>>
>> On Tue, Jul 15, 2008 at 12:20 PM, Jason Edgecombe
>> <jason@rampaginggeek.com> wrote:
>>
>>> Graham Cobb wrote:
>>>
>>>> On Tuesday 15 July 2008 09:25:36 Frantisek Dufka wrote:
>>>>
>>>>
>>>>> Primary goal is to accumulate kernel patches so they do not get lost,
>>>>> secondary goal is to build kernel images for all devices and latest
>>>>> versions of all IT200x releases. Patches should primarily apply to
>>>>> kernel sources release in Maemo SDK (i.e not current linux-omap).


I like qwerty12's idea of keeping patches in a quilt set, I replied in
the garage forum[1].

I think until the autobuilder/extras-devel process is defined, we
should be collecting patches already floating around and maybe keeping
a table of the status of those patches (stable(ish), experimental,
developers only, only for version 2.6.21-omap-blah etc etc).

If we have those patches as a quilt set, then someone can already grab
the maemo kernel sources and get our quilt set from svn and push the
patches they are interested in.

Once the build process is defined we can choose which patches have a
status worthy of going in the extras-devel build. Then we can start
making 'spins' with different patch sets if that makes sense.

I don't mind collecting patches for now, so if you have some code
floating around or a known location of something interesting to the
project, reply here with it and i can bundle them up (and make a quilt
set ?) ready to go in svn

Cheers

[1] https://garage.maemo.org/forum/forum.php?thread_id=3093&forum_id=2801

>>>>>
>>>>>
>>>> Do you see this also addressing the related issue of building and distributing
>>>> kernel modules?
>>>>
>>>> I have a package (sisusbvga) which contains a kernel module (to drive an
>>>> external VGA adapter). At the moment, I have built the kernel module using
>>>> the instructions on the wiki and then I package it up as a binary blob -- in
>>>> other words the debian package does NOT build the module from source. If
>>>> possible, I would like to change that so that the debian package builds the
>>>> module, in the autobuilder.
>>>>
>>>> Actually in my case the situation may be reasonably straightforward: the
>>>> sisusbvga driver is actually part of the standard Linux kernel, although a
>>>> patch is required to get it to build for the Internet Tablet (I ought to
>>>> submit the patch to LKML one day). So, I guess it falls within the scope of
>>>> this project anyway, assuming you are addressing the problem of kernel
>>>> modules as well as the kernel image itself.
>>>>
>>>> There are another couple of issues -- are they part of this project?
>>>>
>>>> Firstly, as it stands today, I can't find a way to install the module such
>>>> that it can be found and loaded automatically when the hardware is seen on
>>>> boot: /lib/modules is only in the initfs.
>>>>
>>>> The other problem is how to deal with kernel versions. I believe the plan for
>>>> Maemo going forward is that even kernel upgrades may occur. What package do
>>>> I specify as a dependency so that my package only installs on the correct
>>>> kernel version? How do I get the autobuilder to build the various versions
>>>> of my module needed for the different kernel versions? What magic do I need
>>>> to put in my debian/control to get the installer to install the correct
>>>> version of my module for the kernel version?
>>>>
>>>>
>>> I have a similar issue where I have to maintain the openafs kernel
>>> modules, but I am trying to get them to automatically build in the
>>> autobuilder. my module lives in a odd folder and is loaded by the init.d
>>> script so loading is taken care of. I will continue to maint the openafs
>>> kernel module along with the openafs package.
>>>
>>
>> The fuse module, from the package fuse-modules-rx-34 is installed at
>> /lib/modules/2.6.21-omap1/extra/fuse.ko
>> and it is loaded by the default kernel.
>>
>> I didn't find a good solution for building kernel modules in
>> autobuilder, except building the whole kernel first.
>> I don't have much experience with kernel modules, but maybe there's a
>> way of avoiding compiling the kernel every time I want to build a
>> single module.
>>
>> Maybe someone with more experience building modules can give some hints.
>>
>> Marcio
>>
> I thought that too, but I seem to be able to get away with running the
> following in the kernel source to make things work "make distclean; make
> n800_defconfig; make modules_prepare"
>
> I'm having trouble with fakeroot and scratchbox building my package but
> if I get to the autobuilder, I'll let you know how this works. There is
> a kernel-diablo-headers package but it was not enough to compile kernel
> modules against.
>
> Jason
> _______________________________________________
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>



--
Nick Loeve
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Hi,

2008/7/26, nick loeve <trickie@gmail.com>:
> I don't mind collecting patches for now, so if you have some code
> floating around or a known location of something interesting to the
> project, reply here with it and i can bundle them up (and make a quilt
> set ?) ready to go in svn

Several months ago I have written a patch for the FM tuner driver.
This patch allows
the FM tuner in the N800 switch between the European/American and
Japanese frequency bands
so that the FM radio can be used in Japan.

See https://bugs.maemo.org/show_bug.cgi?id=2249 for the patch.


Regards,
Martin
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Hi,

So far i have this list of patches, from what i have tried myself and
what I have found on the lists or in bugzilla:

1. FM tuner patch for n800 - allows Japanese radio frequencies
- https://bugs.maemo.org/show_bug.cgi?id=2249

2. Allow dsp framebuffer sharing on n8x0
- https://bugs.maemo.org/show_bug.cgi?id=3123

3. n770 SDHC support and higher speed SD/MMC
- http://fanoush.wz.cz/maemo/n770-49-mmc-2.6.18-osso55-sdhc.diff

4. n770 tearsync fix
- http://fanoush.wz.cz/maemo/n770-49-yuv420+tearsync.diff

5. Extended backlight levels
- for IT2006 - http://fanoush.wz.cz/maemo/n770-mipid-backlight.diff
- for IT2007 - http://fanoush.wz.cz/maemo/n800-mipid-backlight.diff
- for IT2008 -
http://fanoush.wz.cz/maemo/rx-34-2.6.21.0-osso63-mipid-backlight.diff

6. Blizzard rotation support
- http://sse2.net/rotate/Updated_blizzard_rotation_support_v2.diff

7. Kprobes backport for ARM (2.6.21)
- http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4447
- http://www.kernel.org/pub/linux/kernel/people/eugeneteo/kprobes/kprobes-arm-cleanup-2.6.21.4-A1

8. High Speed SD/MMC
- Latest for IT2008 - http://intr.overt.org/4.2008.23-mmc-kernel/
- Latest for IT2007 - http://intr.overt.org/4.2007.38-mmc-kernel/

9. Patches for android support
- http://wiki.kimitakeblog.net/lib/exe/fetch.php/android/kernel-diablo-android-v2.patch.bz2?id=dev%3Aandroid%3Akernel&cache=cache

/* These are bug fixes, mostly confirmed as fixes, not in current
official sources) */

10. ARM futex fix (maybe an official bugfix, but till then...)
- https://bugs.maemo.org/show_bug.cgi?id=3438

11. USB fix for host mode on n810 (this may also be an update)
- https://bugs.maemo.org/show_bug.cgi?id=3026

12. V4L2 fix for IT2008
- https://bugs.maemo.org/show_bug.cgi?id=2491

If there are others, especially for earlier ITOS releases and the n770
(of which i have never played with), then let me know and Ill add this
to the list. Soon I will look at making a quilt set (maybe one per
machine?) of all these patches, just so that we have a copy in one
place.

If anyone has remarks or experiences with any of the patches, then
also let me know, as I would like to make a table with information
about each patch (is it stable, does it work as intended, is it used
etc etc). From that list we can decide what will be 'patched' into the
community kernel (or maybe we have more than one i dunno).

Im currently trying to finish off some stuff for the next Mamona
release (plug plug), so i haven't done much else for this project than
trying to collect these links.

Cheers


On Sun, Jul 27, 2008 at 10:23 PM, Martin Grimme <martin.grimme@gmail.com> wrote:
> Hi,
>
> 2008/7/26, nick loeve <trickie@gmail.com>:
>> I don't mind collecting patches for now, so if you have some code
>> floating around or a known location of something interesting to the
>> project, reply here with it and i can bundle them up (and make a quilt
>> set ?) ready to go in svn
>
> Several months ago I have written a patch for the FM tuner driver.
> This patch allows
> the FM tuner in the N800 switch between the European/American and
> Japanese frequency bands
> so that the FM radio can be used in Japan.
>
> See https://bugs.maemo.org/show_bug.cgi?id=2249 for the patch.
>
>
> Regards,
> Martin
>



--
Nick Loeve
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Excellent :)

I just compiled my first n800 kernel last night and was about to start patch
hunting...

I'll update the wiki kernel page l8r

David


nick loeve wrote:
> Hi,
>
> So far i have this list of patches, from what i have tried myself and
> what I have found on the lists or in bugzilla:
>
> 1. FM tuner patch for n800 - allows Japanese radio frequencies
> - https://bugs.maemo.org/show_bug.cgi?id=2249
>
> 2. Allow dsp framebuffer sharing on n8x0
> - https://bugs.maemo.org/show_bug.cgi?id=3123
>
> 3. n770 SDHC support and higher speed SD/MMC
> - http://fanoush.wz.cz/maemo/n770-49-mmc-2.6.18-osso55-sdhc.diff
>
> 4. n770 tearsync fix
> - http://fanoush.wz.cz/maemo/n770-49-yuv420+tearsync.diff
>
> 5. Extended backlight levels
> - for IT2006 - http://fanoush.wz.cz/maemo/n770-mipid-backlight.diff
> - for IT2007 - http://fanoush.wz.cz/maemo/n800-mipid-backlight.diff
> - for IT2008 -
> http://fanoush.wz.cz/maemo/rx-34-2.6.21.0-osso63-mipid-backlight.diff
>
> 6. Blizzard rotation support
> - http://sse2.net/rotate/Updated_blizzard_rotation_support_v2.diff
>
> 7. Kprobes backport for ARM (2.6.21)
> - http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4447
> - http://www.kernel.org/pub/linux/kernel/people/eugeneteo/kprobes/kprobes-arm-cleanup-2.6.21.4-A1
>
> 8. High Speed SD/MMC
> - Latest for IT2008 - http://intr.overt.org/4.2008.23-mmc-kernel/
> - Latest for IT2007 - http://intr.overt.org/4.2007.38-mmc-kernel/
>
> 9. Patches for android support
> - http://wiki.kimitakeblog.net/lib/exe/fetch.php/android/kernel-diablo-android-v2.patch.bz2?id=dev%3Aandroid%3Akernel&cache=cache
>
> /* These are bug fixes, mostly confirmed as fixes, not in current
> official sources) */
>
> 10. ARM futex fix (maybe an official bugfix, but till then...)
> - https://bugs.maemo.org/show_bug.cgi?id=3438
>
> 11. USB fix for host mode on n810 (this may also be an update)
> - https://bugs.maemo.org/show_bug.cgi?id=3026
>
> 12. V4L2 fix for IT2008
> - https://bugs.maemo.org/show_bug.cgi?id=2491
>
> If there are others, especially for earlier ITOS releases and the n770
> (of which i have never played with), then let me know and Ill add this
> to the list. Soon I will look at making a quilt set (maybe one per
> machine?) of all these patches, just so that we have a copy in one
> place.
>
> If anyone has remarks or experiences with any of the patches, then
> also let me know, as I would like to make a table with information
> about each patch (is it stable, does it work as intended, is it used
> etc etc). From that list we can decide what will be 'patched' into the
> community kernel (or maybe we have more than one i dunno).
>
> Im currently trying to finish off some stuff for the next Mamona
> release (plug plug), so i haven't done much else for this project than
> trying to collect these links.
>
> Cheers
>
>
> On Sun, Jul 27, 2008 at 10:23 PM, Martin Grimme <martin.grimme@gmail.com> wrote:
>> Hi,
>>
>> 2008/7/26, nick loeve <trickie@gmail.com>:
>>> I don't mind collecting patches for now, so if you have some code
>>> floating around or a known location of something interesting to the
>>> project, reply here with it and i can bundle them up (and make a quilt
>>> set ?) ready to go in svn
>> Several months ago I have written a patch for the FM tuner driver.
>> This patch allows
>> the FM tuner in the N800 switch between the European/American and
>> Japanese frequency bands
>> so that the FM radio can be used in Japan.
>>
>> See https://bugs.maemo.org/show_bug.cgi?id=2249 for the patch.
>>
>>
>> Regards,
>> Martin
>>
>
>
>

_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers